From report at bugs.python.org  Fri Aug  1 01:08:13 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Jul 2014 23:08:13 +0000
Subject: [New-bugs-announce] [issue22117] Rewrite pytime.h to work on
	nanoseconds
Message-ID: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To prepare Python to add support of monotonic clock in pytime.h, I propose to rewrite pytime.h to use a new _PyTimeSpec structure which has a resolution of 1 nanosecond on only work on integers.

Currently, pytime.h uses a _PyTime_timeval structure which has a solution of 1 microsecond and works internally on floating point numbers. Computing the difference between two timestamps may loose precision.

The tv_nsec field of _PyTimeSpec must be in the range [0; 999999999], even for negative numbers. For example, -1 ns is stored as (-1, 999999999). This property makes the code more complex, especially to round correctly.


The new API is based on the idea that all timestamps must be stored as _PyTimeSpec.

Convert a value into a _PyTimeSpec:

- _PyTimeSpec_from_double(): C double
- _PyTimeSpec_from_object(): Python int or float object
- you can also fill directly the tv_sec and tv_nsec fields

Convert a _PyTimeSpec timestamp into a value:

- _PyTimeSpec_to_time_t(): C time_t
- _PyTimeSpec_to_timeval(): C timeval (tv_sec, tv_usec), but ot directly the structure because the exact structure is different depending on the OS and OS version
- _PyTimeSpec_ms(): C long, number of milliseconds

Operations on _PyTimeSpec:

- _PyTimeSpec_add(): a+b
- _PyTimeSpec_sub(): a-b

I removed high-level functions like _PyTime_ObjectToTimeval(): you should now combine _PyTimeSpec_from_object() with _PyTimeSpec_to_timeval(). I did this to not multiply the number of functions, because I want to test all functions in unit tests and have a short API.


I tried to enhance detecton of overflow. I didn't review carefuly my patch yet. I'm not sure that all calls check for error and handle exceptions correctly. Only the following functions raise an exception on error:

- _PyTimeSpec_from_object()
- _PyTimeSpec_to_time_t()
- _PyTimeSpec_to_timeval()

Other functions sets the minimum/maximum value in case of underflow/overflow. So even if you don't check for errors, the behaviour on overflow should be acceptable.


The new _PyTimeSpec_Init() function checks that the system clock works, so _PyTimeSpec_get_time() and _PyTimeSpec_get_time_info() don't need to check for error. In fact, these functions call Py_FatalError() on error, but it should never happen. This idea was proposed in the issue #22043 to check if the monotonic clock is working. Maybe we can avoid checking the system clock in _PyTimeSpec_Init() and only check the monotonic clock. I hope that all platforms have a working system clock! The oppoosite would be a huge issue.


The patch removes function which are exposed in the stable ABI. Since the functions are private, name starting with ("_Py"), I consider that it's ok to remove them. The functions are replaced with new functions which a have a new name. I excluded pytime.h from the stable ABI. I don't know why private functions were part of the stable ABI :-/


The patch comes with unit tests for each function.


I didn't implement handling of overflow and underflow in _PyTimeSpec_add() and _PyTimeSpec_sub() yet. But I implemented detection for overflow for the simple case.


See also:

- Issue #22043: "Use a monotonic clock to compute timeouts".
- PEP 410: "Use decimal.Decimal type for timestamps" (rejected)

----------
files: timespec.patch
keywords: patch
messages: 224452
nosy: haypo
priority: normal
severity: normal
status: open
title: Rewrite pytime.h to work on nanoseconds
versions: Python 3.4
Added file: http://bugs.python.org/file36186/timespec.patch

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

From report at bugs.python.org  Fri Aug  1 15:38:49 2014
From: report at bugs.python.org (Mike Lissner)
Date: Fri, 01 Aug 2014 13:38:49 +0000
Subject: [New-bugs-announce] [issue22118] urljoin fails with messy relative
	URLs
Message-ID: <1406900329.8.0.528379735401.issue22118@psf.upfronthosting.co.za>


New submission from Mike Lissner:

Not sure if this is desired behavior, but it's making my code break, so I figured I'd get it filed.

I'm trying to crawl this website: https://www.appeals2.az.gov/ODSPlus/recentDecisions2.cfm

Unfortunately, most of the URLs in the HTML are relative, taking the form:

'../../some/path/to/some/pdf.pdf'

I'm using lxml's make_links_absolute() function, which calls urljoin creating invalid urls like:

https://www.appeals2.az.gov/../Decisions/CR20130096OPN.pdf

If you put that into Firefox or wget or whatever, it works, despite being invalid and making no sense. 

**It works because those clients fix the problem,** joining the invalid path and the URL into:

https://www.appeals2.az.gov/Decisions/CR20130096OPN.pdf

I know this will mean making urljoin have a workaround to fix bad HTML, but this seems to be what wget, Chrome, Firefox, etc. all do. 

I've never filed a Python bugs before, but is this something we could consider?

----------
components: Library (Lib)
messages: 224500
nosy: Mike.Lissner
priority: normal
severity: normal
status: open
title: urljoin fails with messy relative URLs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  1 22:44:52 2014
From: report at bugs.python.org (John Fisher)
Date: Fri, 01 Aug 2014 20:44:52 +0000
Subject: [New-bugs-announce] [issue22119] Some input chars (i.e. '++') break
	re.match
Message-ID: <1406925892.62.0.916485678842.issue22119@psf.upfronthosting.co.za>


New submission from John Fisher:

Some characters repeated in the pattern break re.match:


Linux python 2.7.6
###################################
# test.py
import re

#diffitem = "libstdc+"   succeeds
#diffitem = "libstdc++"  fails
#diffitem = "libstdc**"  fails
#diffitem = "libstdc.."  succeeds
diffitem = "libstdc+\+"  succeeds
line = "time  1.7-23build1"

result = re.match(diffitem, line)
print result

###################################
$ python  test.py
Traceback (most recent call last):
  File "test.py", line 9, in <module>
    result = re.match(diffitem, line)
  File "/usr/lib/python2.7/re.py", line 137, in match
    return _compile(pattern, flags).match(string)
  File "/usr/lib/python2.7/re.py", line 244, in _compile
    raise error, v # invalid expression
sre_constants.error: multiple repeat

----------
components: Regular Expressions
messages: 224518
nosy: ezio.melotti, jpfisher, mrabarnett
priority: normal
severity: normal
status: open
title: Some input chars (i.e. '++') break re.match
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug  2 02:14:08 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Aug 2014 00:14:08 +0000
Subject: [New-bugs-announce] [issue22120] Fix compiler warnings
Message-ID: <1406938448.57.0.457733140419.issue22120@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #22110 enabled more compiler warnings. Attached patch tries to fix most of them on Linux.

----------
messages: 224528
nosy: haypo
priority: normal
severity: normal
status: open
title: Fix compiler warnings

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

From report at bugs.python.org  Sat Aug  2 09:53:52 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Sat, 02 Aug 2014 07:53:52 +0000
Subject: [New-bugs-announce] [issue22121] IDLE should start with HOME as the
	initial working	directory
Message-ID: <1406966032.01.0.548285467026.issue22121@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

On Windows IDLE's working directory is Python's install directory, e.g., C:\Python34. ISTM that this is the wrong directory for 99% of general users and for 100% of beginners since this is _not_ the directory where people should save their own .py files (unless they are experts, in which case they know better and won't anyway).

I think that IDLE should start out in the user's home directory (ideally on all platforms).

----------
components: IDLE
messages: 224537
nosy: mark
priority: normal
severity: normal
status: open
title: IDLE should start with HOME as the initial working directory
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug  2 09:57:51 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Sat, 02 Aug 2014 07:57:51 +0000
Subject: [New-bugs-announce] [issue22122] turtle module examples should all
	begin "from turtle	import *"
Message-ID: <1406966271.25.0.28039955033.issue22122@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

The turtle module is aimed primarily at young beginners to Python. Making them type turtle.this and turtle.that all over the place is tedious and unhelpful.

At the start of the turtle docs there's a nice example that begins
from turtle import *
and the following code is all the better for it.

But none of the other examples do this. I realise that this would make the module's docs inconsistent, but given the target audience and given that we surely want to lower the barrier to entry, it would be a reasonable concession to make?

----------
assignee: docs at python
components: Documentation
messages: 224538
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: turtle module examples should all begin "from turtle import *"
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug  2 10:02:28 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Sat, 02 Aug 2014 08:02:28 +0000
Subject: [New-bugs-announce] [issue22123] Make object() behave exactly
	like	types.SimpleNamespace() if given kwargs
Message-ID: <1406966548.11.0.912987884229.issue22123@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

Right now object() does not accept any args and returns the lightest possible featureless object (i.e., without even a __dict__).

This is great.

However, it is really useful sometimes to be able to create an object to hold some editable state (so not a namedtuple). Right now this can be done with types.SimpleNamespace().

I think it would be a useful enhancement to have object() work as it does now, but to allow it to accept kwargs in which case it would provide identical functionality to types.SimpleNamespace().

This arises from an email I wrote to the python mailinglist:
https://groups.google.com/d/msg/comp.lang.python/9pY7hLp8lDg/voYF8nMO6x8J

But I also think it would be useful more generally.

----------
components: Interpreter Core
messages: 224539
nosy: mark
priority: normal
severity: normal
status: open
title: Make object() behave exactly like types.SimpleNamespace() if given kwargs
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug  2 22:35:33 2014
From: report at bugs.python.org (Sai Krishna G)
Date: Sat, 02 Aug 2014 20:35:33 +0000
Subject: [New-bugs-announce] [issue22124] Rotating items of list to left
Message-ID: <1407011733.93.0.772896051293.issue22124@psf.upfronthosting.co.za>


New submission from Sai Krishna G:

Hi, I am trying to rotate list of 3 to left
for this I am trying to define this function
def rotate_left3(nums)

#argument nums is list
for example
rotate_left3([1, 2, 3])
I am expecting value [2,3,1] in return. I have written the following code
    a = nums
    a[0]=nums[1]
    a[1]=nums[2]
    a[2]=nums[0]
    return a #this is returning [2,3,2] instead of [2,3,1]
however if I assign
a = [0,0,0] #or any other value other than directly assigning nums
the code works perfectly

----------
components: Windows
files: rotate_left3.py
messages: 224586
nosy: Sai.Krishna.G
priority: normal
severity: normal
status: open
title: Rotating items of list to left
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36215/rotate_left3.py

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

From report at bugs.python.org  Sun Aug  3 00:11:52 2014
From: report at bugs.python.org (David Wilson)
Date: Sat, 02 Aug 2014 22:11:52 +0000
Subject: [New-bugs-announce] [issue22125] Cure signedness warnings
	introduced by #22003
Message-ID: <1407017512.42.0.779686467966.issue22125@psf.upfronthosting.co.za>


New submission from David Wilson:

The attached patch (hopefully) silences the signedness warnings generated by Visual Studio and reported on python-dev in <https://mail.python.org/pipermail/python-dev/2014-July/135603.html>. 

This was sloppiness on my part, I even noted the problem in the original ticket and never fixed it. :)

I don't have a local dev environment setup for MSVC and Python, but at least the attached patch cures the signedness errors on Clang. They don't seem to occur at all with GCC on my Mac.

The added casts ensure comparisons uniformly compare in the unsigned domain. It seems "size_t buf_size" is pretty redundant in the original struct, it just introduces lots of casting when it only appears to be required during write_bytes() to avoid signed overflow (undefined behaviour)

----------
components: Library (Lib)
files: cow-sign.patch
keywords: patch
messages: 224593
nosy: dw, pitrou, zach.ware
priority: normal
severity: normal
status: open
title: Cure signedness warnings introduced by #22003
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file36217/cow-sign.patch

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

From report at bugs.python.org  Sun Aug  3 09:12:42 2014
From: report at bugs.python.org (ivank)
Date: Sun, 03 Aug 2014 07:12:42 +0000
Subject: [New-bugs-announce] [issue22126] mc68881 fpcr inline asm breaks
	clang -flto build
Message-ID: <1407049962.24.0.593960566551.issue22126@psf.upfronthosting.co.za>


New submission from ivank:

Build cpython master with clang -flto results in:

[...]
ar rc libpython3.5m.a Modules/_threadmodule.o  Modules/signalmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/_stat.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/zipimport.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython3.5m.a
clang -pthread -flto -B/usr/lib/gold-ld -flto -B/usr/lib/gold-ld -Xlinker -export-dynamic -o python Programs/python.o libpython3.5m.a -lpthread -ldl  -lutil   -lm  
clang -pthread -flto -B/usr/lib/gold-ld -flto -B/usr/lib/gold-ld -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o libpython3.5m.a -lpthread -ldl  -lutil   -lm  
<inline asm>:1:10: error: invalid register name
        fmove.l %fpcr,36(%rsp)
                ^~~~~
LLVM ERROR: Error parsing inline asm

clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [python] Error 1
make: *** Waiting for unfinished jobs....
<inline asm>:1:10: error: invalid register name
        fmove.l %fpcr,36(%rsp)
                ^~~~~
LLVM ERROR: Error parsing inline asm

clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Programs/_testembed] Error 1



My build script was:

#!/bin/bash

# Get clang 3.5 from
# deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty main
# deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty main

set -e

sudo ln -sf /usr/lib/llvm-3.5/lib/LLVMgold.so /usr/lib/LLVMgold.so
sudo mkdir -p /usr/lib/bfd-plugins
sudo ln -sf /usr/lib/llvm-3.5/lib/LLVMgold.so /usr/lib/bfd-plugins/LLVMgold.so
grep -Fxq /usr/lib/llvm-3.5/lib /etc/ld.so.conf || (echo "/usr/lib/llvm-3.5/lib should be in /etc/ld.so.conf" && false)
sudo ldconfig

export CC=clang
export CXX=clang++
export CFLAGS="-O3 -flto -B/usr/lib/gold-ld -fomit-frame-pointer"
export CXXFLAGS="-O3 -flto -B/usr/lib/gold-ld -fomit-frame-pointer"
export LDFLAGS="-flto -B/usr/lib/gold-ld" 
make clean || echo "Can't make clean"
./configure --prefix=/opt/leakless
make -j17


It works fine without the -flto/gold-ld options.

----------
components: Interpreter Core
messages: 224613
nosy: ivank
priority: normal
severity: normal
status: open
title: mc68881 fpcr inline asm breaks clang -flto build
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug  3 10:17:29 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 03 Aug 2014 08:17:29 +0000
Subject: [New-bugs-announce] [issue22127] performance regression in
	socket.getsockaddr()
Message-ID: <1407053849.06.0.738160055146.issue22127@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

I noticed that socket.sendto() got noticably slower since 3.4 (at least), compared to 2.7:

2.7:
$ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA = b'hello'; TARGET=('127.0.0.1', 4242)" "s.sendto(DATA, TARGET)"
100000 loops, best of 3: 15.8 usec per loop

3.4:
$ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA = b'hello'; TARGET=('127.0.0.1', 4242)" "s.sendto(DATA, TARGET)"
10000 loops, best of 3: 25.9 usec per loop

A profile reveals this:
2.7:
         100065 function calls in 2.268 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.361    0.361    2.268    2.268 test_send.py:1(<module>)
   100000    1.895    0.000    1.895    0.000 {method 'sendto' of '_socket.socket' objects}


3.4:
         906015 function calls (905975 primitive calls) in 6.132 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      5/1    0.000    0.000    6.132    6.132 {built-in method exec}
        1    0.334    0.334    6.132    6.132 test_send.py:1(<module>)
   100000    2.347    0.000    5.769    0.000 {method 'sendto' of '_socket.socket' objects}
   100000    1.991    0.000    3.411    0.000 idna.py:147(encode)
   500086    0.894    0.000    0.894    0.000 {built-in method len}
   100000    0.269    0.000    0.269    0.000 {method 'encode' of 'str' objects}
   100000    0.257    0.000    0.257    0.000 {method 'split' of 'bytes' objects}


As can be seen, it's the IDNA encoding which takes a long time, and doesn't appear in the 2.7 profile.
The parsing code (including idna codec) is present in both versions though:
"""
static int
getsockaddrarg(PySocketSockObject *s, PyObject *args,
               struct sockaddr *addr_ret, int *len_ret)
[...]
        if (!PyArg_ParseTuple(args, "eti:getsockaddrarg",
                              "idna", &host, &port))
            return 0;
"""

I'm currently bisecting the commit, but I'm not familiar with encoding stuff.
Is it expected that the IDNA encoding be called when passed an ascii string?

----------
components: Library (Lib)
messages: 224618
nosy: haypo, loewis, neologix, pitrou
priority: normal
severity: normal
status: open
title: performance regression in socket.getsockaddr()
type: performance
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Aug  3 15:17:18 2014
From: report at bugs.python.org (Frank van Dijk)
Date: Sun, 03 Aug 2014 13:17:18 +0000
Subject: [New-bugs-announce] [issue22128] patch: steer people away from
	codecs.open
Message-ID: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>


New submission from Frank van Dijk:

stackoverflow.com has a zillion answers recommending the use of codecs.open() as a unicode capable drop in replacement for open(). This probably means that there is still a lot of code being written that uses codecs.open(). That's bad thing because of codecs.open()'s lack of newline conversion. A lot of that code will 
- have compatibility issues when it is moved between unix and windows
- silently break text files on windows, leading to issues further downstream (confusing other tools, messing up revision control histories)

The problem has been fixed with io.open() in 2.x and open() in 3.x. Unfortunately the 2.7 unicode HOWTO still recommends the use of codecs.open(). The 2.7 and the 3.x documentation of codecs.open() doesn't refer the reader to better alternatives.

The attached patches fix that.

The only downside I see is that newly written code that uses the better alternatives would be incompatible with 2.5 and older. However croaking on a small minority of systems is better than silently disrupting workflows, causing platform incompatibilities, and inviting flaky workarounds.

The 2.7 patch makes the unicode HOWTO recommend io.open() instead of codecs.open(). Both patches change the codecs.open() documentation to refer to io.open() or (on 3.x) open().

Additionally I removed the "data loss" explanation from codecs.open()'s note about its lack of newline conversion. It is not particularly helpful information and it is not entirely correct (data loss could also have been avoided by doing newline conversion before encoding and after decoding)

----------
assignee: docs at python
components: Documentation
files: codecsopen2.patch
keywords: patch
messages: 224632
nosy: Frank.van.Dijk, docs at python
priority: normal
severity: normal
status: open
title: patch: steer people away from codecs.open
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36234/codecsopen2.patch

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

From report at bugs.python.org  Sun Aug  3 15:18:36 2014
From: report at bugs.python.org (Tobias Leupold)
Date: Sun, 03 Aug 2014 13:18:36 +0000
Subject: [New-bugs-announce] [issue22129] Please add an equivalent to
	QString::simplified() to	Python strings
Message-ID: <1407071916.54.0.415237885761.issue22129@psf.upfronthosting.co.za>


New submission from Tobias Leupold:

It would be nice if a function equivalent to Qt's QString::simplified() would be added to Python's strings (cf. http://qt-project.org/doc/qt-4.8/qstring.html#simplified ).

I'm not sure if my approach is good or fast, but I added this function to my code like so: http://nasauber.de/blog/T/143/QString_simplified_in_Python

----------
components: Interpreter Core
messages: 224633
nosy: l3u
priority: normal
severity: normal
status: open
title: Please add an equivalent to QString::simplified() to Python strings
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Aug  3 19:16:57 2014
From: report at bugs.python.org (Brendan Meeder)
Date: Sun, 03 Aug 2014 17:16:57 +0000
Subject: [New-bugs-announce] [issue22130] Logging fileConfig behavior does
	not match documentation
Message-ID: <1407086217.44.0.852593986521.issue22130@psf.upfronthosting.co.za>


New submission from Brendan Meeder:

The 2.7.8 documentation for fileConfig says that for disable_existing_loggers:

"If specified as False, loggers which exist when this call is made are left alone."

This is actually not the case- they are enabled after the call to fileConfig. In particular, the loggers that would be disabled if disable_existing_loggers=True are enabled after the call, regardless of whether they were previously enabled/disabled.

----------
components: Library (Lib)
messages: 224648
nosy: Brendan.Meeder
priority: normal
severity: normal
status: open
title: Logging fileConfig behavior does not match documentation
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug  4 04:05:56 2014
From: report at bugs.python.org (Kevin London)
Date: Mon, 04 Aug 2014 02:05:56 +0000
Subject: [New-bugs-announce] [issue22131] uuid.bytes optimization
Message-ID: <1407117956.69.0.92579582172.issue22131@psf.upfronthosting.co.za>


New submission from Kevin London:

Generating the byte representation of a UUID object can be a little faster by using binascii's unhexlify on the hex value of the UUID object. In my testing, I saw about a 5.5x speed increase with the attached changes. 

Here are a set of benchmarks that I ran, which are inspired by Wang Chun's benchmarks on http://bugs.python.org/issue5885:

https://gist.github.com/kevinlondon/d3bb32d5a784f78731fa

My times:

kevin$ python uuid_benchmark.py 100000
Original Average: 8.049 microseconds
Updated Average: 1.447 microseconds
 
I re-ran all of the tests with the patched uuid module and they passed. Here's my patchcheck output as well:

kevin$ make patchcheck
./python.exe ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 1 file
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0 files
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NO
configure regenerated ... not needed
pyconfig.h.in regenerated ... not needed

Thanks!

----------
assignee: ronaldoussoren
components: Benchmarks, Library (Lib), Macintosh
files: uuid_bytes_update.patch
keywords: patch
messages: 224671
nosy: kevinlondon, ronaldoussoren
priority: normal
severity: normal
status: open
title: uuid.bytes optimization
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file36241/uuid_bytes_update.patch

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

From report at bugs.python.org  Mon Aug  4 09:15:34 2014
From: report at bugs.python.org (Csaba Makara)
Date: Mon, 04 Aug 2014 07:15:34 +0000
Subject: [New-bugs-announce] [issue22132] Cannot copy the same directory
	structure to the same	destination more than once
Message-ID: <1407136534.84.0.777001072361.issue22132@psf.upfronthosting.co.za>


New submission from Csaba Makara:

If I use the distutils.dir_util.copy_tree to copy the same directory structure multiple times to the same place (even from multiple sources) but I remove and recreate the target_directory before each copy, the following exception accurs:

g:\_Programming>py example.py
Traceback (most recent call last):
  File "E:\Python34\lib\distutils\file_util.py", line 41, in _copy_file_contents

    fdst = open(dst, 'wb')
FileNotFoundError: [Errno 2] No such file or directory: 'c:\\bin\\folder_inside\
\file_inside.txt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "example.py", line 13, in <module>
    dir_util.copy_tree(source_folder2, target_folder)
  File "E:\Python34\lib\distutils\dir_util.py", line 160, in copy_tree
    verbose=verbose, dry_run=dry_run))
  File "E:\Python34\lib\distutils\dir_util.py", line 164, in copy_tree
    dry_run=dry_run)
  File "E:\Python34\lib\distutils\file_util.py", line 143, in copy_file
    _copy_file_contents(src, dst)
  File "E:\Python34\lib\distutils\file_util.py", line 44, in _copy_file_contents

    "could not create '%s': %s" % (dst, e.strerror))
distutils.errors.DistutilsFileError: could not create 'c:\bin\folder_inside\file
_inside.txt': No such file or directory
_______________________________________________________________

If the target_folder is not deleted, the problem won't appear. 
The problem seems to be the handling of the inner directories. In the second attempt the inner folders are thought to be existing, but they are not.

See the attached script.

----------
components: Distutils
files: example.py
messages: 224691
nosy: Csaba.Makara, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Cannot copy the same directory structure to the same destination more than once
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file36244/example.py

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

From report at bugs.python.org  Mon Aug  4 16:30:22 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Mon, 04 Aug 2014 14:30:22 +0000
Subject: [New-bugs-announce] [issue22133] IDLE: Set correct WM_CLASS on X11
Message-ID: <1407162622.12.0.711549475862.issue22133@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

I found this bug on gnome where IDLE's activity bar entry is named "Toplevel" instead of "IDLE". After digging through the X11 and gnome docs, the WM_CLASS was wrongly being set as "Toplevel". This patch has been verified using xprop, that the correct WM_CLASS value is getting set.

(Does this have any other side effect on KDE, LXDE, XFCE et al?)

----------
components: IDLE
files: idle-x11-class.diff
keywords: patch
messages: 224728
nosy: jesstess, sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Set correct WM_CLASS on X11
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36251/idle-x11-class.diff

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

From report at bugs.python.org  Mon Aug  4 19:29:57 2014
From: report at bugs.python.org (Larry)
Date: Mon, 04 Aug 2014 17:29:57 +0000
Subject: [New-bugs-announce] [issue22134] string formatting float rounding
	errors
Message-ID: <1407173397.31.0.0273570683592.issue22134@psf.upfronthosting.co.za>


New submission from Larry:

Certain values close to the rounding boundary are rounded down instead of up; and this is done somewhat inconsistently.


#Example (python v2.7.8, and previous)

#almost an odd-even pattern, but not quite
for x in [1.045, 1.145, 1.245, 1.345, 1.445, 1.545, 1.645, 1.745, 1.845, 1.945]:
    print "{0:.3f} => {0:.2f}".format(x)

#while ..6 rounds up correctly
for x in [1.046, 1.146, 1.246, 1.346, 1.446, 1.546, 1.646, 1.746, 1.846, 1.946]:
    print "{0:.3f} => {0:.2f}".format(x)

----------
messages: 224747
nosy: Larry
priority: normal
severity: normal
status: open
title: string formatting float rounding errors
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug  4 22:44:21 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 04 Aug 2014 20:44:21 +0000
Subject: [New-bugs-announce] [issue22135] allow to break into pdb with
	Ctrl-C for all the commands	that resume execution
Message-ID: <1407185061.52.0.89159247831.issue22135@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Pdb sets a handler for the SIGINT signal (which is sent when the user presses Ctrl-C on the console) when you give a continue command.
'continue' is not the only pdb command that may be interrupted, all the commands that resume the execution of the program (i.e. the 'do_xxx' Pdb methods that return 1), except for the ones that terminate pdb, should also set the SIGINT signal handler. These are the 'step', 'next', 'until' and 'return' commands.
For example, a 'next' command issued at the invocation of a function when the function is doing a long processing and the user wishes to break into pdb again with Ctrl-C within this function.

It is probably better to fix this issue after issue 20766 is fixed.

----------
components: Library (Lib)
messages: 224772
nosy: xdegaye
priority: normal
severity: normal
status: open
title: allow to break into pdb with Ctrl-C for all the commands that resume execution
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug  4 23:06:58 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 04 Aug 2014 21:06:58 +0000
Subject: [New-bugs-announce] [issue22136] Fix _tkinter compiler warnings on
	MSVC
Message-ID: <1407186418.11.0.644206830672.issue22136@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Dropping support of Tk 8.3 caused a few compiler warnings on Windows:

  ..\Modules\_tkinter.c(587): warning C4090: '=' : different 'const' qualifiers
  ..\Modules\_tkinter.c(588): warning C4090: '=' : different 'const' qualifiers
  ..\Modules\_tkinter.c(589): warning C4090: '=' : different 'const' qualifiers
  ..\Modules\_tkinter.c(590): warning C4090: '=' : different 'const' qualifiers
  ..\Modules\_tkinter.c(591): warning C4090: '=' : different 'const' qualifiers
  ..\Modules\_tkinter.c(592): warning C4090: '=' : different 'const' qualifiers
  ..\Modules\_tkinter.c(593): warning C4090: '=' : different 'const' qualifiers

Does this patch look like the correct fix?

----------
components: Build, Tkinter, Windows
files: tkinter_MSVC_warnings.diff
keywords: patch
messages: 224776
nosy: serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Fix _tkinter compiler warnings on MSVC
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file36261/tkinter_MSVC_warnings.diff

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

From report at bugs.python.org  Tue Aug  5 02:17:13 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Tue, 05 Aug 2014 00:17:13 +0000
Subject: [New-bugs-announce] [issue22137] Test imaplib API on all methods
	specified in RFC 3501
Message-ID: <1407197833.23.0.797549876094.issue22137@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

I finished writing tests for all methods which are specified in RFC 3501 but left out extensions for now. The attached patch will trigger many resource warnings. Do you have an idea why the sockets aren't closed?

----------
files: imaplib_test_rfc3501.patch
keywords: patch
messages: 224790
nosy: jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Test imaplib API on all methods specified in RFC 3501
Added file: http://bugs.python.org/file36263/imaplib_test_rfc3501.patch

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

From report at bugs.python.org  Tue Aug  5 06:14:00 2014
From: report at bugs.python.org (Clint Hepner)
Date: Tue, 05 Aug 2014 04:14:00 +0000
Subject: [New-bugs-announce] [issue22138] patch.object doesn't restore
	function defaults
Message-ID: <1407212040.69.0.583222239779.issue22138@psf.upfronthosting.co.za>


New submission from Clint Hepner:

Following a patch, a function's __defaults__ attribute is reset to None.

    def foo(x=5):
        return x

    assert foo() == 5  # As expected
    with unittest.mock.patch.object(foo, '__defaults__', (10,)):
        assert foo() == 10  # As expected

    assert foo() == 5  # Fails
    assert foo.__defaults__ is None  # Succeeds

----------
components: Library (Lib)
messages: 224801
nosy: chepner
priority: normal
severity: normal
status: open
title: patch.object doesn't restore function defaults
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  5 13:32:54 2014
From: report at bugs.python.org (Andreas Richter)
Date: Tue, 05 Aug 2014 11:32:54 +0000
Subject: [New-bugs-announce] [issue22139] python windows 2.7.8 64-bit wrong
	binary version
Message-ID: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za>


New submission from Andreas Richter:

Having the following problem.
1. Download 2.7.8 64-bit windows msi
2. Install it
3. Run python ... says it's 2.7.6
4. Execute import hmac
5. Error

Output:
C:\prototype>python
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import hmac
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\prototype\Tools\python27\lib\hmac.py", line 8, in <module>
    from operator import _compare_digest as compare_digest
ImportError: cannot import name _compare_digest

I saw some posts out there indicating it had something to do with django or something related, but when I run python -v I can see that it's only involving local python libraries (in fact no site-packages at all)
The problem is that the builtin version of the operator module (which incidentally is not loaded from a pyd or pyc file (meaning it's inside of either python27.dll or python.exe doesn't contain _compare_digest.)
Most of the time to get things to run you can just delete the import line if you can make sure not to call hmac.compare_digest.

----------
components: Installation
messages: 224821
nosy: Andreas.Richter
priority: normal
severity: normal
status: open
title: python windows 2.7.8 64-bit wrong binary version
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  5 15:28:32 2014
From: report at bugs.python.org (Michael Dussere)
Date: Tue, 05 Aug 2014 13:28:32 +0000
Subject: [New-bugs-announce] [issue22140] "python-config --includes" returns
	a wrong path (double	prefix)
Message-ID: <1407245312.64.0.904100539745.issue22140@psf.upfronthosting.co.za>


New submission from Michael Dussere:

Our python is installed on a shared directory that is accessed through a symbolic link. 
$ which python3.4-config
/Produits/publics/x86_64.Linux.RH6/python/3.4.1/bin/python3.4-config

$ ls -al /Produits
lrwxrwxrwx 1 root root 13 Oct 31  2013 /Produits -> /nfs/Produits

With this configuration python-config returns a wrong path (it gives a double /nfs prefix)

$ python3.4-config --includes
-I/nfs/nfs/Produits/publics/x86_64.Linux.RH6/python/3.4.1/include/python3.4m -I/nfs/nfs/Produits/publics/x86_64.Linux.RH6/python/3.4.1/include/python3.4m


The problem is due to a double string replacement in the script

   prefix_build="/Produits/publics/x86_64.Linux.RH6/python/3.4.1"
   prefix_real=$(installed_prefix "$0")

   # Use sed to fix paths from their built-to locations to their installed-to
   # locations.
   prefix=$(echo "$prefix_build" | sed "s#$prefix_build#$prefix_real#")
   exec_prefix_build="${prefix}"
   exec_prefix=$(echo "$exec_prefix_build" | sed "s#$exec_prefix_build#$prefix_real#")
   includedir=$(echo "${prefix}/include" | sed "s#$prefix_build#$prefix_real#")

for $includedir the replacement of $prefix_build by $prefix_real is applyed twice and since the $prefix_real contains $prefix_build it produce a wrong result.

In addition I think it is strange to have lines like the following
prefix=$(echo "$prefix_build" | sed "s#$prefix_build#$prefix_real#")

----------
components: Demos and Tools
messages: 224825
nosy: Michael.Dussere
priority: normal
severity: normal
status: open
title: "python-config --includes" returns a wrong path (double prefix)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  5 17:59:59 2014
From: report at bugs.python.org (Lorenz Quack)
Date: Tue, 05 Aug 2014 15:59:59 +0000
Subject: [New-bugs-announce] [issue22141] rlcompleter.Completer matches too
	much
Message-ID: <1407254399.39.0.799670201718.issue22141@psf.upfronthosting.co.za>


New submission from Lorenz Quack:

Example:

>>> completer = rlcompleter.Completer()

>>> class A(object):
...     def foo(): pass
...     def foobar(): pass

>>> completer.complete("A.foo(", 0)
'A.foo('
>>> completer.complete("A.foo(", 1)
'A.foobar('

I consider the last match a bug.

The root of this bug is that in attr_matches the regular expression ignores any trailing non-alphanumeric characters by using the "\w" sequence. Note that it would also match "A.foo?%&@" to both "A.foo" and "A.foobar".

I propose this regex instead:
r"(\w+(\.\w+)*)\.([^.]*)"
What do people think?

----------
components: Library (Lib)
messages: 224848
nosy: donlorenzo
priority: normal
severity: normal
status: open
title: rlcompleter.Completer matches too much
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/issue22141>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:01:20 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Aug 2014 16:01:20 +0000
Subject: [New-bugs-announce] [issue22142] PEP 465 operators not described in
	lexical_analysis
Message-ID: <1407254480.75.0.52462093327.issue22142@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

As a side comment in #21972, it was noted that @= is not currently documented as an assignment operator. In addition, @ is mentioned as a delimiter, but not as an operator.

https://docs.python.org/3.5/reference/lexical_analysis.html

----------
messages: 224849
nosy: benjamin.peterson, loewis
priority: normal
severity: normal
status: open
title: PEP 465 operators not described in lexical_analysis
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug  5 18:13:15 2014
From: report at bugs.python.org (Lorenz Quack)
Date: Tue, 05 Aug 2014 16:13:15 +0000
Subject: [New-bugs-announce] [issue22143] rlcompleter.Completer has
	duplicate matches
Message-ID: <1407255195.5.0.870338576239.issue22143@psf.upfronthosting.co.za>


New submission from Lorenz Quack:

Example:
>>> import rlcompleter
>>> completer = rlcompleter.Completer()
>>> class A(object):
...     foo = None
>>> class B(A):
...     pass
>>> b = B()
>>> print([completer.complete("b.foo", i) for i in range(4)])
['b.foo', 'b.foo', 'b.foo', None]

I would expect the completions to be unique.
This happens because the possible words to match are put into a list.
A possible fix is putting them into a set instead.
Patch attached.

----------
components: Library (Lib)
files: rlcompleter.diff
keywords: patch
messages: 224852
nosy: donlorenzo
priority: normal
severity: normal
status: open
title: rlcompleter.Completer has duplicate matches
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36268/rlcompleter.diff

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

From report at bugs.python.org  Tue Aug  5 18:30:10 2014
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Ren=C3=A9_Rideau?=)
Date: Tue, 05 Aug 2014 16:30:10 +0000
Subject: [New-bugs-announce] [issue22144] ellipsis needs better display in
	lexer documentation
Message-ID: <1407256210.06.0.54083612565.issue22144@psf.upfronthosting.co.za>


New submission from Fran?ois-Ren? Rideau:

As a followup to http://bugs.python.org/issue21972

The ellipsis (three dots) should be displayed in the box on top of section 2.6 of the reference manual, and not just in the text below:
https://docs.python.org/3.5/reference/lexical_analysis.html

----------
messages: 224854
nosy: Fran?ois-Ren?.Rideau
priority: normal
severity: normal
status: open
title: ellipsis needs better display in lexer documentation
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug  5 18:35:23 2014
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Ren=C3=A9_Rideau?=)
Date: Tue, 05 Aug 2014 16:35:23 +0000
Subject: [New-bugs-announce] [issue22145] <> in parser spec but not lexer
	spec
Message-ID: <1407256523.86.0.758013450113.issue22145@psf.upfronthosting.co.za>


New submission from Fran?ois-Ren? Rideau:

As another follow up to http://bugs.python.org/issue21972

<> is mentioned in the parser spec: https://docs.python.org/3.5/reference/grammar.html
But not in the lexer spec: https://docs.python.org/3.5/reference/lexical_analysis.html

Either is a mistake.

I suggested in issue 21972 that the former was the bug, because it referred to a joke PEP and because <> doesn't actually work as a comparator in Python 3.4. The response by loewis was that the parser documentation was correct ? well then the lexer documentation is incorrect.

----------
assignee: docs at python
components: Documentation
messages: 224856
nosy: Fran?ois-Ren?.Rideau, docs at python, loewis
priority: normal
severity: normal
status: open
title: <> in parser spec but not lexer spec
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug  5 20:54:45 2014
From: report at bugs.python.org (A Kaptur)
Date: Tue, 05 Aug 2014 18:54:45 +0000
Subject: [New-bugs-announce] [issue22146] Error message for __build_class__
	contains typo
Message-ID: <1407264885.08.0.937298200249.issue22146@psf.upfronthosting.co.za>


New submission from A Kaptur:

One of the error messages for __build_class__ has an extra underscore in the middle.

----------
files: build_class_typo.patch
keywords: patch
messages: 224874
nosy: akaptur
priority: low
severity: normal
status: open
title: Error message for __build_class__ contains typo
versions: Python 3.4
Added file: http://bugs.python.org/file36272/build_class_typo.patch

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

From report at bugs.python.org  Tue Aug  5 21:44:08 2014
From: report at bugs.python.org (Isaac Schwabacher)
Date: Tue, 05 Aug 2014 19:44:08 +0000
Subject: [New-bugs-announce] [issue22147] PosixPath() constructor should not
	accept strings with	embedded NUL bytes
Message-ID: <1407267848.45.0.809324931091.issue22147@psf.upfronthosting.co.za>


New submission from Isaac Schwabacher:

This is listed as a python3.4 issue even though I only tried this on the python2.7 backport because I don't have a python3 handy, but I was not able to find an indication, either here or elsewhere, that this had been addressed.  Please forgive me if it has.

The `pathlib.PosixPath()` constructor currently accepts strings containing NUL bytes, converting them into paths containing NUL bytes. POSIX specifies that a pathname may not contain embedded NULs.

It appears that `PosixPath.stat()` is checking for embedded NUL, but `PosixPath.open()` is not!  For safety, constructing a `PosixPath` with embedded NULs should be forbidden.

`pathlib.WindowsPath()` should probably receive the same treatment.

Observed behavior:

```python

>>> from pathlib import Path

>>> Path("\0I'm not malicious, I'm mischievous!")
PosixPath("\x00I'm not malicious, I'm mischievous!")

>>> _.open()
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File ".../site-packages/pathlib.py", line 1077, in open
 return io.open(str(self), mode, buffering, encoding, errors, newline)
IOError: [Errno 2] No such file or directory: ''

>>> Path('/') / _
PosixPath("/\x00I'm not malicious, I'm mischievous!")

>>> _.open()
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File ".../site-packages/pathlib.py", line 1077, in open
 return io.open(str(self), mode, buffering, encoding, errors, newline)
IOError: [Errno 21] Is a directory: "/\x00I'm not malicious, I'm mischievous!"

>>> _.stat()
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File ".../site-packages/pathlib.py", line 1051, in stat
 return self._accessor.stat(self)
 File ".../site-packages/pathlib.py", line 346, in wrapped
 return strfunc(str(pathobj), *args)
TypeError: must be encoded string without NULL bytes, not str

>>> p1 = Path('/etc/passwd\0/hello.txt').open()

>>> p2 = Path('/etc/passwd').open()

>>> os.path.sameopenfile(p1.fileno(), p2.fileno())
True  # DANGER WILL ROBINSON!

```

Expected behavior:

```python

>>> Path("/\0I'm not malicious, I'm mischievous!")
...
ValueError: Illegal byte '\x00' in path

```

----------
messages: 224880
nosy: ischwabacher
priority: normal
severity: normal
status: open
title: PosixPath() constructor should not accept strings with embedded NUL bytes
type: security
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  5 22:32:50 2014
From: report at bugs.python.org (John Beck)
Date: Tue, 05 Aug 2014 20:32:50 +0000
Subject: [New-bugs-announce] [issue22148] frozen.c should #include
	<importlib.h> instead of	"importlib.h"
Message-ID: <1407270770.77.0.054260844743.issue22148@psf.upfronthosting.co.za>


New submission from John Beck:

Background: on Solaris, we build Python and various modules 64-bit. To
make this work with our general 64-bit changes, we use foo/64 as the path
for our shared objects (.so files) rather than foo, for various values
of foo (e.g., "/usr/lib", "/usr/lib/python3.4", etc.).  We had to tweak
Lib/importlib/_bootstrap.py to implement this.  In so doing, we learned
that Python/frozen.o does not pick up this change.  The reason is that
Python/frozen.c has a #include of "importlib.h".  But because of the
quotes, it looks in the same directory for importlib.h .  But when we
rebuild importlib.h (via _freeze_importlib), the rebuilt importlib.h is
placed into our build dir, not $srcdir.  But '#include "importlib.h"'
looks first for $srcdir/Python/importlib.h, finds the old one, then
uses it without finding the rebuilt one over in the build dir.

Although the description of the problem is rather convoluted, the fix is
fortunately extremely simple: change "importlib.h" to <importlib.h>, i.e.,
change the quotes to angle-brackets, per the attached patch.

----------
components: Interpreter Core
files: frozen-path.patch
keywords: patch
messages: 224885
nosy: jbeck
priority: normal
severity: normal
status: open
title: frozen.c should #include <importlib.h> instead of "importlib.h"
versions: Python 3.4
Added file: http://bugs.python.org/file36276/frozen-path.patch

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

From report at bugs.python.org  Tue Aug  5 22:39:23 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 05 Aug 2014 20:39:23 +0000
Subject: [New-bugs-announce] [issue22149] the frame of a suspended generator
	should not have a	local trace function
Message-ID: <1407271163.94.0.203518620414.issue22149@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

When tracing, the frame of a suspended generator should not have an f_trace function as there is no way to delete the frame f_trace attribute in that case even though
tracing may have been disabled.

The patch relies on the fact that whenever the generator is resumed, a 'call' tracing event is issued and the generator's frame f_trace is set again.
As expected, frames, including generators' frames, have their f_trace attribute cleared on the 'return' tracing event that is issued when the frame goes out of scope
or when the system's trace function has been removed.

----------
components: Interpreter Core
files: generator_f_trace.patch
keywords: patch
messages: 224887
nosy: xdegaye
priority: normal
severity: normal
status: open
title: the frame of a suspended generator should not have a local trace function
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file36277/generator_f_trace.patch

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

From report at bugs.python.org  Wed Aug  6 06:20:43 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 06 Aug 2014 04:20:43 +0000
Subject: [New-bugs-announce] [issue22150] deprecated-removed directive is
	broken in Sphinx 1.2.2
Message-ID: <1407298843.86.0.170034471858.issue22150@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The attached patch fixes the problem for me. Tested with Firefox 30.0 and Chrome 35.0.1916.153 on Ubuntu.

----------
components: Demos and Tools
files: deprecated-removed.diff
keywords: patch
messages: 224902
nosy: berker.peksag, georg.brandl
priority: normal
severity: normal
stage: patch review
status: open
title: deprecated-removed directive is broken in Sphinx 1.2.2
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36281/deprecated-removed.diff

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

From report at bugs.python.org  Wed Aug  6 07:00:02 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Aug 2014 05:00:02 +0000
Subject: [New-bugs-announce] [issue22153] There is no standard
	TestCase.runTest implementation
Message-ID: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation for "unittest.TestCase" says "the standard implementation of the default 'methodName', runTest(), will run every method starting with 'test' as an individual test". However:

>>> from unittest import *
>>> class Test(TestCase):
...     def test_method(self): pass
... 
>>> t = Test()
>>> t.run()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/unittest/case.py", line 552, in run
    testMethod = getattr(self, self._testMethodName)
AttributeError: 'Test' object has no attribute 'runTest'

After further experimentation, I see that if my test method is called "runTest", it can be automatically discovered, but only if there are no other test- prefixed methods.

Perhaps you could drop the end of the second paragraph for TestCase, so that it just reads:

Each instance of TestCase will run a single base method: the method named "methodName".

I think the details about the test- prefix and counting results are covered elsewhere, and in most uses you wouldn't instantiate a TestCase yourself, so changing the method name is irrelevant.

Also, perhaps under "TestLoader.loadTestsFromTestCase" it should say:

If no methods with the usual name prefix are found, but the "runTest" method is implemented, there will be a single test case using that method.

----------
assignee: docs at python
components: Documentation
messages: 224907
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: There is no standard TestCase.runTest implementation
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug  6 09:56:40 2014
From: report at bugs.python.org (Ralph Broenink)
Date: Wed, 06 Aug 2014 07:56:40 +0000
Subject: [New-bugs-announce] [issue22154] ZipFile.open context manager
	support
Message-ID: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>


New submission from Ralph Broenink:

In Python 3.2, context manager support for ZipFile was added. However, I would also love the ability for ``ZipFile.open`` to be used as a context manager, e.g.:

    from zipfile import ZipFile
    with ZipFile("test.zip", "r") as z:
        with z.open("test.txt", "r") as f:
            print(f.read())

----------
components: Extension Modules
messages: 224914
nosy: Ralph.Broenink
priority: normal
severity: normal
status: open
title: ZipFile.open context manager support
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug  6 12:18:37 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Aug 2014 10:18:37 +0000
Subject: [New-bugs-announce] [issue22155] Out of date code example for
	tkinter's createfilehandle
Message-ID: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>


New submission from Martin Panter:

The only documentation on ?createfilehandle? and friends that I can find looks like it needs updating:

https://docs.python.org/release/3.4.0/faq/gui.html#can-i-have-tk-events-handled-while-waiting-for-i-o

I have been using the equivalent of this instead, for both Python 2 and 3:

import tkinter
widget = tkinter.Tk()
widget.tk.createfilehandler(file, tkinter.READABLE | tkinter.WRITABLE, callback)
...
widget.tk.deletefilehandler(file)

However I have no idea if this is a supported, proper way, if one even still exists. The old way was removed by Issue 3638.

BTW, there is a link to release/3.4.1 documentation but that returned a 404 error for me, so I linked to the 3.4.0 doc instead.

----------
assignee: docs at python
components: Documentation, Tkinter
messages: 224922
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Out of date code example for tkinter's createfilehandle
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug  6 12:38:10 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Aug 2014 10:38:10 +0000
Subject: [New-bugs-announce] [issue22156] Fix compiler warnings
Message-ID: <1407321490.98.0.896409161312.issue22156@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #22110 enabled more compiler warnings. Attached patch tries to fix most of them on Linux.

----------
files: fix_warnings.patch
keywords: patch
messages: 224924
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: Fix compiler warnings
versions: Python 3.5
Added file: http://bugs.python.org/file36287/fix_warnings.patch

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

From report at bugs.python.org  Wed Aug  6 14:37:48 2014
From: report at bugs.python.org (snehal)
Date: Wed, 06 Aug 2014 12:37:48 +0000
Subject: [New-bugs-announce] [issue22157] FAIL: test_with_pip
	(test.test_venv.EnsurePipTest)
Message-ID: <1407328668.69.0.785402496227.issue22157@psf.upfronthosting.co.za>


New submission from snehal:

On ppc64le architecture I see following error with 
TAR :  https://www.python.org/ftp/python/3.4.1/Python-3.4.1.tar.xz


======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ubuntu/python/Python-3.4.1/Lib/test/test_venv.py", line 352, in test_with_pip
    with_pip=True)
subprocess.CalledProcessError: Command '['/tmp/tmpge5lfrua/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ubuntu/python/Python-3.4.1/Lib/test/test_venv.py", line 358, in test_with_pip
    self.fail(msg.format(exc, details))
AssertionError: Command '['/tmp/tmpge5lfrua/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

**Subprocess Output**
Traceback (most recent call last):
  File "/home/ubuntu/python/Python-3.4.1/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/ubuntu/python/Python-3.4.1/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/ubuntu/python/Python-3.4.1/Lib/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/home/ubuntu/python/Python-3.4.1/Lib/ensurepip/__init__.py", line 209, in _main
    default_pip=args.default_pip,
  File "/home/ubuntu/python/Python-3.4.1/Lib/ensurepip/__init__.py", line 116, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/home/ubuntu/python/Python-3.4.1/Lib/ensurepip/__init__.py", line 40, in _run_pip
    import pip
  File "/tmp/tmpn9zaabpk/pip-1.5.6-py2.py3-none-any.whl/pip/__init__.py", line 9, in <module>
  File "/tmp/tmpn9zaabpk/pip-1.5.6-py2.py3-none-any.whl/pip/log.py", line 9, in <module>
  File "/tmp/tmpn9zaabpk/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/__init__.py", line 2, in <module>
  File "/tmp/tmpn9zaabpk/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/initialise.py", line 5, in <module>
  File "/tmp/tmpn9zaabpk/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/ansitowin32.py", line 6, in <module>
  File "/tmp/tmpn9zaabpk/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/winterm.py", line 2, in <module>
  File "/tmp/tmpn9zaabpk/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/win32.py", line 7, in <module>
  File "/home/ubuntu/python/Python-3.4.1/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: No module named '_ctypes'


----------------------------------------------------------------------
Ran 13 tests in 0.561s

FAILED (failures=1)
test test_venv failed
make: *** [test] Error

----------
components: Tests
messages: 224930
nosy: snehal
priority: normal
severity: normal
status: open
title: FAIL: test_with_pip (test.test_venv.EnsurePipTest)
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug  6 21:07:56 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Wed, 06 Aug 2014 19:07:56 +0000
Subject: [New-bugs-announce] [issue22158] RFC 6531 (SMTPUTF8) support in
	smtpd.PureProxy
Message-ID: <1407352076.6.0.272779806488.issue22158@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

This issue depends on issue 21725 for the communication with the client and issue 22027 for communicating with the remote server.
I think I can come up with a patch for the default branch which is applicable but will not run without the two other issues beeing fixed (I tried that for issue 21783 but it didn't work out well).

----------
components: Library (Lib)
messages: 224963
nosy: jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: RFC 6531 (SMTPUTF8) support in smtpd.PureProxy
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug  6 23:08:27 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Wed, 06 Aug 2014 21:08:27 +0000
Subject: [New-bugs-announce] [issue22159] smtpd.PureProxy and
	smtpd.DebuggingServer do not work	with decode_data=True
Message-ID: <1407359307.97.0.457936656417.issue22159@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

I fixed this for smtpd.DebuggingServer in the patch for issue 21725 but think it is an independent issue which is resolvable with a small patch.

----------
components: Library (Lib)
files: decode_data_proxy_debugging_server.patch
keywords: patch
messages: 224967
nosy: jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: smtpd.PureProxy and smtpd.DebuggingServer do not work with decode_data=True
versions: Python 3.5
Added file: http://bugs.python.org/file36293/decode_data_proxy_debugging_server.patch

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

From report at bugs.python.org  Thu Aug  7 01:36:56 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 06 Aug 2014 23:36:56 +0000
Subject: [New-bugs-announce] [issue22160] Windows installers need to be
	updated following OpenSSL	security reelase
Message-ID: <1407368216.11.0.739238471572.issue22160@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://www.openssl.org/news/secadv_20140806.txt

----------
components: Interpreter Core, Library (Lib)
keywords: security_issue
messages: 224976
nosy: alex, benjamin.peterson, steve.dower
priority: normal
severity: normal
status: open
title: Windows installers need to be updated following OpenSSL security reelase
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug  7 11:12:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Aug 2014 09:12:21 +0000
Subject: [New-bugs-announce] [issue22161] Remove unsupported code from ctypes
Message-ID: <1407402741.94.0.893062545823.issue22161@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some ctypes functions by mistake accept wrong types which then rejected by internal functions. This is mainly remnants of 2.x where both str and unicode was accepted and then automatically converted to right type.

----------
assignee: serhiy.storchaka
components: ctypes
files: ctype_bytes_checks-3.4.patch
keywords: patch
messages: 224999
nosy: amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove unsupported code from ctypes
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36297/ctype_bytes_checks-3.4.patch

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

From report at bugs.python.org  Thu Aug  7 11:55:45 2014
From: report at bugs.python.org (Daniel Lintott)
Date: Thu, 07 Aug 2014 09:55:45 +0000
Subject: [New-bugs-announce] [issue22162] Actiavting a venv - Dash doesn't
	understand source
Message-ID: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>


New submission from Daniel Lintott:

In the documentation for venv (https://docs.python.org/3.5/library/venv.html) it gives examples for activating the venv under bash/zsh.

For a long time under both Debian and Ubuntu the default shell has been Dash (https://wiki.ubuntu.com/DashAsBinSh)

Dash doesn't undertsand the command 'source' so instead the venv must be activated using the . command (as is done for Fish, but using the bash activate file instead)

----------
assignee: docs at python
components: Documentation
messages: 225001
nosy: dlintott, docs at python
priority: normal
severity: normal
status: open
title: Actiavting a venv - Dash doesn't understand source
type: enhancement

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

From report at bugs.python.org  Thu Aug  7 13:02:32 2014
From: report at bugs.python.org (Eduardo Robles Elvira)
Date: Thu, 07 Aug 2014 11:02:32 +0000
Subject: [New-bugs-announce] [issue22163] max_wbits set incorrectly to
	-zlib.MAX_WBITS in tarfile, shouldn't be negative
Message-ID: <1407409352.24.0.421737248606.issue22163@psf.upfronthosting.co.za>


New submission from Eduardo Robles Elvira:

I think I have found a small typo-bug in tarfile.py, that seems to
be present in cpython upstream, which makes tarfile compression slower.
The issue can be seen here, in line 415 [1] of tarfile.py:

        self.cmp = self.zlib.compressobj(9, self.zlib.DEFLATED,
                                            -self.zlib.MAX_WBITS,
                                            self.zlib.DEF_MEM_LEVEL,
                                            0)

The minus sign doesn't make sense to me, because zlib.MAX_WBITS is 15,
and according to the documentation [2] wbits is by default 15 and
"This should be an integer from 8 to 15. Higher values give better
compression, but use more memory". -15 is not even in range. So I guess the expected value should be the zlib default, 15. Or maybe another value, but it should at least be in range. 

I marked it as "performance" type bug as this only really affects performance.

I might have gotten it all wrong and it's fine the way it is, but I thought it'd be best to report it, as it looked fishy to me.

--
[1] http://hg.python.org/cpython/file/94d0e842b9ea/Lib/tarfile.py#l415
[2] https://docs.python.org/3.4/library/zlib.html#zlib.compressobj

----------
components: Library (Lib)
files: max_wbits.patch
keywords: patch
messages: 225006
nosy: edulix
priority: normal
severity: normal
status: open
title: max_wbits set incorrectly to -zlib.MAX_WBITS in tarfile, shouldn't be negative
type: performance
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36299/max_wbits.patch

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

From report at bugs.python.org  Thu Aug  7 16:32:39 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2014 14:32:39 +0000
Subject: [New-bugs-announce] [issue22164] cell object cleared too early?
Message-ID: <1407421959.83.0.174061439532.issue22164@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is a tricky issue I'm sometimes seeing when running Numba's test suite, and I can't seem to write a reproducer. Somtimes I'm seeing the following messages:

Exception ignored in: <function _OverloadedBase._make_finalizer.<locals>.finalizer at 0x7f1466487c80>
Traceback (most recent call last):
  File "/home/antoine/numba/numba/dispatcher.py", line 59, in finalizer
    if shutting_down():
NameError: free variable 'shutting_down' referenced before assignment in enclosing scope

So what does it correspond to? The code is here:
https://github.com/numba/numba/blob/master/numba/dispatcher.py#L47

Basically, there's no way 'shutting_down' can be referenced before assignment... except if it has been cleared. And the only thing which can clear it here is the GC (namely, cell objects' tp_clear() method).

I'm not sure what the exact trigger for reproduction is. It does have to feature a reference cycle involving the closure; perhaps the trashcan mechanism comes into play as well. Also, the closure must be invoked on collection of something in the cycle, so a weakref callback could be nice.

----------
messages: 225012
nosy: pitrou, tim.peters
priority: normal
severity: normal
status: open
title: cell object cleared too early?
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug  7 17:06:33 2014
From: report at bugs.python.org (Josh Lee)
Date: Thu, 07 Aug 2014 15:06:33 +0000
Subject: [New-bugs-announce] [issue22165] Empty response from http.server
	when directory listing	contains invalid unicode
Message-ID: <1407423993.73.0.218384565957.issue22165@psf.upfronthosting.co.za>


New submission from Josh Lee:

While SimpleHTTPServer from Python2 would happily spit out whatever bytes were in the directory listing, Python3's http.server logs an error and closes the connection without responding to the HTTP request.

$ mkdir $'\xff'
$ ls
\377/
$ python3 -m http.server 
Serving HTTP on 0.0.0.0 port 8000 ...
----------------------------------------
Exception happened during processing of request from ('74.125.59.145', 19648)
Traceback (most recent call last):
  File "/home/josh/local/lib/python3.5/socketserver.py", line 321, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/josh/local/lib/python3.5/socketserver.py", line 347, in process_request
    self.finish_request(request, client_address)
  File "/home/josh/local/lib/python3.5/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/josh/local/lib/python3.5/socketserver.py", line 681, in __init__
    self.handle()
  File "/home/josh/local/lib/python3.5/http/server.py", line 398, in handle
    self.handle_one_request()
  File "/home/josh/local/lib/python3.5/http/server.py", line 386, in handle_one_request
    method()
  File "/home/josh/local/lib/python3.5/http/server.py", line 677, in do_GET
    f = self.send_head()
  File "/home/josh/local/lib/python3.5/http/server.py", line 716, in send_head
    return self.list_directory(path)
  File "/home/josh/local/lib/python3.5/http/server.py", line 772, in list_directory
    % (urllib.parse.quote(linkname), html.escape(displayname)))
  File "/home/josh/local/lib/python3.5/urllib/parse.py", line 688, in quote
    string = string.encode(encoding, errors)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 0: surrogates not allowed
----------------------------------------

----------
components: Library (Lib)
messages: 225016
nosy: durin42, jleedev
priority: normal
severity: normal
status: open
title: Empty response from http.server when directory listing contains invalid unicode
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug  7 22:49:27 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 07 Aug 2014 20:49:27 +0000
Subject: [New-bugs-announce] [issue22166] test_codecs "leaking" references
Message-ID: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za>


New submission from Zachary Ware:

After 9bca86812857 (#22104), test_codecs now reports "leaked" references from ExceptionChainingTest.  Previously the tests were only ever loaded one time, so each run of the tests was actually using the same set of TestCase instances; now the tests are freshly loaded before every test run and thus each run uses a new set of TestCase instances.  My suspicion is that this is coming into play in ExceptionChainingTest.setUp, where the test's codec_name attribute is derived from the repr and id of the TestCase instance.  However, I'm not familiar enough with the codecs code to know where it's going wrong from there.

One possible "fix" is to abuse load_tests to ensure the tests are only loaded once:

_suite = None

def load_tests(loader, suite, pattern):
    global _suite
    if _suite is None:
        _suite = suite
    return _suite

...which restores the old behavior, but strikes me as a fairly horrible hack.  Somewhat less bad would be to just skip those tests when they've already been run before.  I can't help but feel that there has to be a better solution that I can't see, though.

Nick, as the original author of the test class in question, do you have any insight into a better way to fix the "leaks"?

----------
components: Tests
messages: 225040
nosy: brett.cannon, ncoghlan, zach.ware
priority: normal
severity: normal
status: open
title: test_codecs "leaking" references
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Aug  8 03:09:01 2014
From: report at bugs.python.org (Roy Smith)
Date: Fri, 08 Aug 2014 01:09:01 +0000
Subject: [New-bugs-announce] [issue22167] iglob() has misleading
	documentation (does indeed store	names internally)
Message-ID: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za>


New submission from Roy Smith:

For background, see:

https://mail.python.org/pipermail/python-list/2014-August/676291.html

In a nutshell, the iglob() docs say, "Return an iterator which yields the same values as glob() without actually storing them all simultaneously."  The problem is, internally, it calls os.listdir(), which apparently *does* store the entire list internally, defeating the whole purpose of iglob()

I recognize that iglob() is not going to get fixed in 2.7, but at least the documentation should be updated to point out that it doesn't really do what it says it does.  Or rather, it doesn't really not do what it says it doesn't :-)

----------
assignee: docs at python
components: Documentation
messages: 225048
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: iglob() has misleading documentation (does indeed store names internally)
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  8 03:27:43 2014
From: report at bugs.python.org (Kent D. Lee)
Date: Fri, 08 Aug 2014 01:27:43 +0000
Subject: [New-bugs-announce] [issue22168] Turtle Graphics RawTurtle problem
Message-ID: <1407461263.41.0.42681300045.issue22168@psf.upfronthosting.co.za>


New submission from Kent D. Lee:

This is either a turtle graphics or tkinter problem. 

In Python 3.4 it appears that something in Turtle Graphics broke or at least changed. I get the following error when trying to run a program that works in Python 3.1 and 3.2.

Kent's Mac> python3.4 c4.py
Traceback (most recent call last):
  File "c4.py", line 283, in <module>
    main()
  File "c4.py", line 277, in main
    animApp = Connect4Application(root)
  File "c4.py", line 110, in __init__
    self.buildWindow()
  File "c4.py", line 129, in buildWindow
    theTurtle = turtle.RawTurtle(canvas)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/turtle.py", line 2534, in __init__
    self.screen = TurtleScreen(canvas)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/turtle.py", line 1000, in __init__
    cv._rootwindow.call('wm', 'attributes', '.', '-topmost', '1')
AttributeError: 'Canvas' object has no attribute '_rootwindow'
Kent's Mac> 

The code is attached. The error occurs on line 129 when trying to create a RawTurtle and provide it with a Canvas.

----------
components: Tkinter
files: c4.py
messages: 225049
nosy: Kent.D..Lee
priority: normal
severity: normal
status: open
title: Turtle Graphics RawTurtle problem
versions: Python 3.4
Added file: http://bugs.python.org/file36307/c4.py

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

From report at bugs.python.org  Fri Aug  8 05:24:54 2014
From: report at bugs.python.org (Orson Peters)
Date: Fri, 08 Aug 2014 03:24:54 +0000
Subject: [New-bugs-announce] [issue22169] sys.tracebacklimit = 0 does not
	work as documented in 3.x
Message-ID: <1407468294.35.0.178254047495.issue22169@psf.upfronthosting.co.za>


New submission from Orson Peters:

According to the documentation of sys.tracebacklimit, setting it to 0 or less would assure "all traceback information is suppressed and only the exception type and value are printed".

This is not the case:

    $ python -c "import sys; sys.tracebacklimit = 0; raise Exception()"
    Exception

    $ python3 -c "import sys; sys.tracebacklimit = 0; raise Exception()"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    Exception

----------
components: Interpreter Core
messages: 225055
nosy: orlp
priority: normal
severity: normal
status: open
title: sys.tracebacklimit = 0 does not work as documented in 3.x
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/issue22169>
_______________________________________

From report at bugs.python.org  Fri Aug  8 05:26:17 2014
From: report at bugs.python.org (Susan Tan)
Date: Fri, 08 Aug 2014 03:26:17 +0000
Subject: [New-bugs-announce] [issue22170] Typo in iterator doc
Message-ID: <1407468377.55.0.545687415871.issue22170@psf.upfronthosting.co.za>


New submission from Susan Tan:

Typo in last line: 

for line in open("myfile.txt"):
    print line,

Instead there should be no extra "," character in "print line,"

----------
assignee: docs at python
components: Documentation
messages: 225056
nosy: Susan, docs at python
priority: normal
severity: normal
status: open
title: Typo in iterator doc
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  8 06:53:59 2014
From: report at bugs.python.org (Wesley Kerfoot)
Date: Fri, 08 Aug 2014 04:53:59 +0000
Subject: [New-bugs-announce] [issue22171] stack smash when using
	ctypes/libffi to access union
Message-ID: <1407473639.16.0.026036901704.issue22171@psf.upfronthosting.co.za>


New submission from Wesley Kerfoot:

Description:
python 2.7.8 fails with a 'stack smashing detected' error and aborts when trying to access a C union using ctypes/libffi

Steps to reproduce:
See the contents of test.c and test.py in the attached file
gcc -c -fpic -Wall -Wextra -pedantic -Wpointer-arith -Werror -std=c99 -O0 ./test.c -o test.o
gcc -shared -o test.so test.o
python2 test.py

Also fails with clang instead of gcc.

OS: Linux frege 3.15.8-1-ARCH #1 SMP PREEMPT Fri Aug 1 08:51:42 CEST 2014 x86_64 GNU/Linux
python2 version: 2.7.8
libffi version (OS wide version): 3.1-2
gcc version: 4.9.1
clang version: 3.4.2

I have tried rebuilding python with the included version of libffi (Arch normally uses a systemwide version).

Here is the PKGBUILD file Arch uses https://projects.archlinux.org/svntogit/packages.git/tree/python2/trunk/PKGBUILD?id=c319b32ada1506cf2bd48acc50649ae77a696c53

I have also reported this bug on their tracker since I am not sure if this is a bug in ctypes or libffi or both: https://bugs.archlinux.org/task/41502

----------
components: ctypes
files: crash.log
messages: 225059
nosy: amaury.forgeotdarc, belopolsky, meador.inge, wjak56
priority: normal
severity: normal
status: open
title: stack smash when using ctypes/libffi to access union
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file36308/crash.log

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

From report at bugs.python.org  Fri Aug  8 11:32:10 2014
From: report at bugs.python.org (Daniel Thomas)
Date: Fri, 08 Aug 2014 09:32:10 +0000
Subject: [New-bugs-announce] [issue22172] Local files shadow system modules,
	even from system modules
Message-ID: <1407490330.0.0.140358266083.issue22172@psf.upfronthosting.co.za>


New submission from Daniel Thomas:

In Python 3.4 (but not 3.2 or 2.7) when a system module does an import then files with the same name in the directory of the original python script which match that name are used.

E.g.
With a directory containing:
test.py:
    #!/usr/bin/env python3
    from collections import OrderedDict
    print('do stuff')

operator.py:
    #!/usr/bin/env python3
    print('EXPLOIT!')

Running test.py will cause:
EXPLOIT!
Traceback (most recent call last):
  File "./test.py", line 4, in <module>
    from collections import OrderedDict
  File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>
    from operator import itemgetter as _itemgetter, eq as _eq
ImportError: cannot import name 'itemgetter'


While test.py is perfectly innocent it is in the same directory as the nasty operator.py and test.py makes no reference at all to operator.py but when 'collections' is imported it imports from operator which is resolved to operator.py in the local directory

This is a security vulnerability because it is possible to verify that a python script is safe to run by reading its code and then on running it find that other code is implicitly loaded by the system libraries which is never referenced in the original file or part of any of the standard libraries.

It is also rather confusing but a related issue is already filed for that in issue21202.
This is similar to the standard name shadowing trap http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#the-name-shadowing-trap but now applies to other files in the source directory in a way which it didn't in previous versions of python. I suspect this was introduced in python 3.3 through changes to the import system and __init__.py becoming optional but I don't have a 3.3 install to check that with.


sys.path here is: ['/auto/homes/drt24/pythontest', '/usr/lib/python3.4', '/usr/lib/python3.4/plat-x86_64-linux-gnu', '/usr/lib/python3.4/lib-dynload', '/usr/local/lib/python3.4/dist-packages', '/usr/lib/python3/dist-packages']
Running Python 3.4.0-0ubuntu2 on Ubuntu 14.04.1 LTS with Linux 3.13.0-32-generic

----------
components: Interpreter Core
messages: 225065
nosy: drt24
priority: normal
severity: normal
status: open
title: Local files shadow system modules, even from system modules
type: security
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  8 16:08:01 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 08 Aug 2014 14:08:01 +0000
Subject: [New-bugs-announce] [issue22173] Update lib2to3.tests and
	test_lib2to3 to use test	discovery
Message-ID: <1407506881.47.0.548658817568.issue22173@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch updates lib2to3.tests and the test.test_lib2to3 script to use test discovery.  It also re-enables lib2to3.tests.test_all_fixers with a "cpu" resource guard.  That test has been failing since at least 3.2, but was never run anyway.  To allow it to pass, the patch adds "from __future__ import print_function" to lib2to3.main and lib2to3.tests.pytree_idempotency.

----------
components: 2to3 (2.x to 3.x conversion tool), Tests
files: test_lib2to3_discovery.diff
keywords: patch
messages: 225072
nosy: zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Update lib2to3.tests and test_lib2to3 to use test discovery
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36310/test_lib2to3_discovery.diff

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

From report at bugs.python.org  Fri Aug  8 22:48:59 2014
From: report at bugs.python.org (diana)
Date: Fri, 08 Aug 2014 20:48:59 +0000
Subject: [New-bugs-announce] [issue22174] property doc fixes
Message-ID: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>


New submission from diana:

The property docs are a bit funky.

    https://docs.python.org/3/library/functions.html#property

1) docstrings have zero to do with making a read-only property. It currently says:

"If given, doc will be the docstring of the property attribute. Otherwise, the property will copy fget?s docstring (if it exists). This makes it possible to create read-only properties easily using property() as a decorator:"

2) The 'then' in this sentence is awkward (and incorrect English).

"If then c is an instance of C, c.x will invoke the getter, c.x = value will invoke the setter and del c.x the deleter."

3) This sentence is missing a beginning.

"turns the voltage() method into a ?getter? for a read-only attribute with the same name."

4) This sentence has an extra comma (after del'ing):

"fget is a function for getting an attribute value, likewise fset is a function for setting, and fdel a function for del?ing, an attribute."

Attached is a patch with minimal changes to the property docs, addressing the above four issues. Okay, that's not entirely true -- I did add an example usage because the current docs don't actually show using a property attribute.

>>> p = Parrot()
>>> p.voltage
100000

I've also attached an "after" screenshot of the docs in case it helps with review.

Cheers,

--diana

----------
assignee: docs at python
components: Documentation
files: property_docs.patch
keywords: patch
messages: 225086
nosy: diana, docs at python
priority: normal
severity: normal
status: open
title: property doc fixes
versions: Python 3.5
Added file: http://bugs.python.org/file36318/property_docs.patch

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

From report at bugs.python.org  Sat Aug  9 00:07:50 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 08 Aug 2014 22:07:50 +0000
Subject: [New-bugs-announce] [issue22175] improve test_faulthandler
	readability with dedent
Message-ID: <1407535670.93.0.160044104545.issue22175@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

'test_faulthandler.patch' uses dedent to have triple-quoted strings in indented form. This allows viewing the source code with the folding tools available with some editors.

'test_faulthandler.diff' is the result of 'hg diff --ignore-all-space' and may be used to ensure that the changes made by the patch only affect the presentation of test_faulthandler.py.

----------
components: Library (Lib)
files: test_faulthandler.patch
keywords: patch
messages: 225091
nosy: haypo, xdegaye
priority: normal
severity: normal
status: open
title: improve test_faulthandler readability with dedent
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36321/test_faulthandler.patch

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

From report at bugs.python.org  Sat Aug  9 21:53:52 2014
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 09 Aug 2014 19:53:52 +0000
Subject: [New-bugs-announce] [issue22176] update internal libffi copy to 3.1,
	introducing AArch64 and POWER ELF ABIv2
Message-ID: <1407614032.19.0.619633143282.issue22176@psf.upfronthosting.co.za>


New submission from Matthias Klose:

tracking the import of libffi 3.1

----------
components: ctypes
messages: 225109
nosy: doko
priority: normal
severity: normal
status: open
title: update internal libffi copy to 3.1, introducing AArch64 and POWER ELF ABIv2
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug  9 23:59:44 2014
From: report at bugs.python.org (jp)
Date: Sat, 09 Aug 2014 21:59:44 +0000
Subject: [New-bugs-announce] [issue22177] Incorrect version reported after
	downgrade
Message-ID: <1407621584.41.0.669200940466.issue22177@psf.upfronthosting.co.za>


New submission from jp:

After downgrading from version 2.7.8 to 2.7.5 on Win7 x86 32bit Python, the interpreter continues to report version 2.7.8.

I have verified that the installation folder has the correct files belonging to 2.7.5 as evidenced by python.exe having a 2013 timestamp. 

Ran python -V at windows CMD and sys.version in interpreter, both report 2.7.8.

----------
messages: 225114
nosy: jpe5605
priority: normal
severity: normal
status: open
title: Incorrect version reported after downgrade
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 10 08:01:22 2014
From: report at bugs.python.org (sw)
Date: Sun, 10 Aug 2014 06:01:22 +0000
Subject: [New-bugs-announce] [issue22178] _winreg.QueryInfoKey Last Modified
	Time Value Incorrect	or Explanation Incorrect
Message-ID: <1407650482.35.0.308980176266.issue22178@psf.upfronthosting.co.za>


New submission from sw:

The explanation of the 3rd index of the tuple returned from _winreg.QueryInfoKey(key) explains that it is a long representing 100s of nanoseconds since 1/1/1600.

However, when I use this value and convert to the actual date using 
startDate = datetime(1600,1,1)
lastModified = QueryInfoKey(key)[2]
print "%s" % startDate + timedelta(seconds=lastModified*(10**-9)*100) 

The date is about right except for the year value, it's off by one.

I suspect the documentation should say the value in the tuple is the time since 1/1/1601 instead of 1/1/1600. This would corroborate Microsoft's documentation that makes references to 1/1/1601 (i.e. http://technet.microsoft.com/en-ca/aa393040(v=vs.90).aspx)

----------
messages: 225125
nosy: slw07g
priority: normal
severity: normal
status: open
title: _winreg.QueryInfoKey Last Modified Time Value Incorrect or Explanation Incorrect
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 10 14:01:02 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 10 Aug 2014 12:01:02 +0000
Subject: [New-bugs-announce] [issue22179] Focus stays on Search Dialog when
	text found in editor
Message-ID: <1407672062.65.0.813743837574.issue22179@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

As the title.  Even using the Find Next button doesn't get the focus on the found text so you can't see it, the Search Dialog has to be closed.  Windows 8.1 Python 3.4.1.

----------
components: IDLE
messages: 225138
nosy: BreamoreBoy, terry.reedy
priority: normal
severity: normal
status: open
title: Focus stays on Search Dialog when text found in editor
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug 10 16:18:24 2014
From: report at bugs.python.org (Michael Williamson)
Date: Sun, 10 Aug 2014 14:18:24 +0000
Subject: [New-bugs-announce] [issue22180] operator.setitem example no longer
	works in Python 3 due	to lazy map
Message-ID: <1407680304.87.0.195005785734.issue22180@psf.upfronthosting.co.za>


New submission from Michael Williamson:

The Python docs for the operator module include an example using map and setitem to "Build a dictionary that maps the ordinals from 0 to 255 to their character equivalents.":

    d = {}
    keys = range(256)
    vals = map(chr, keys)
    map(operator.setitem, [d]*len(keys), keys, vals)   

Since map is lazy since Python 3, the dictionary d is never actually changed in this example. I'm not entirely sure what the idiomatic way to fix the example is since it strikes me as being fairly unidiomatic to begin with, but the simplest would be to call list on the result of map to force evaluation (patch attached).

----------
assignee: docs at python
components: Documentation
files: doc-operator-example.patch
keywords: patch
messages: 225141
nosy: docs at python, mwilliamson
priority: normal
severity: normal
status: open
title: operator.setitem example no longer works in Python 3 due to lazy map
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36333/doc-operator-example.patch

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

From report at bugs.python.org  Mon Aug 11 01:32:43 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Aug 2014 23:32:43 +0000
Subject: [New-bugs-announce] [issue22181] os.urandom() should use Linux 3.17
	getrandom() syscall
Message-ID: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The future Linux kernel 3.17 will have a new getrandom() syscall which avoids the need of a file descriptor:
http://lwn.net/Articles/606141/

The file descriptor of os.urandom() causes perfomance issues and surprising bugs: #18756, #21207.

I don't know when the function will land in the libc.

OpenBSD 5.6 (not released yet) will also have a new getentropy() syscall.

For Python 2.7, see also the PEP 466 and the issue #21305.

----------
messages: 225171
nosy: haypo
priority: normal
severity: normal
status: open
title: os.urandom() should use Linux 3.17 getrandom() syscall
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug 11 14:38:56 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 11 Aug 2014 12:38:56 +0000
Subject: [New-bugs-announce] [issue22182] distutils.file_util.move_file
	unpacks wrongly an	exception
Message-ID: <1407760736.2.0.981302438241.issue22182@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hi. When os.rename fails inside distutils.file_util.move_file, the exception is unpacked using ``(num, msg) = e``. While this was valid in Python 2, in Python 3 it should be ``e.args``. The attached patched fixes this.

----------
components: Distutils
files: distutils_unpacking_exception.patch
keywords: patch
messages: 225184
nosy: Claudiu.Popa, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.file_util.move_file unpacks wrongly an exception
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file36345/distutils_unpacking_exception.patch

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

From report at bugs.python.org  Mon Aug 11 16:17:13 2014
From: report at bugs.python.org (Patrick Westerhoff)
Date: Mon, 11 Aug 2014 14:17:13 +0000
Subject: [New-bugs-announce] [issue22183] datetime.timezone methods require
	datetime object
Message-ID: <1407766633.4.0.589829089007.issue22183@psf.upfronthosting.co.za>


New submission from Patrick Westerhoff:

I?ve noticed that the methods in `datetime.timezone` all require a datetime object (or explicitely `None`) as its parameter or they will raise an exception.

The datetime object however is never required for the implementation of the method, so it seems to me like an unnecessary requirement, given that timezone objects are completely independent of datetime objects.

For example `timezone.utcoffset` is implemented like this:

    def utcoffset(self, dt):
        if isinstance(dt, datetime) or dt is None:
            return self._offset
        raise TypeError("utcoffset() argument must be a datetime instance"
                        " or None")

I don?t really understand this requirement and if there isn?t an actual reason for it (if there is, it should be documented somewhere), I?d suggest to remove this requirement completely. For backwards compatibility, the parameter could simply default to `None`.

----------
components: Library (Lib)
messages: 225188
nosy: poke
priority: normal
severity: normal
status: open
title: datetime.timezone methods require datetime object
type: behavior

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

From report at bugs.python.org  Mon Aug 11 21:53:01 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 11 Aug 2014 19:53:01 +0000
Subject: [New-bugs-announce] [issue22184] lrucache should reject maxsize as
	a function
Message-ID: <1407786781.71.0.524022287452.issue22184@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

In https://bitbucket.org/jaraco/backports.functools_lru_cache/issue/1/python-2-attributeerror-int-object-has-no, a user was confused when he tried to use the lrucache decorator incorrectly, passing the wrapped function directly to lrucache. Consider:

    @lrucache
    def expensive(param):
        pass

One can even get away with profiling that now decorated function:

    for x in range(10000):
        expensive(x)

The test will run without error, but it's not doing what the user thinks it's doing. In the first section, it's creating a decorator, and in the second section, it's wrapping an int in that decorator, but because the wrapper is never called, an error is never raised.

I propose adding a simple check that if maxsize is callable, raise a TypeError. That would prevent unintentional misuse and subtle non-failure with minimal impact on performance.

----------
components: Library (Lib)
messages: 225202
nosy: jason.coombs, rhettinger
priority: normal
severity: normal
status: open
title: lrucache should reject maxsize as a function

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

From report at bugs.python.org  Tue Aug 12 01:47:11 2014
From: report at bugs.python.org (Doug Zongker)
Date: Mon, 11 Aug 2014 23:47:11 +0000
Subject: [New-bugs-announce] [issue22185] Occasional RuntimeError from
	Condition.notify
Message-ID: <1407800831.15.0.236937632355.issue22185@psf.upfronthosting.co.za>


New submission from Doug Zongker:

Condition.wait() modifies self._waiters without holding the lock (when a wait with timeout times out without the condition being notified).

If this happens to occur in between construction of the _islice and _deque objects in Condition.notify():

    def notify(self, n=1):
        [...]
        all_waiters = self._waiters
        waiters_to_notify = _deque(_islice(all_waiters, n))

then the result is a RuntimeError exception:

    File "/usr/lib/python3.4/threading.py", line 358, in notify_all
      self.notify(len(self._waiters))
    File "/usr/lib/python3.4/threading.py", line 341, in notify
      waiters_to_notify = _deque(_islice(all_waiters, n))
  RuntimeError: deque mutated during iteration

(I have a server which makes extensive use of conditions on which this happens about once a day.)

This patch fixes this bug by moving wait()'s modification of self._waiters to be inside the lock, as suggested by Antoine Pitrou here: http://bugs.python.org/issue17385#msg183875

----------
components: Library (Lib)
files: fix.diff
keywords: patch
messages: 225208
nosy: dougz, pitrou
priority: normal
severity: normal
status: open
title: Occasional RuntimeError from Condition.notify
type: crash
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36351/fix.diff

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

From report at bugs.python.org  Tue Aug 12 18:57:31 2014
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Tue, 12 Aug 2014 16:57:31 +0000
Subject: [New-bugs-announce] [issue22186] Typos in .py files
Message-ID: <1407862651.37.0.513368911737.issue22186@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

The patch removes several typos found in .py files.

----------
assignee: docs at python
components: Documentation
files: spelling.diff
keywords: patch
messages: 225232
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Typos in .py files
type: enhancement
Added file: http://bugs.python.org/file36358/spelling.diff

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

From report at bugs.python.org  Tue Aug 12 20:13:05 2014
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 12 Aug 2014 18:13:05 +0000
Subject: [New-bugs-announce] [issue22187] commands.mkarg() buggy in East
	Asian locales
Message-ID: <1407867185.09.0.871560290901.issue22187@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

This is how shell quoting in commands.mkarg() is implemented:

def mkarg(x):
    if '\'' not in x:
        return ' \'' + x + '\''
    s = ' "'
    for c in x:
        if c in '\\$"`':
            s = s + '\\'
        s = s + c
    s = s + '"'
    return s

This is unfortunately not compatible with the way bash splits arguments in some locales.
The problem is that in a few East Asian encodings (at least BIG5, BIG5-HKSCS, GB18030, GBK), the 0x5C byte (backslash in ASCII) could be the second byte of a two-byte character; and bash apparently decodes the strings before splitting.

PoC:

$ sh --version | head -n1
GNU bash, version 4.3.22(1)-release (i486-pc-linux-gnu)

$ LC_ALL=C python test-mkargs.py
crw-rw-rw- 1 root root 1, 3 Aug 12 16:00 /dev/null
ls: cannot access " ; python -c 'import this' | grep . | shuf | head -n1 | cowsay -y ; ": No such file or directory

$ LC_ALL=zh_CN.GBK python test-mkargs.py
crw-rw-rw- 1 root root 1, 3 8?  12 16:00 /dev/null
ls: ?????: No such file or directory
 ________________________________
< Simple is better than complex. >
 --------------------------------
        \   ^__^
         \  (..)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
sh: ?: ?????

----------
components: Library (Lib)
files: test-mkargs.py
messages: 225235
nosy: jwilk
priority: normal
severity: normal
status: open
title: commands.mkarg() buggy in East Asian locales
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file36359/test-mkargs.py

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

From report at bugs.python.org  Tue Aug 12 23:09:57 2014
From: report at bugs.python.org (Peter Wu)
Date: Tue, 12 Aug 2014 21:09:57 +0000
Subject: [New-bugs-announce] [issue22188] test_gdb fails on invalid gdbinit
Message-ID: <1407877797.02.0.603397074385.issue22188@psf.upfronthosting.co.za>


New submission from Peter Wu:

I had a stale ~/.gdbinit file which tried to executed python code causing an exception. The tests should probably run with `-nx` or `-nh` to avoid reading ~/.gdbinit.

----------
components: Tests
messages: 225245
nosy: lekensteyn
priority: normal
severity: normal
status: open
title: test_gdb fails on invalid gdbinit
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 13 07:49:12 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Aug 2014 05:49:12 +0000
Subject: [New-bugs-announce] [issue22189] collections.UserString missing
	some str methods
Message-ID: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

str currently implements some methods that UserString doesn't:

>>> set(dir(str)) - set(dir(UserString))
{'__rmod__', 'casefold', 'isprintable', 'maketrans', 'format_map', '__getnewargs__'}

casefold, isprintable & format_map (and perhaps __rmod__) should likely be available on UserString as well.

----------
messages: 225255
nosy: ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: collections.UserString missing some str methods
type: enhancement

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

From report at bugs.python.org  Wed Aug 13 08:42:55 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Aug 2014 06:42:55 +0000
Subject: [New-bugs-announce] [issue22190] Integrate tracemalloc into
	regrtest refleak hunting
Message-ID: <1407912175.87.0.645515613061.issue22190@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Trying to debug issue #22166, I realised it would be nice if there was an easy way to use tracemalloc to get a clear idea of *what's* leaking when regrtest -R reports a refleak.

For that specific issue, I'm just trying to hack something together as a learning experience, but it would be good to have something more sophisticated built in to regrtest.

----------
components: Tests
messages: 225257
nosy: haypo, ncoghlan, neologix, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Integrate tracemalloc into regrtest refleak hunting
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug 13 15:42:16 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2014 13:42:16 +0000
Subject: [New-bugs-announce] [issue22191] warnings.__all__ incomplete
Message-ID: <1407937336.93.0.74452438959.issue22191@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you try `pydoc warnings` (or `help(warnings)` in the interpreter prompt) you'll notice that some functions such as simplefilter() don't appear. This seems to be because warnings.__all__ is incomplete.

----------
components: Library (Lib)
keywords: easy
messages: 225279
nosy: brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: warnings.__all__ incomplete
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug 13 22:52:43 2014
From: report at bugs.python.org (Ben Roberts)
Date: Wed, 13 Aug 2014 20:52:43 +0000
Subject: [New-bugs-announce] [issue22192] dict_values objects are hashable
Message-ID: <1407963163.14.0.392361410258.issue22192@psf.upfronthosting.co.za>


New submission from Ben Roberts:

In python 3.4 these result in a TypeError:

  hash({}.keys())

  hash({}.items())

But this succeeds:

  hash({}.values())

The 2.7 backports of these - viewkeys, viewitems, and viewvalues respectively - behave equivalently.

See more discussion on StackOverflow: http://stackoverflow.com/questions/25293912/why-are-some-dict-views-hashable

The cause appears to be that key and item views implement rich comparisons, whereas values views do not.  Therefore dict_view objects use the default id()-based __hash__ implementation.

Possible fix: explicitly set tp_hash to PyObject_HashNotImplemented for PyDictValues_Type - and perhaps for the other two view types as well, for symmetry.

----------
components: Interpreter Core
messages: 225287
nosy: roippi
priority: normal
severity: normal
status: open
title: dict_values objects are hashable
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Aug 14 12:24:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Aug 2014 10:24:53 +0000
Subject: [New-bugs-announce] [issue22193] Add _PySys_GetSizeOf()
Message-ID: <1408011893.72.0.474736082349.issue22193@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds private function _PySys_GetSizeOf(). It is needed for correct implementing of __sizeof__() methods: issue15490, issue15513, issue15381 (BytesIO.__sizeof__ is broken in 3.5). See discussion about it in issue15490. I extracted this patch in separate issue for its simplicity and because it is needed in other issues.

----------
assignee: serhiy.storchaka
components: Interpreter Core
files: _PySys_GetSizeOf.patch
keywords: patch
messages: 225294
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add _PySys_GetSizeOf()
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36368/_PySys_GetSizeOf.patch

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

From report at bugs.python.org  Thu Aug 14 15:29:58 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2014 13:29:58 +0000
Subject: [New-bugs-announce] [issue22194] access to cdecimal / libmpdec API
Message-ID: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently cdecimal exports no C API that I know of, and it makes sure the libmpdec symbols are kept private in the .so file. It would be nice for external C code (or, in general, non-Python code) to be able to access cdecimal objects, and make operations on them, without the huge overhead of the regular C Python API.

----------
messages: 225297
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: access to cdecimal / libmpdec API
type: enhancement

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

From report at bugs.python.org  Thu Aug 14 17:18:00 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2014 15:18:00 +0000
Subject: [New-bugs-announce] [issue22195] Make it easy to replace print()
	calls with logging calls
Message-ID: <1408029480.31.0.129647427763.issue22195@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Often an application (or e.g. a library's test suite), in its early development, will start making print() calls, and later will want to switch to the logging module. However the logging module doesn't offer any facility for this: you can't print() to a logger object, and loggers don't have a method that reflects print()'s signature.

(note print() only uses the .write() and .flush() methods on its stream argument, so a simple wrapper may make the trick)

----------
components: Library (Lib)
messages: 225302
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: Make it easy to replace print() calls with logging calls
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug 14 17:33:51 2014
From: report at bugs.python.org (Lele Gaifax)
Date: Thu, 14 Aug 2014 15:33:51 +0000
Subject: [New-bugs-announce] [issue22196] namedtuple documentation
	could/should mention the new	Enum type
Message-ID: <1408030431.26.0.145305463203.issue22196@psf.upfronthosting.co.za>


New submission from Lele Gaifax:

The documentation of namedtuple, near the end, talks about implementing enumerated constants and says ?Enumerated constants can be implemented with named tuples, but it is simpler and more efficient to use a simple class declaration?.

Maybe it should mention the recently added Enum type instead/too.

----------
assignee: docs at python
components: Documentation
messages: 225303
nosy: docs at python, lelit
priority: normal
severity: normal
status: open
title: namedtuple documentation could/should mention the new Enum type

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

From report at bugs.python.org  Thu Aug 14 17:39:01 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2014 15:39:01 +0000
Subject: [New-bugs-announce] [issue22197] Allow better verbosity / output
	control in test cases
Message-ID: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently, test cases have no control over output and verbosity. I would propose two possible enhancements:
- give the TestCase read access to the verbosity value (as e.g. `self.verbosity`), to allow for conditional output in tests
- allow test methods to force output buffering (rather than only let the user specify it on the command line), because you would like some stuff to only be printed out on failure; a decorator would IMO be fine

----------
components: Library (Lib)
messages: 225304
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
status: open
title: Allow better verbosity / output control in test cases
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug 14 18:47:41 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Aug 2014 16:47:41 +0000
Subject: [New-bugs-announce] [issue22198] Odd floor-division corner case
Message-ID: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

I'm not sure it's worth fixing this, but it seems worth recording:

>>> -0.5 // float('inf')
-1.0

I was expecting a value of `-0.0`, and while IEEE 754 doesn't cover the floor division operation, I'm reasonably confident that that's the value it would have recommended if it had. :-)

However, it's difficult to come up with a situation where the difference matters: there aren't any obvious invariants I can think of that are broken by this special case.  So unless anyone thinks it should be changed, I'll settle for recording the oddity in this issue, and closing as won't fix after a short period.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 225305
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Odd floor-division corner case
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug 14 19:28:32 2014
From: report at bugs.python.org (Jim Carroll)
Date: Thu, 14 Aug 2014 17:28:32 +0000
Subject: [New-bugs-announce] [issue22199] Embedding Python documentation
	error
Message-ID: <1408037312.39.0.0797944753174.issue22199@psf.upfronthosting.co.za>


New submission from Jim Carroll:

On the page https://docs.python.org/2/extending/embedding.html#compiling-and-linking-under-unix-like-systems

The documentation makes the following reference:

"...(use sysconfig.get_makefile_filename() to find its location)..."

But this is incorrect. sysconfig was modified in 3.x (Issue 9877) to use this new name. In 2.x, the function has an underscore prefix:

sysconfig._get_makefile_filename()

----------
assignee: docs at python
components: Documentation
messages: 225307
nosy: docs at python, jamercee
priority: normal
severity: normal
status: open
title: Embedding Python documentation error
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 14 23:37:01 2014
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 14 Aug 2014 21:37:01 +0000
Subject: [New-bugs-announce] [issue22200] Remove distutils checks for Python
	version
Message-ID: <1408052221.61.0.16718662323.issue22200@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

We noticed the other day that distutils, despite being part of the standard library, checks the version of Python it's running under and has some different code paths - one of which is only taken for Python < 2.2.

We haven't managed to figure out why this is necessary. So this issue is partly a patch and partly a question: is there a reason that distutils can't assume it's run on the version of Python it came with? If so, I'm happy to make a new patch adding a comment to explain that. If not, I'll go looking for other places where it has unnecessary checks, and we can clean up one little corner of wtf.

----------
components: Distutils
files: rm-distutils-version-check.patch
keywords: patch
messages: 225320
nosy: dstufft, eric.araujo, takluyver
priority: normal
severity: normal
status: open
title: Remove distutils checks for Python version
Added file: http://bugs.python.org/file36372/rm-distutils-version-check.patch

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

From report at bugs.python.org  Fri Aug 15 01:27:42 2014
From: report at bugs.python.org (Antony Lee)
Date: Thu, 14 Aug 2014 23:27:42 +0000
Subject: [New-bugs-announce] [issue22201] python -mzipfile fails to unzip
	files with folders	created by zip
Message-ID: <1408058862.32.0.0511670758715.issue22201@psf.upfronthosting.co.za>


New submission from Antony Lee:

With Python 3.4.1:

$ mkdir foo; zip -r foo{,}; python -mzipfile -e foo.zip dest
  adding: foo/ (stored 0%)
Traceback (most recent call last):
  File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.4/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.4/zipfile.py", line 1799, in <module>
    main()
  File "/usr/lib/python3.4/zipfile.py", line 1777, in main
    with open(tgt, 'wb') as fp:
IsADirectoryError: [Errno 21] Is a directory: 'dest/foo/'

Note that zipfile is actually able to unzip the file:

$ python -c 'from zipfile import *; ZipFile("foo.zip").extractall("dest")'

works fine.

If the zip file is created by "python -mzipfile -c foo.zip foo" then there is no problem.  Likewise, if there are no folders in the zip file (but just a collection of files) then there is no problem.

----------
components: Library (Lib)
messages: 225325
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: python -mzipfile fails to unzip files with folders created by zip
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Aug 15 02:15:09 2014
From: report at bugs.python.org (Reza Shahrzad)
Date: Fri, 15 Aug 2014 00:15:09 +0000
Subject: [New-bugs-announce] [issue22202] Function Bug?
Message-ID: <000301cfb81d$e76593f0$b630bbd0$@verizon.net>


New submission from Reza Shahrzad:

Hi,

I hope this e-mail will get to the right person/department and looked at.

Thank you,

Reza Shahrzad

----------
files: List_Error.py, Uncertainty.docx
messages: 225326
nosy: rezashahrzad
priority: normal
severity: normal
status: open
title: Function Bug?
Added file: http://bugs.python.org/file36374/List_Error.py
Added file: http://bugs.python.org/file36375/Uncertainty.docx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22202>
_______________________________________
-------------- next part --------------
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:45:13) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ============================================================== RESTART ==============================================================
>>> 
>>> def fib(n):
	result = []
	a, b = 0, 1
	while a < n:
		result.append(a)
		a, b = b, a+b
	return result

>>> fib(100)
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> 
>>> result
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    result
NameError: name 'result' is not defined
>>> result[3]
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    result[3]
NameError: name 'result' is not defined
>>> 
>>> 
>>> def fib(n):
	result = []
	results = []
	a, b = 0, 1
	while a < n:
		result.append(a)
		results = result
		a, b = b, a+b
	return result

>>> fib(100)
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> results
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    results
NameError: name 'results' is not defined
>>> results[4]
Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    results[4]
NameError: name 'results' is not defined
>>> 
>>> 
>>> def fib(n):
	result = []
	results = []
	a, b = 0, 1
	while a < n:
		result.append(a)
		results = result
		a, b = b, a+b
		print(result)
		print(results)
	return result

>>> fib(100)
[0]
[0]
[0, 1]
[0, 1]
[0, 1, 1]
[0, 1, 1]
[0, 1, 1, 2]
[0, 1, 1, 2]
[0, 1, 1, 2, 3]
[0, 1, 1, 2, 3]
[0, 1, 1, 2, 3, 5]
[0, 1, 1, 2, 3, 5]
[0, 1, 1, 2, 3, 5, 8]
[0, 1, 1, 2, 3, 5, 8]
[0, 1, 1, 2, 3, 5, 8, 13]
[0, 1, 1, 2, 3, 5, 8, 13]
[0, 1, 1, 2, 3, 5, 8, 13, 21]
[0, 1, 1, 2, 3, 5, 8, 13, 21]
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34]
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34]
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> 
>>> print(result)
Traceback (most recent call last):
  File "<pyshell#20>", line 1, in <module>
    print(result)
NameError: name 'result' is not defined
>>> print(results)
Traceback (most recent call last):
  File "<pyshell#21>", line 1, in <module>
    print(results)
NameError: name 'results' is not defined
>>> 
>>> 
>>> z = [0, 1, 2, 3, 4, 5]
>>> z
[0, 1, 2, 3, 4, 5]
>>> print(z)
[0, 1, 2, 3, 4, 5]
>>> z[3]
3
>>> z.append(6)
>>> z
[0, 1, 2, 3, 4, 5, 6]
>>> y = z
>>> y
[0, 1, 2, 3, 4, 5, 6]
>>> y[4]
4
>>> print(y)
[0, 1, 2, 3, 4, 5, 6]
>>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Uncertainty.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 37067 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20140815/54af9fc8/attachment-0001.docx>

From report at bugs.python.org  Fri Aug 15 07:20:32 2014
From: report at bugs.python.org (Alexander Schepanovski)
Date: Fri, 15 Aug 2014 05:20:32 +0000
Subject: [New-bugs-announce] [issue22203] inspect.getargspec() returns wrong
	spec for builtins
Message-ID: <1408080032.86.0.165011450626.issue22203@psf.upfronthosting.co.za>


New submission from Alexander Schepanovski:

inspect.getargspec() returns empty ArgSpec for map() and filter():

    >>> import inspect
    >>> inspect.getargspec(map)
    ArgSpec(args=[], varargs=None, keywords=None, defaults=None)
    >>> inspect.getargspec(filter)
    ArgSpec(args=[], varargs=None, keywords=None, defaults=None)

Not sure if other builtins affected.

----------
components: Library (Lib)
messages: 225338
nosy: suor
priority: normal
severity: normal
status: open
title: inspect.getargspec() returns wrong spec for builtins
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Aug 15 15:25:33 2014
From: report at bugs.python.org (LuisC)
Date: Fri, 15 Aug 2014 13:25:33 +0000
Subject: [New-bugs-announce] [issue22204] 2014 USA CONFERENCE/INVITATION!!
Message-ID: <20140815124408.40F38E352@mail.gzxydc.cn>


New submission from LuisC:

Dear Colleagues

On behalf of California Human Welfare Foundation. It is a great privilege for us to invite you to global Congress meeting Against Economic Crisis, Prostitution, Human Trafficking and child abuse & HIV/AIDS Treatment, held in the united state and in Dakar Senegal.

All interested delegates that requires entry visa to enter the United States to attend this meeting will be assisted by the organization in obtaining the visa in their passport free air round trip tickets to attend this meeting will be provided to all participants.

For registration contact the secretariat at:  secretaryandrea at foxmail.com

Please share the information with your colleagues.

Sincerely,

Dr.Tyler Lockett (Ph.D) Senior Activities Coordinator.

----------
messages: 225350
nosy: lcarrionr
priority: normal
severity: normal
status: open
title: 2014 USA CONFERENCE/INVITATION!!

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

From report at bugs.python.org  Fri Aug 15 21:47:49 2014
From: report at bugs.python.org (Martin Matusiak)
Date: Fri, 15 Aug 2014 19:47:49 +0000
Subject: [New-bugs-announce] [issue22205] debugmallocstats test is cpython
	only
Message-ID: <1408132069.59.0.430460353459.issue22205@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

sys._debugmallocstats is a cpython specific feature, so test_debugmallocstats should be marked as such.

----------
files: debugmallocstats.diff
keywords: patch
messages: 225362
nosy: numerodix, serhiy.storchaka
priority: normal
severity: normal
status: open
title: debugmallocstats test is cpython only
Added file: http://bugs.python.org/file36379/debugmallocstats.diff

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

From report at bugs.python.org  Fri Aug 15 23:45:30 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Aug 2014 21:45:30 +0000
Subject: [New-bugs-announce] [issue22206] PyThread_create_key(): fix
	comparison between signed and	unsigned numbers
Message-ID: <1408139130.39.0.506649628643.issue22206@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #22110 enabled more compiler warnings. I would like to fix this one:
---
gcc -pthread -c -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes    -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Python/thread.o Python/thread.c
In file included from Python/thread.c:86:0:
Python/thread_pthread.h: In function ?PyThread_create_key?:
Python/thread_pthread.h:611:22: attention : signed and unsigned type in conditional expression [-Wsign-compare]
     return fail ? -1 : key;
                      ^
---

Attached patch uses Py_SAFE_DOWNCAST() to explicitly downcast to int.

On Linux (on my Fedora 20/amd64), pthread_key_t is defined as an unsigned int, whereas the result type of PyThread_create_key is a signed int.

Nobody complained before, so I get that nobody noticed the possible overflow for a key > INT_MAX. I checked the code, we only check if PyThread_create_key() returns -1, if you reach UINT_MAX keys. UINT_MAX keys sounds insane, you probably hit another limit before.

On Linux, it looks like the key is a counter and deleted values are reused:

haypo at selma$ ./python
Python 3.5.0a0 (default:a0b38f4eb79e, Aug 15 2014, 23:37:42) 
[GCC 4.8.3 20140624 (Red Hat 4.8.3-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.pythonapi.PyThread_create_key()
2
>>> ctypes.pythonapi.PyThread_create_key()
3
>>> ctypes.pythonapi.PyThread_create_key()
4
>>> ctypes.pythonapi.PyThread_delete_key(3)
0
>>> ctypes.pythonapi.PyThread_create_key()
3

----------
files: PyThread_create_key.patch
keywords: patch
messages: 225367
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: PyThread_create_key(): fix comparison between signed and unsigned numbers
versions: Python 3.5
Added file: http://bugs.python.org/file36380/PyThread_create_key.patch

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

From report at bugs.python.org  Sat Aug 16 00:03:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Aug 2014 22:03:19 +0000
Subject: [New-bugs-announce] [issue22207] Test for integer overflow on
	Py_ssize_t: explicitly cast	to size_t
Message-ID: <1408140199.72.0.115939936455.issue22207@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python contains a lot of tests like this one:

    if (length > PY_SSIZE_T_MAX / 4)
         return PyErr_NoMemory();

where length type is Py_ssize_t.

This test uses signed integers. There is usually a "assert(length > 0);" before.

The issue #22110 enabled more compiler warnings and there are now warnings when the test uses an unsigned number. Example:

   if (size > PY_SSIZE_T_MAX - PyBytesObject_SIZE) ...

where PyBytesObject_SIZE is defined using offsetof() which returns a size_t.

I propose to always cast Py_ssize_t length to size_t to avoid undefined behaviour (I never know if the compiler chooses signed or unsigned at the end) to ensure that the test also fail for negative number. For example, the following test must fail for negative size:

   if ((size_t)size > (size_t)PY_SSIZE_T_MAX - PyBytesObject_SIZE) ...

Attached patch changes bytesobject.c, tupleobject.c and unicodeobject.c (and asdl.c). If the global approach is accepted, more files should be patched.

----------
files: test_overflow_ssize_t.patch
keywords: patch
messages: 225369
nosy: haypo, neologix, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Test for integer overflow on Py_ssize_t: explicitly cast to size_t
versions: Python 3.5
Added file: http://bugs.python.org/file36381/test_overflow_ssize_t.patch

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

From report at bugs.python.org  Sat Aug 16 01:29:17 2014
From: report at bugs.python.org (Mark Grandi)
Date: Fri, 15 Aug 2014 23:29:17 +0000
Subject: [New-bugs-announce] [issue22208] tarfile can't add in memory files
	(reopened)
Message-ID: <1408145357.61.0.947327827691.issue22208@psf.upfronthosting.co.za>


New submission from Mark Grandi:

So I ran into this problem today, where near impossible to create a tarfile.TarFile object, then add files to the archive, when the files are in memory file-like objects (like io.BytesIO, io.StringIO, etc)

code example:

###################
import tarfile, io

tarFileIo = io.BytesIO()

tarFileObj = tarfile.open(fileobj=tarFileIo, mode="w:xz")

fileToAdd = io.BytesIO("hello world!".encode("utf-8"))

# fixes "AttributeError: '_io.BytesIO' object has no attribute 'name'"
fileToAdd.name="helloworld.txt"

# fails with 'io.UnsupportedOperation: fileno'
tarInfo = tarFileObj.gettarinfo(arcname="helloworld.txt", fileobj=fileToAdd)

# never runs
tarFileObj.addfile(tarInfo, fileobj=fileToAdd)
###################

this was previously reported as this bug: http://bugs.python.org/issue10369 but I am unhappy with the resolution of "its not a bug", and the 'hack' that Lars posted as a solution. My reasons:

1: The zipfile module supports writing in memory files / bytes , using the following code (which is weird but it works)

tmp = zipfile.ZipFile("tmp.zip", mode="w")
import io
x = io.BytesIO("hello world!".encode("utf-8"))
tmp.writestr("helloworld.txt", x.getbuffer())
tmp.close()

2: the 'hack' that Lars posted, while it works, this is unintuitive and confusing, and isn't the intended behavior. What happens if your script is cross platform, what file do you open to give to os.stat()? In the code posted it uses open('/etc/passwd/') for the fileobj parameter to gettarinfo(), but that file doesn't exist on windows, now not only are you doing this silly hack, you have to have code that checks platform.system() to get a valid file that is known to exist for every system, or use sys.executable, except the documentation for that says it can return None or an empty string.

3: it is easy to fix (at least to me), in tarfile.gettarinfo(), if fileobj is passed in, and it doesn't have a fileno, then to create the TarInfo object, you set 'name' to be the arcname parameter, size = len(fileobj), then have default (maybe overridden by keyword args to gettarinfo()) values for uid/gid/uname/gname.

On a random tar.gz file that I downloaded from sourceforge, the uid/gid are '500' (when my gid is 20 and uid is 501), and the gname/uname are just empty strings. So its obvious that those don't matter most of the time, and when they do matter, you can modify the TarInfo object after creation or pass in values for them in a theoretical keywords argument to gettarinfo().

If no one wants to code this I can provide a patch, I just want the previous bug report's status of "not a bug" to be reconsidered.

----------
components: Library (Lib)
messages: 225374
nosy: markgrandi
priority: normal
severity: normal
status: open
title: tarfile can't add in memory files (reopened)
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 16 02:57:21 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Aug 2014 00:57:21 +0000
Subject: [New-bugs-announce] [issue22209] Idle: add better access to
	extension information
Message-ID: <1408150641.09.0.182071744794.issue22209@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In msg225377 of #17535, Ned Daily says "(Noted in passing: while the help/doc suggests: "See the beginning of config-extensions.def in the idlelib directory for further information.", even in the unlikely event that a user knew in what directory to look for it, it's not possible to open that file in an IDLE editor window with the current default Cocoa Tk's since Cocoa Tk does not provide a filter option on the open window; only .py* and .txt files can be opened.)"

Users should not normally poke around idlelib and should not need to or be asked to.  The extension information should either be added to the idle doc or make accessible on the help menu with an new 'Extensions' entry. If the docstring were moved to, say, configHandler.py, it would be trivial to access: 'from configHandler import __doc__ and help_extension".  Since configHandler already knows how to find the file, we can just read it up to the second """ line.

Note: regardless of the resolution of this issue, show_text() should be altered to start wide enough to show 80 char lines.

----------
messages: 225378
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: add better access to extension information
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug 16 06:44:22 2014
From: report at bugs.python.org (linuxie)
Date: Sat, 16 Aug 2014 04:44:22 +0000
Subject: [New-bugs-announce] [issue22210] pdb-run-restarting-a-pdb-session
Message-ID: <1408164262.59.0.0117890122292.issue22210@psf.upfronthosting.co.za>


New submission from linuxie:

I was running pdb from the command line.
	Whenever I restart, It throws the error:
	
	 Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/tornado/web.py", line 861, in _execute getattr(self, self.request.method.lower())(*args, **kwargs) File "main.py", line 33, in post res = user.login( platform_id, platform_type) File "main.py", line 33, in post res = user.login( platform_id, platform_type) File "/home/work/src/Python-2.7.8/Lib/bdb.py", line 49, in trace_dispatch return self.dispatch_line(frame) File "/home/work/src/Python-2.7.8/Lib/bdb.py", line 67, in dispatch_line self.user_line(frame) File "/home/work/src/Python-2.7.8/Lib/pdb.py", line 158, in user_line self.interaction(frame, None) File "/home/work/src/Python-2.7.8/Lib/pdb.py", line 210, in interaction self.cmdloop() File "/home/work/src/Python-2.7.8/Lib/cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "/home/work/src/Python-2.7.8/Lib/pdb.py", line 279, in onecmd return cmd.Cmd.onecmd(self, line) File "/home/work/src/Python-2.7.8/Lib/cmd.py", line 221, in onecmd return func(arg) File "/home/work/src/Python-2.7.8/Lib/pdb.py", line 679, in do_run raise Restart Restart


	I wonder why a so big bug has not been solved.

----------
messages: 225383
nosy: zhengxiexie
priority: normal
severity: normal
status: open
title: pdb-run-restarting-a-pdb-session
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug 16 22:54:10 2014
From: report at bugs.python.org (John Malmberg)
Date: Sat, 16 Aug 2014 20:54:10 +0000
Subject: [New-bugs-announce] [issue22211] Remove VMS specific code in
	expat.h & xmlrole.h
Message-ID: <1408222450.15.0.0579194114943.issue22211@psf.upfronthosting.co.za>


New submission from John Malmberg:

The Modules/expat/expat.h and Modules/expat/xmlrole.h contain VMS specific code that actually breaks building python 3.5 on VMS.

Per http://bugs.python.org/issue16136, such VMS specific code should be removed for Python 3.5.


This code may still be needed for the Python 2.7 since that appears to being built using the compiler mode which is to be compatible with VAX/VMS 5.5-1.

----------
messages: 225415
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: Remove VMS specific code in expat.h  & xmlrole.h
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug 16 23:29:12 2014
From: report at bugs.python.org (John Malmberg)
Date: Sat, 16 Aug 2014 21:29:12 +0000
Subject: [New-bugs-announce] [issue22212] zipfile.py fails if zlib.so module
	fails to build.
Message-ID: <1408224552.38.0.698985209475.issue22212@psf.upfronthosting.co.za>


New submission from John Malmberg:

If the zlib.so fails to build while building python, subsequent runs of setup.py fail, which prevents a trying again to build zlib.so after the issue is fixed unless all the .so modules built are deleted.

   File "/PRJ_ROOT/CPYTHON/Lib/zipfile.py", line 20, in <module>
     crc32 = zlib.crc32
AttributeError: module 'zlib' has no attribute 'crc32'
make: *** [sharedmods] Error 1


zipfile.py is trying to test for a missing zlib.so by checking if the import fails.

The problem is that while the zlib module did not get built, the import of it succeeds because the directory is now in the module path at this
point in the build.

Using -v on Python shows the import succeeding.

Python 3.5.0a0 (default, Aug 13 2014, 19:13:13) [C] on openvms0
Type "help", "copyright", "credits" or "license" for more information.
 >>> import zlib
# possible namespace for /PRJ_ROOT/CPYTHON/Modules/zlib
import 'zlib' # None.

In order to get setup.py to work in this case, the following patch is
needed for zipfile.py

--- /src_root/cpython/Lib/zipfile.py    Mon Jun 16 18:00:20 2014
+++ /vms_root/cpython/Lib/zipfile.py    Thu Aug 14 20:39:47 2014
@@ -18,7 +18,7 @@
  try:
      import zlib # We may need its compression method
      crc32 = zlib.crc32
-except ImportError:
+except (ImportError, AttributeError):
      zlib = None
      crc32 = binascii.crc32

This is not a complete solution for zlib.so module not building.  The run_tests.py also fails when zlib.so is not present.

Setup.py reports that zlib.so is an optional module, so not being build should not cause the setup.py to fail.

----------
components: Build
messages: 225417
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: zipfile.py fails if  zlib.so module fails to build.
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug 17 13:42:41 2014
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 17 Aug 2014 11:42:41 +0000
Subject: [New-bugs-announce] [issue22213] pyvenv style virtual environments
	unusable in an	embedded system
Message-ID: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

In am embedded system, as the 'python' executable is itself not run and the Python interpreter is initialised in process explicitly using PyInitialize(), in order to find the location of the Python installation, an elaborate sequence of checks is run as implemented in calculate_path() of Modules/getpath.c.

The primary mechanism is usually to search for a 'python' executable on PATH and use that as a starting point. From that it then back tracks up the file system from the bin directory to arrive at what would be the perceived equivalent of PYTHONHOME. The lib/pythonX.Y directory under that for the matching version X.Y of Python being initialised would then be used.

Problems can often occur with the way this search is done though.

For example, if someone is not using the system Python installation but has installed a different version of Python under /usr/local. At run time, the correct Python shared library would be getting loaded from /usr/local/lib, but because the 'python' executable is found from /usr/bin, it uses /usr as sys.prefix instead of /usr/local.

This can cause two distinct problems.

The first is that there is no Python installation at all under /usr corresponding to the Python version which was embedded, with the result of it not being able to import 'site' module and therefore failing.

The second is that there is a Python installation of the same major/minor but potentially a different patch revision, or compiled with different binary API flags or different Unicode character width. The Python interpreter in this case may well be able to start up, but the mismatch in the Python modules or extension modules and the core Python library that was actually linked can cause odd errors or crashes to occur.

Anyway, that is the background.

For an embedded system the way this problem was overcome was for it to use Py_SetPythonHome() to forcibly override what should be used for PYTHONHOME so that the correct installation was found and used at runtime.

Now this would work quite happily even for Python virtual environments constructed using 'virtualenv' allowing the embedded system to be run in that separate virtual environment distinct from the main Python installation it was created from.

Although this works for Python virtual environments created using 'virtualenv', it doesn't work if the virtual environment was created using pyvenv.

One can easily illustrate the problem without even using an embedded system.

$ which python3.4
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4

$ pyvenv-3.4 py34-pyvenv

$ py34-pyvenv/bin/python
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/private/tmp/py34-pyvenv'
>>> sys.path
['', '/Library/Frameworks/Python.framework/Versions/3.4/lib/python34.zip', '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4', '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin', '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload', '/private/tmp/py34-pyvenv/lib/python3.4/site-packages']

$ PYTHONHOME=/tmp/py34-pyvenv python3.4
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'
Abort trap: 6

The basic problem is that in a pyvenv virtual environment, there is no duplication of stuff in lib/pythonX.Y, with the only thing in there being the site-packages directory.

When you start up the 'python' executable direct from the pyvenv virtual environment, the startup sequence checks know this and consult the pyvenv.cfg to extract the:

home = /Library/Frameworks/Python.framework/Versions/3.4/bin

setting and from that derive where the actual run time files are.

When PYTHONHOME or Py_SetPythonHome() is used, then the getpath.c checks blindly believe that is the authoritative value:

 * Step 2. See if the $PYTHONHOME environment variable points to the
 * installed location of the Python libraries.  If $PYTHONHOME is set, then
 * it points to prefix and exec_prefix.  $PYTHONHOME can be a single
 * directory, which is used for both, or the prefix and exec_prefix
 * directories separated by a colon.

    /* If PYTHONHOME is set, we believe it unconditionally */
    if (home) {
        wchar_t *delim;
        wcsncpy(prefix, home, MAXPATHLEN);
        prefix[MAXPATHLEN] = L'\0';
        delim = wcschr(prefix, DELIM);
        if (delim)
            *delim = L'\0';
        joinpath(prefix, lib_python);
        joinpath(prefix, LANDMARK);
        return 1;
    }
Because of this, the problem above occurs as the proper runtime directories for files aren't included in sys.path. The result being that the 'encodings' module cannot even be found.

What I believe should occur is that PYTHONHOME should not be believed unconditionally. Instead there should be a check to see if that directory contains a pyvenv.cfg file and if there is one, realise it is a pyvenv style virtual environment and do the same sort of adjustments which would be made based on looking at what that pyvenv.cfg file contains.

For the record this issue is affecting Apache/mod_wsgi and right now the only workaround I have is to tell people that in addition to setting the configuration setting corresponding to PYTHONHOME, to use configuration settings to have the same effect as doing:

PYTHONPATH=/Library/Frameworks/Python.framework/Versions/3.4/lib/python34.zip:/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4:/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin:/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload

so that the correct runtime files are found.

I am still trying to work out a more permanent workaround I can add to mod_wsgi code itself since can't rely on a fix for existing Python versions with pyvenv support.

Only other option is to tell people not to use pyvenv and use virtualenv instead.

Right now I can offer no actual patch as that getpath.c code is scary enough that not even sure at this point where the check should be incorporated or how.

Only thing I can surmise is that the current check for pyvenv.cfg being before the search for the prefix is meaning that it isn't consulted.

    /* Search for an environment configuration file, first in the
       executable's directory and then in the parent directory.
       If found, open it for use when searching for prefixes.
    */

    {
        wchar_t tmpbuffer[MAXPATHLEN+1];
        wchar_t *env_cfg = L"pyvenv.cfg";
        FILE * env_file = NULL;

        wcscpy(tmpbuffer, argv0_path);

        joinpath(tmpbuffer, env_cfg);
        env_file = _Py_wfopen(tmpbuffer, L"r");
        if (env_file == NULL) {
            errno = 0;
            reduce(tmpbuffer);
            reduce(tmpbuffer);
            joinpath(tmpbuffer, env_cfg);
            env_file = _Py_wfopen(tmpbuffer, L"r");
            if (env_file == NULL) {
                errno = 0;
            }
        }
        if (env_file != NULL) {
            /* Look for a 'home' variable and set argv0_path to it, if found */
            if (find_env_config_value(env_file, L"home", tmpbuffer)) {
                wcscpy(argv0_path, tmpbuffer);
            }
            fclose(env_file);
            env_file = NULL;
        }
    }

    pfound = search_for_prefix(argv0_path, home, _prefix, lib_python);

----------
messages: 225434
nosy: grahamd
priority: normal
severity: normal
status: open
title: pyvenv style virtual environments unusable in an embedded system
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug 17 16:24:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Aug 2014 14:24:09 +0000
Subject: [New-bugs-announce] [issue22214] Tkinter: Don't stringify callbacks
	arguments
Message-ID: <1408285449.26.0.836464630135.issue22214@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently Tkinter supports two modes:

* When wantobjects=1 (default), all results of Tcl/Tk commands are converted to appropriate Python objects (int, float, str, bytes, tuple) if it is possible or to Tcl_Obj for unknown Tcl types.
* When wantobjects=0 (legacy mode), all results of Tcl/Tk commands are converted to strings.

But arguments of a callback are always converted to str, even when wantobjects=1. This can lost information ("42" is not distinguished from 42 or (42,)) and may be less efficient. Unfortunately we can't just change Tkinter to pass callback arguments as Python objects, this is backward incompatible change. Proposed patch introduces third mode wantobjects=2. It is the same as wantobjects=1, but callbacks now received . Default mode is still wantobjects=1, it can be changed in future. But in Tkinter applications (IDLE, Turtledemo, Pynche) we can use wantobjects=2 right now.

The only problem left is documenting it. The wantobjects parameter is not documented at all except an entry in "What's New in Python 2.3". Does anyone want to document this feature?

----------
components: Tkinter
files: tkinter_obj_cmd.patch
keywords: patch
messages: 225446
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Tkinter: Don't stringify callbacks arguments
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36393/tkinter_obj_cmd.patch

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

From report at bugs.python.org  Sun Aug 17 16:43:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Aug 2014 14:43:55 +0000
Subject: [New-bugs-announce] [issue22215] "embedded NUL character" exceptions
Message-ID: <1408286635.01.0.343838296034.issue22215@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently most functions which accepts string only without embedded NUL character, raise TypeError. Proposed patch change exception type to more consistent ValueError. It also unifies error messages.

I have opened a discussion on Python-Dev.

----------
components: Interpreter Core
files: valueerror_embedded_nul_character.diff
keywords: patch
messages: 225447
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: "embedded NUL character" exceptions
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36394/valueerror_embedded_nul_character.diff

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

From report at bugs.python.org  Sun Aug 17 18:53:45 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Sun, 17 Aug 2014 16:53:45 +0000
Subject: [New-bugs-announce] [issue22216] smtplip STARTTLS fails at second
	attampt due to	unsufficiant quit()
Message-ID: <1408294425.22.0.0722430877114.issue22216@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

When using smtplib.SMTP to connect to a SMTP server the instance variables esmtp_response survives a SMTP.quit() which results in the following error:

>>> import smtplib
>>> smtp = smtplib.SMTP('mail.oberkirch.org', 25)
>>> smtp.starttls()
(220, b'2.0.0 Ready to start TLS')
>>> smtp.ehlo()
(250, b'mail.oberkirch.org\nPIPELINING\nSIZE 10240000\nVRFY\nETRN\nAUTH PLAIN LOGIN\nAUTH=PLAIN LOGIN\nENHANCEDSTATUSCODES\n8BITMIME\nDSN')
>>> smtp.quit()
(221, b'2.0.0 Bye')
>>> smtp.connect('mail.oberkirch.org', 25)
(220, b'mail.oberkirch.org ESMTP Postfix')
>>> smtp.starttls()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/smtplib.py", line 672, in starttls
    raise SMTPException("STARTTLS extension not supported by server.")
smtplib.SMTPException: STARTTLS extension not supported by server.
>>>

While reporting this issue I found out that starttls also does not throw away any ehlo information as it should. Provided that fixing this would probably break existing code (which would only work with non-standard servers like postfix) I did not change that behaviour.

----------
components: Library (Lib)
files: quit_resets_greeting.patch
keywords: patch
messages: 225450
nosy: zvyn
priority: normal
severity: normal
status: open
title: smtplip STARTTLS fails at second attampt due to unsufficiant quit()
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36396/quit_resets_greeting.patch

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

From report at bugs.python.org  Sun Aug 17 19:05:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Aug 2014 17:05:43 +0000
Subject: [New-bugs-announce] [issue22217] Reprs for zipfile classes
Message-ID: <1408295143.26.0.466080487063.issue22217@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch implements __repr__() methods of three zipfile classes: ZipFile, ZipInfo and ZipExtFile. Example:

>>> import zipfile
>>> zf = zipfile.ZipFile('/usr/share/doc/texlive-base/support/makeindex/ind-src.zip')
>>> zf
<zipfile.ZipFile filename='/usr/share/doc/texlive-base/support/makeindex/ind-src.zip' mode='r'>
>>> zf.infolist()[:2]
[<ZipInfo filename='ind-src/' filemode=drwxr-xr-x external_attr=0x10>, <ZipInfo filename='ind-src/fig1.tex' compress_type=deflate filemode=-r--r--r-- external_attr=0x1 file_size=1553 compress_size=518>]
>>> zf.open('ind-src/fig1.tex')
<zipfile.ZipExtFile name='ind-src/fig1.tex' mode='r' compress_type=deflate>

----------
assignee: serhiy.storchaka
components: Library (Lib)
messages: 225451
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Reprs for zipfile classes
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug 17 19:31:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Aug 2014 17:31:19 +0000
Subject: [New-bugs-announce] [issue22218] Fix more compiler warnings
	"comparison between signed	and unsigned integers"
Message-ID: <1408296679.77.0.83853794909.issue22218@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #22110 enabled more compiler warnings. Attached patch fixes some of them in the Modules/ subdirectory.

----------
files: fix_more_warnings.patch
keywords: patch
messages: 225453
nosy: haypo
priority: normal
severity: normal
status: open
title: Fix more compiler warnings "comparison between signed and unsigned integers"
versions: Python 3.5
Added file: http://bugs.python.org/file36399/fix_more_warnings.patch

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

From report at bugs.python.org  Sun Aug 17 19:53:45 2014
From: report at bugs.python.org (Antony Lee)
Date: Sun, 17 Aug 2014 17:53:45 +0000
Subject: [New-bugs-announce] [issue22219] python -mzipfile fails to add
	empty folders to created	zip
Message-ID: <1408298025.49.0.964091160745.issue22219@psf.upfronthosting.co.za>


New submission from Antony Lee:

Compare

$ mkdir foo; zip -q foo{,}; unzip -l foo.zip
Archive:  foo.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2014-08-17 10:49   foo/
---------                     -------
        0                     1 file

and

$ mkdir foo; python -mzipfile -c foo{.zip,}; unzip -l foo.zip
Archive:  foo.zip
warning [foo.zip]:  zipfile is empty

A patch was posted by Ryan Wilson in related issue #22201.

----------
components: Library (Lib)
messages: 225457
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: python -mzipfile fails to add empty folders to created zip
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Aug 17 20:54:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Aug 2014 18:54:31 +0000
Subject: [New-bugs-announce] [issue22220] Ttk extensions test failure
Message-ID: <1408301671.8.0.626599352152.issue22220@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Strange test failure on one of Windows buildbots:
http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/2393/steps/test/logs/stdio

======================================================================
ERROR: test_horizontal_range (tkinter.test.test_ttk.test_extensions.LabeledScaleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py", line 113, in test_horizontal_range
    lscale.pack()
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py", line 1952, in pack_configure
    + self._options(cnf, kw))
_tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid

======================================================================
ERROR: test_resize (tkinter.test.test_ttk.test_extensions.LabeledScaleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py", line 175, in test_resize
    x.pack(expand=True, fill='both')
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py", line 1952, in pack_configure
    + self._options(cnf, kw))
_tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid

======================================================================
ERROR: test_variable_change (tkinter.test.test_ttk.test_extensions.LabeledScaleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py", line 143, in test_variable_change
    x.pack()
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py", line 1952, in pack_configure
    + self._options(cnf, kw))
_tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid

======================================================================
ERROR: test_menu (tkinter.test.test_ttk.test_extensions.OptionMenuTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py", line 256, in test_menu
    optmenu.pack()
  File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py", line 1952, in pack_configure
    + self._options(cnf, kw))
_tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid

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

May be it relates to my last Tkinter changes or may be it is just sporadic failure.

----------
assignee: serhiy.storchaka
components: Tkinter
messages: 225458
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: test needed
status: open
title: Ttk extensions test failure
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug 17 21:53:49 2014
From: report at bugs.python.org (=?utf-8?q?Jorgen_Sch=C3=A4fer?=)
Date: Sun, 17 Aug 2014 19:53:49 +0000
Subject: [New-bugs-announce] [issue22221] ast.literal_eval confused by
	coding declarations
Message-ID: <1408305229.31.0.808680198001.issue22221@psf.upfronthosting.co.za>


New submission from Jorgen Sch?fer:

The ast module seems to get confused for certain strings which contain coding declarations.

>>> import ast

>>> s = u'"""\\\n# -*- coding: utf-8 -*-\n"""'
>>> print s
"""\
# -*- coding: utf-8 -*-
"""
>>> ast.literal_eval(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/forcer/Programs/Python/python2.7/lib/python2.7/ast.py", line 49, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "/home/forcer/Programs/Python/python2.7/lib/python2.7/ast.py", line 37, in parse
    return compile(source, filename, mode, PyCF_ONLY_AST)
  File "<unknown>", line 0
SyntaxError: encoding declaration in Unicode string

----------
components: Library (Lib)
messages: 225464
nosy: jorgenschaefer
priority: normal
severity: normal
status: open
title: ast.literal_eval confused by coding declarations
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 17 21:55:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Aug 2014 19:55:29 +0000
Subject: [New-bugs-announce] [issue22222] dtoa.c: remove custom memory
	allocator
Message-ID: <1408305329.63.0.21484400673.issue22222@psf.upfronthosting.co.za>


New submission from STINNER Victor:

dtoa.c has an optimized memory allocator for performances: it uses a short pool of 2304 doubles (18 KB) to avoid calling malloc/free. Comment in dtoa.c:

/* Memory management: memory is allocated from, and returned to, Kmax+1 pools
   of memory, where pool k (0 <= k <= Kmax) is for Bigints b with b->maxwds ==
   1 << k.  These pools are maintained as linked lists, with freelist[k]
   pointing to the head of the list for pool k.

   On allocation, if there's no free slot in the appropriate pool, MALLOC is
   called to get more memory.  This memory is not returned to the system until
   Python quits.  There's also a private memory pool that's allocated from
   in preference to using MALLOC.

   For Bigints with more than (1 << Kmax) digits (which implies at least 1233
   decimal digits), memory is directly allocated using MALLOC, and freed using
   FREE.

   XXX: it would be easy to bypass this memory-management system and
   translate each call to Balloc into a call to PyMem_Malloc, and each
   Bfree to PyMem_Free.  Investigate whether this has any significant
   performance on impact. */

Python already has such memory pool: PyObject_Malloc(). I propose to reuse it. It avoids wasting memory "until Python quits" just to optimize dtoa.c.

dtoa.c memory pool is only used for allocations smaller than 68 bytes (on 64 bits system, Kmax=7). PyObject_Malloc() is optimized for allocations smaller than 513 bytes, so it's ok.

See also the issue #7632.

----------
files: dtoa_remove_custom_alloc.patch
keywords: patch
messages: 225465
nosy: haypo, mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: dtoa.c: remove custom memory allocator
versions: Python 3.5
Added file: http://bugs.python.org/file36400/dtoa_remove_custom_alloc.patch

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

From report at bugs.python.org  Mon Aug 18 11:46:02 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Mon, 18 Aug 2014 09:46:02 +0000
Subject: [New-bugs-announce] [issue22223] argparse not including '--'
	arguments in previous	optional REMAINDER argument
Message-ID: <1408355162.18.0.7039636355.issue22223@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

If you have an optional nargs=argparse.REMAINDER argument defined
then, if specified, its value should contain all the remaining command-line content. However, it seems that value does not include later '--' arguments.

For example, the following works as expected:

import argparse
parser = argparse.ArgumentParser(prog="PROG")
parser.add_argument("--args", nargs=argparse.REMAINDER)
args = parser.parse_args("--args cmd --arg1 XX ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "ZZ"]

But the following fails with
'PROG: error: unrecognized arguments: -- ZZ':

import argparse
parser = argparse.ArgumentParser(prog="PROG")
parser.add_argument("--args", nargs=argparse.REMAINDER)
args = parser.parse_args("--args cmd --arg1 XX -- ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "--", "ZZ"]


Note that the same code works as expected when using a
positional nargs=argparse.REMAINDER arguments:

import argparse
parser = argparse.ArgumentParser(prog="PROG")
parser.add_argument("args", nargs=argparse.REMAINDER)
args = parser.parse_args("args cmd --arg1 XX ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "ZZ"]
args = parser.parse_args("args cmd --arg1 XX -- ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "--", "ZZ"]

But that, of course, does not allow us to have the args value
start with something like "--blah" that looks like an optional
argument.


Hope this helps.

Best regards,
  Jurko Gospodneti?

----------
components: Library (Lib)
messages: 225484
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: argparse not including '--' arguments in previous optional REMAINDER argument
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Aug 18 12:57:24 2014
From: report at bugs.python.org (Alexander Patrakov)
Date: Mon, 18 Aug 2014 10:57:24 +0000
Subject: [New-bugs-announce] [issue22224] docs.python.org is prone to
	political blocking in Russia
Message-ID: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>


New submission from Alexander Patrakov:

I could not access http://docs.python.org/ from work today. Upon investigation, it appears that the ISP has blocked all sites on the IP address 185.31.17.175, because of the court order unrelated to docs.python.org. Many other ISPs in Russia also don't know any methods of site blocking except by IP address.

Even if the bad site removes the offending materials, the situation is doomed to repeat itself in the future.

To avoid this, please obtain an IPv4 or IPv6 address for docs.python.org that is not shared with any site not controlled by PSF.

----------
assignee: docs at python
components: Documentation
messages: 225487
nosy: Alexander.Patrakov, docs at python
priority: normal
severity: normal
status: open
title: docs.python.org is prone to political blocking in Russia
type: behavior

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

From report at bugs.python.org  Mon Aug 18 20:49:06 2014
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 18 Aug 2014 18:49:06 +0000
Subject: [New-bugs-announce] [issue22225] Add SQLite support to
	http.cookiejar
Message-ID: <1408387746.24.0.600227999545.issue22225@psf.upfronthosting.co.za>


New submission from Demian Brecht:

This is a proposal for adding SQLite support to http.cookiejar. I've been working on an implementation for MozillaSQLiteCookieJar and GoogleSQLiteCookieJar (initial patch will likely only include Mozilla) but wanted to make sure that the addition has buy-in before I continue work on it within the stdlib.

----------
components: Library (Lib)
messages: 225502
nosy: demian.brecht
priority: normal
severity: normal
status: open
title: Add SQLite support to http.cookiejar
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug 19 08:16:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Aug 2014 06:16:14 +0000
Subject: [New-bugs-announce] [issue22226] Refactor dict result handling in
	Tkinter
Message-ID: <1408428974.08.0.266954995149.issue22226@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch refactors code which converts the result of Tcl call to Python dict. Added new private function _splitdict() which does this in more robust manner.

Also this patch fixes a bug in Treeview.heading(). The heading subcommand of ttk::treeview return options dict in which one key surprisingly was not '-' prefixed.

% ttk::treeview t
% .t heading #0
-text {} -image {} -anchor center -command {} state {}

Current code unconditionally cuts "s" from the "state" key.

>>> from tkinter import ttk
>>> t = ttk.Treeview()
>>> t.heading('#0')
{'anchor': 'center', 'tate': '', 'image': '', 'text': '', 'command': ''}

----------
assignee: serhiy.storchaka
components: Tkinter
files: tkinter_splitdict.diff
keywords: patch
messages: 225515
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Refactor dict result handling in Tkinter
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36411/tkinter_splitdict.diff

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

From report at bugs.python.org  Tue Aug 19 10:05:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Aug 2014 08:05:55 +0000
Subject: [New-bugs-announce] [issue22227] Simplify tarfile iterator
Message-ID: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

TarFile iteration can be simplified by using a generator instead of iterator class. Attached patch get rid of the TarIter class and decrease sources size by 16 lines.

----------
components: Library (Lib)
files: tarfile_tariter.diff
keywords: patch
messages: 225521
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify tarfile iterator
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36412/tarfile_tariter.diff

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

From report at bugs.python.org  Tue Aug 19 11:42:08 2014
From: report at bugs.python.org (Lele Gaifax)
Date: Tue, 19 Aug 2014 09:42:08 +0000
Subject: [New-bugs-announce] [issue22228] Adapt bash readline
	operate-and-get-next function
Message-ID: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za>


New submission from Lele Gaifax:

Bash implements an handy extension to the history/readline library called "operate-and-get-next" bound by default to Ctrl-O that lets you repeat an arbitrary sequence of input lines possibly editing some of them.

This patch adapts the extension to the Python readline module.

Since I have no way of testing it against the libedit alternative library, it targets only the real readline library.

----------
files: readline.patch
keywords: patch
messages: 225523
nosy: lelit, steven.daprano
priority: normal
severity: normal
status: open
title: Adapt bash readline operate-and-get-next function
type: enhancement
Added file: http://bugs.python.org/file36414/readline.patch

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

From report at bugs.python.org  Tue Aug 19 19:34:05 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 19 Aug 2014 17:34:05 +0000
Subject: [New-bugs-announce] [issue22229] wsgiref doesn't appear to ever set
	REMOTE_HOST in the	environ
Message-ID: <1408469645.6.0.0733162760485.issue22229@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Based on a reading of the code:

https://github.com/python/cpython/blob/master/Lib/wsgiref/simple_server.py#L88-L90

is where REMOTE_HOST is set.

However, `address_string` always returns `self.client_address[0]` (https://github.com/python/cpython/blob/master/Lib/http/server.py#L568), which means that `!=` comparison always returns False, which means REMOTE_HOST is never actually set correctly.

----------
components: Library (Lib)
messages: 225534
nosy: alex
priority: normal
severity: normal
status: open
title: wsgiref doesn't appear to ever set REMOTE_HOST in the environ
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Aug 19 19:37:14 2014
From: report at bugs.python.org (Ryan Wilson)
Date: Tue, 19 Aug 2014 17:37:14 +0000
Subject: [New-bugs-announce] [issue22230] 'python -mzipfile -c' does not zip
	empty directories
Message-ID: <1408469834.45.0.903664986624.issue22230@psf.upfronthosting.co.za>


New submission from Ryan Wilson:

Running command:

$ mkdir foo; python -mzipfile -c foo.zip foo; python -mzipfile -e foo.zip dest
ls: cannot access dest: No such file or directory

This is because 'foo.zip' is empty since running 'python -mzipfile -c foo.zip foo' does not zip empty directories.

Running 'unzip foo.zip' also produces:
Archive:  foo.zip
warning [foo.zip]:  zipfile is empty

The following posted patch fixes this issue.

----------
components: Library (Lib)
files: add_empty_dirs_to_zipfile.patch
keywords: patch
messages: 225535
nosy: ryantimwilson
priority: normal
severity: normal
status: open
title: 'python -mzipfile -c' does not zip empty directories
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36416/add_empty_dirs_to_zipfile.patch

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

From report at bugs.python.org  Wed Aug 20 04:49:37 2014
From: report at bugs.python.org (Bob Chen)
Date: Wed, 20 Aug 2014 02:49:37 +0000
Subject: [New-bugs-announce] [issue22231] httplib: unicode url will cause an
	ascii codec error	when combined with a utf-8 string header
Message-ID: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za>


New submission from Bob Chen:

Try to run these two script below, and you will understand what I'm talking about.

If you specified an url and it happened to be an unicode string(which is quite common in python because python processes string as unicode and you could possibly get it from somewhere else), and your header contains a utf-8 string converted from a foreign language, like u'??', then the codec error occurred.

File "/usr/lib/python2.7/httplib.py", line 808, in _send_output
    msg = "\r\n".join(self._buffer) 


# -*- encoding: utf-8 -*-
# should fail
import httplib, urllib
params = urllib.urlencode({'@number': 12524, '@type': 'issue', '@action': 'show'})
headers = {"Content-type": "application/x-www-form-urlencoded",
        "Accept": "text/plain", 'notes': u'??'.encode('utf-8')}
conn = httplib.HTTPConnection(u"bugs.python.org")
conn.request("POST", u"http://bugs.python.org/any_url", params, headers)
response = conn.getresponse()
print response.status, response.reason



# -*- encoding: utf-8 -*-
# should be ok
import httplib, urllib
params = urllib.urlencode({'@number': 12524, '@type': 'issue', '@action': 'show'})
headers = {"Content-type": "application/x-www-form-urlencoded",
        "Accept": "text/plain", 'notes': u'??'.encode('utf-8')}
conn = httplib.HTTPConnection(u"bugs.python.org")
conn.request("POST", "http://bugs.python.org/any_url", params, headers)
response = conn.getresponse()
print response.status, response.reason

----------
components: Library (Lib)
messages: 225553
nosy: Bob.Chen
priority: normal
severity: normal
status: open
title: httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 20 12:01:51 2014
From: report at bugs.python.org (Samuel Charron)
Date: Wed, 20 Aug 2014 10:01:51 +0000
Subject: [New-bugs-announce] [issue22232] str.splitlines splitting on
	none-\r\n characters
Message-ID: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>


New submission from Samuel Charron:

According to the documentation, str.splitlines uses the universal newlines to split lines.
The documentation says it's all about \r, \n, and \r\n (https://docs.python.org/3.5/glossary.html#term-universal-newlines)

However, it's also splitting on other characters. Reading the code, it seems the list of characters is from Objects/unicodeobject.c , in _PyUnicode_Init, the linebreak array.
When testing any of these characters, it splits the string.

Other libraries are using str.splitlines assuming it only breaks on these \r and \n characters. This is the case of email.feedparser for instance, used by http.client to parse headers. These HTTP headers should be separated by CLRF as specified by http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4. 

Either the documentation should state that splitlines splits on other characters or it should stick to the documentation and split only on \r and \n characters.

If it splits on other characters, the list could be improved, as the unicode reference lists the mandatory characters for line breaking : http://www.unicode.org/reports/tr14/tr14-32.html#BK

----------
components: Library (Lib), Unicode
messages: 225561
nosy: ezio.melotti, haypo, scharron
priority: normal
severity: normal
status: open
title: str.splitlines splitting on none-\r\n characters
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug 20 12:02:33 2014
From: report at bugs.python.org (Samuel Charron)
Date: Wed, 20 Aug 2014 10:02:33 +0000
Subject: [New-bugs-announce] [issue22233] http.client splits headers on
	none-\r\n characters
Message-ID: <1408528953.84.0.772180232607.issue22233@psf.upfronthosting.co.za>


New submission from Samuel Charron:

In some cases, the headers from http.client (that uses email.feedparser) splits headers at wrong separators. The bug is from the use of str.splitlines (in email.feedparser) that splits on other characters than \r\n as it should. (See bug http://bugs.python.org/issue22232)

To reproduce the bug : 

import http.client
c = http.client.HTTPSConnection("graph.facebook.com")
c.request("GET", "/%C4%85", None, {"test": "\x85"})
r = c.getresponse()
print(r.headers)
print(r.headers.keys())
print(r.headers.get("WWW-Authenticate"))

As you can see, the WWW-Authenticate is wrongly parsed (it misses its final "), and therefore the rest of the headers are ignored.

----------
components: Library (Lib)
messages: 225562
nosy: scharron
priority: normal
severity: normal
status: open
title: http.client splits headers on none-\r\n characters
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug 20 14:39:51 2014
From: report at bugs.python.org (Antti Haapala)
Date: Wed, 20 Aug 2014 12:39:51 +0000
Subject: [New-bugs-announce] [issue22234] urllib.parse.urlparse accepts any
	falsy value as an url
Message-ID: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>


New submission from Antti Haapala:

Because of "if x else ''" in _decode_args (http://hg.python.org/cpython/file/3.4/Lib/urllib/parse.py#l96), urllib.parse.urlparse accepts any falsy value as an url, returning a ParseResultBytes with all members set to empty bytestrings.

Thus you get:

    >>> urllib.parse.urlparse({})
    ParseResultBytes(scheme=b'', netloc=b'', path=b'', params=b'', query=b'', fragment=b'')

which may result in some very confusing exceptions later on: I had a list of URLs that accidentally contained some Nones and got very confusing TypeErrors while processing the results expecting them to be strings.

If the `if x else ''` part were removed, such invalid falsy values would fail with `AttributeError: 'foo' object has no attribute 'decode'`, as happens with any truthy invalid value.

----------
components: Library (Lib)
messages: 225566
nosy: Ztane
priority: normal
severity: normal
status: open
title: urllib.parse.urlparse accepts any falsy value as an url
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 20 15:58:25 2014
From: report at bugs.python.org (Etienne Robillard)
Date: Wed, 20 Aug 2014 13:58:25 +0000
Subject: [New-bugs-announce] [issue22235] httplib: TypeError with file()
	object in ssl.py
Message-ID: <1408543105.82.0.290860786236.issue22235@psf.upfronthosting.co.za>


New submission from Etienne Robillard:

Trying to push to a ssl server but python break in httplib. 



erob at nguns:~/django-hotsauce$ hg push https://tkadm30 at bitbucket.org/tkadm30/django-hotsauce
pushing to https://tkadm30 at bitbucket.org/tkadm30/django-hotsauce
warning: bitbucket.org certificate with fingerprint 45:ad:ae:1a:cf:0e:73:47:06:07:e0:88:f5:cc:10:e5:fa:1c:f7:99 not verified (check hostfingerprints or web.cacerts config setting)
** unknown exception encountered, please report by visiting
** http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.3 (default, Aug 20 2014, 09:34:08) [GCC 4.7.2]
** Mercurial Distributed SCM (version 3.1)
** Extensions loaded: color, gpg, strip, mq, notify, patchbomb
Traceback (most recent call last):
  File "/usr/local/bin/hg", line 43, in <module>
    mercurial.dispatch.run()
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 28, in run
    sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 69, in dispatch
    ret = _runcatch(req)
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 138, in _runcatch
    return _dispatch(req)
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 820, in _dispatch
    cmdpats, cmdoptions)
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 600, in runcommand
    ret = _runcommand(ui, options, cmd, d)
  File "/usr/local/lib/python2.7/site-packages/mercurial/extensions.py", line 196, in wrap
    return wrapper(origfn, *args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/hgext/color.py", line 433, in colorcmd
    return orig(ui_, opts, cmd, cmdfunc)
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 911, in _runcommand
    return checkargs()
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 882, in checkargs
    return cmdfunc()
  File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 817, in <lambda>
    d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/usr/local/lib/python2.7/site-packages/mercurial/util.py", line 550, in check
    return func(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/mercurial/extensions.py", line 151, in wrap
    util.checksignature(origfn), *args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/mercurial/util.py", line 550, in check
    return func(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/hgext/mq.py", line 3393, in mqcommand
    return orig(ui, repo, *args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/mercurial/util.py", line 550, in check
    return func(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/mercurial/commands.py", line 4768, in push
    other = hg.peer(repo, opts, dest)
  File "/usr/local/lib/python2.7/site-packages/mercurial/hg.py", line 129, in peer
    return _peerorrepo(rui, path, create).peer()
  File "/usr/local/lib/python2.7/site-packages/mercurial/hg.py", line 106, in _peerorrepo
    obj = _peerlookup(path).instance(ui, path, create)
  File "/usr/local/lib/python2.7/site-packages/mercurial/httppeer.py", line 261, in instance
    inst._fetchcaps()
  File "/usr/local/lib/python2.7/site-packages/mercurial/httppeer.py", line 58, in _fetchcaps
    self.caps = set(self._call('capabilities').split())
  File "/usr/local/lib/python2.7/site-packages/mercurial/httppeer.py", line 172, in _call
    fp = self._callstream(cmd, **args)
  File "/usr/local/lib/python2.7/site-packages/mercurial/httppeer.py", line 119, in _callstream
    resp = self.urlopener.open(req)
  File "/usr/local/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/local/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/local/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python2.7/site-packages/mercurial/url.py", line 371, in https_open
    return self.do_open(self._makeconnection, req)
  File "/usr/local/lib/python2.7/site-packages/mercurial/keepalive.py", line 255, in do_open
    r = h.getresponse()
  File "/usr/local/lib/python2.7/site-packages/mercurial/keepalive.py", line 577, in safegetresponse
    return cls.getresponse(self)
  File "/usr/local/lib/python2.7/httplib.py", line 1028, in getresponse
    response = self.response_class(*args, **kwds)
  File "/usr/local/lib/python2.7/site-packages/mercurial/keepalive.py", line 380, in __init__
    httplib.HTTPResponse.__init__(self, sock, debuglevel, method)
  File "/usr/local/lib/python2.7/httplib.py", line 346, in __init__
    self.fp = sock.makefile('rb', 0)
  File "/usr/local/lib/python2.7/ssl.py", line 366, in makefile
    return _fileobject(self, mode, bufsize, close=True)
TypeError: file() takes at most 3 arguments (4 given)

----------
components: Library (Lib)
messages: 225567
nosy: erob
priority: normal
severity: normal
status: open
title: httplib: TypeError with file() object in ssl.py
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 20 16:19:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Aug 2014 14:19:41 +0000
Subject: [New-bugs-announce] [issue22236] Do not use _default_root in
	Tkinter tests
Message-ID: <1408544381.68.0.237360840846.issue22236@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently many Tkinter tests depends on tkinter._default_root. I.e. they reuse the same Tcl interpreter and main window. This can cause unexpected dependencies between tests. Proposed patch creates new root for every test, this makes tests mutually independent. It also fixes some bugs in NoDefaultRoot mode and get rid of 'can't invoke "event" command:' messages in tests. This patch is needed to run Tkinter tests in different "wantobjects" modes (issue21585).

----------
components: Tests, Tkinter
files: tkinter_no_default_root.patch
keywords: patch
messages: 225570
nosy: gpolo, serhiy.storchaka, terry.reedy, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Do not use _default_root in Tkinter tests
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36421/tkinter_no_default_root.patch

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

From report at bugs.python.org  Wed Aug 20 18:53:50 2014
From: report at bugs.python.org (Wilfred Hughes)
Date: Wed, 20 Aug 2014 16:53:50 +0000
Subject: [New-bugs-announce] [issue22237] sorted() docs should state that
	the sort is stable
Message-ID: <1408553630.26.0.335574291367.issue22237@psf.upfronthosting.co.za>


New submission from Wilfred Hughes:

According to https://wiki.python.org/moin/HowTo/Sorting/#Sort_Stability_and_Complex_Sorts and Alex Martelli: http://stackoverflow.com/q/1915376/509706, Python's sorted() is stable. It would be great to update the docs for sorted() to state this.

----------
assignee: docs at python
components: Documentation
messages: 225574
nosy: Wilfred.Hughes, docs at python
priority: normal
severity: normal
status: open
title: sorted() docs should state that the sort is stable
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/issue22237>
_______________________________________

From report at bugs.python.org  Wed Aug 20 19:31:43 2014
From: report at bugs.python.org (Robert Snoeberger)
Date: Wed, 20 Aug 2014 17:31:43 +0000
Subject: [New-bugs-announce] [issue22238] fractions.gcd results in infinite
	loop when nan or inf	given as parameter.
Message-ID: <1408555903.78.0.619851425654.issue22238@psf.upfronthosting.co.za>


New submission from Robert Snoeberger:

>>> import fractions
>>> fractions.gcd(16, float('inf'))
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    fractions.gcd(16, float('inf'))
  File "C:\Python34-32bit\lib\fractions.py", line 24, in gcd
    a, b = b, a%b
KeyboardInterrupt
>>> fractions.gcd(16, float('nan'))
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    fractions.gcd(16, float('nan'))
  File "C:\Python34-32bit\lib\fractions.py", line 24, in gcd
    a, b = b, a%b
KeyboardInterrupt
>>> 

With the iterative algorithm that is used 

a, b = b, a%b

b converges to float('nan'). It will never become 0 to break out of the loop. It might be nice to error when the iteration has converged b to a value other than 0.

----------
components: Library (Lib)
messages: 225576
nosy: snoeberger
priority: normal
severity: normal
status: open
title: fractions.gcd results in infinite loop when nan or inf given as parameter.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 20 20:03:50 2014
From: report at bugs.python.org (Daniel Arbuckle)
Date: Wed, 20 Aug 2014 18:03:50 +0000
Subject: [New-bugs-announce] [issue22239] asyncio: nested event loop
Message-ID: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za>


New submission from Daniel Arbuckle:

It's occasionally necessary to invoke the asyncio event loop from code that was itself invoked within (although usually not directly by) the event loop.

For example, imagine you are writing a class that serves as a local proxy for a remote data structure. You can not make the __contains__ method of that class into a coroutine, because Python automatically converts the return value into a boolean. However, __contains__ must invoke coroutines in order to communicate over the network, and it must be invokable from within a coroutine to be at all useful.

If the event loop _run_once method were reentrant, addressing this problem would be simple. That primitive could be used to create a loop_until_complete function, which could be applied to the io tasks that __contains__ needs to invoke

So, making _run_once reentrant is one way of addressing this request.

Alternately, I've attached a decorator that sets aside some of the state of _run_once, runs a couroutine to completion in a nested event loop, restores the saved state, and returns the coroutine's result. This is merely a proof of concept, but it does work, at least in my experiments.

----------
components: asyncio
files: nested.py
messages: 225578
nosy: djarb, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: nested event loop
type: enhancement
Added file: http://bugs.python.org/file36422/nested.py

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

From report at bugs.python.org  Wed Aug 20 21:59:11 2014
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 20 Aug 2014 19:59:11 +0000
Subject: [New-bugs-announce] [issue22240] argparse support for "python -m
	module" in help
Message-ID: <1408564751.42.0.897410433728.issue22240@psf.upfronthosting.co.za>


New submission from Miki Tebeka:

"python -m module -h" starts with
    usage: __main__.py

It should be
    usage: python -m module

----------
components: Library (Lib)
files: prog.diff
keywords: patch
messages: 225586
nosy: tebeka
priority: normal
severity: normal
status: open
title: argparse support for "python -m module" in help
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36424/prog.diff

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

From report at bugs.python.org  Thu Aug 21 13:35:17 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 21 Aug 2014 11:35:17 +0000
Subject: [New-bugs-announce] [issue22241] strftime/strptime round trip fails
	even for UTC datetime	object
Message-ID: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za>


New submission from Akira Li:

>>> from datetime import datetime, timezone
  >>> dt = datetime.now(timezone.utc)
  >>> fmt = '%Y-%m-%d %H:%M:%S.%f %Z%z'
  >>> datetime.strptime(dt.strftime(fmt), fmt)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/cpython/Lib/_strptime.py", line 500, in _strptime_datetime
      tt, fraction = _strptime(data_string, format)
    File "/cpython/Lib/_strptime.py", line 337, in _strptime
      (data_string, format))
  ValueError: time data '2014-08-21 11:29:13.537251 UTC+00:00+0000'
  does not match format '%Y-%m-%d %H:%M:%S.%f %Z%z'

The issue is that dt.strftime('%Z') produces 'UTC+00:00'
(due to timezone.utc.tzname(dt) returning 'UTC+00:00')
instead of 'UTC' that strptime() accepts and %Z examples [1]
in the docs demonstrate.

[1] https://docs.python.org/3.4/library/datetime.html#strftime-and-strptime-behavior

----------
components: Library (Lib)
messages: 225606
nosy: akira
priority: normal
severity: normal
status: open
title: strftime/strptime round trip fails even for UTC datetime object
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug 21 16:55:27 2014
From: report at bugs.python.org (Jon Poler)
Date: Thu, 21 Aug 2014 14:55:27 +0000
Subject: [New-bugs-announce] [issue22242] Doc fix in the Import section in
	language reference.
Message-ID: <1408632927.48.0.574934380183.issue22242@psf.upfronthosting.co.za>


New submission from Jon Poler:

It looks like there might be a contradiction in the documentation of import in the language reference. In the loading subsection https://docs.python.org/dev/reference/import.html#loading, first bulleted list of the section, it specifies that if a loader fails, it must remove only the failing module from sys.modules, while other side-effect imports by loader will stay in sys.modules.

In the next subsection https://docs.python.org/dev/reference/import.html#loaders, second bulleted list (last bullet), the phrasing is confusing, and possibly contradictory. I believe that it meant to reiterate what was said above (see my previous paragraph).

Attached is a potential patch, but if anyone finds that I am interpreting this wrong, I'll make adjustments accordingly.

----------
assignee: docs at python
components: Documentation
files: import_doc_fix.patch
keywords: patch
messages: 225610
nosy: docs at python, jon.poler
priority: normal
severity: normal
status: open
title: Doc fix in the Import section in language reference.
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36427/import_doc_fix.patch

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

From report at bugs.python.org  Thu Aug 21 17:55:55 2014
From: report at bugs.python.org (Michael Williamson)
Date: Thu, 21 Aug 2014 15:55:55 +0000
Subject: [New-bugs-announce] [issue22243] Documentation on try statement
	incorrectly implies	target of except clause can be any
	assignable expression
Message-ID: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>


New submission from Michael Williamson:

In the docs for the try statement [1], part of the grammar is:

try1_stmt ::=  "try" ":" suite
               ("except" [expression ["as" target]] ":" suite)+
               ["else" ":" suite]
               ["finally" ":" suite]

The `target` rule allows any assignable expression (identifier, attributes, etc.). However, CPython appears to only allow identifiers as a target. The abstract grammar in the ast module [2] appears to confirm this.

[1] https://docs.python.org/3.4/reference/compound_stmts.html#the-try-statement
[2] https://docs.python.org/3.4/library/ast.html#abstract-grammar

----------
assignee: docs at python
components: Documentation
messages: 225611
nosy: docs at python, mwilliamson
priority: normal
severity: normal
status: open
title: Documentation on try statement incorrectly implies target of except clause can be any assignable expression
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug 21 22:46:55 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 21 Aug 2014 20:46:55 +0000
Subject: [New-bugs-announce] [issue22244] load_verify_locations fails to
	handle unicode paths on	Python 2
Message-ID: <1408654015.09.0.119519270878.issue22244@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Details of the issue are here: http://bugs.python.org/msg225613

I'm not sure what the correct API to use is there, perhaps the encoding can be folded into the PyArg_ParseTupleAndKeywords() call.

----------
components: Extension Modules
messages: 225614
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: load_verify_locations fails to handle unicode paths on Python 2
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 22 01:33:29 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2014 23:33:29 +0000
Subject: [New-bugs-announce] [issue22245] test_urllib2_localnet prints out
	error messages
Message-ID: <1408664009.01.0.559911932302.issue22245@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I get the following error messages in the test suite:

[1/1] test_urllib2_localnet
test_basic_auth_httperror (test.test_urllib2_localnet.BasicAuthTests) ... ----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 44046)
Traceback (most recent call last):
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 305, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 331, in process_request
    self.finish_request(request, client_address)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 344, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/antoine/cpython/34/Lib/test/test_urllib2_localnet.py", line 291, in http_server_with_basic_auth_handler
    return BasicAuthHandler(*args, **kwargs)
  File "/home/antoine/cpython/34/Lib/test/test_urllib2_localnet.py", line 212, in __init__
    http.server.BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 669, in __init__
    self.handle()
  File "/home/antoine/cpython/34/Lib/http/server.py", line 398, in handle
    self.handle_one_request()
  File "/home/antoine/cpython/34/Lib/http/server.py", line 387, in handle_one_request
    self.wfile.flush() #actually send the response if not already done.
ValueError: I/O operation on closed file.
----------------------------------------
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 44047)
Traceback (most recent call last):
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 305, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 331, in process_request
    self.finish_request(request, client_address)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 344, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/antoine/cpython/34/Lib/test/test_urllib2_localnet.py", line 291, in http_server_with_basic_auth_handler
    return BasicAuthHandler(*args, **kwargs)
  File "/home/antoine/cpython/34/Lib/test/test_urllib2_localnet.py", line 212, in __init__
    http.server.BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 669, in __init__
    self.handle()
  File "/home/antoine/cpython/34/Lib/http/server.py", line 398, in handle
    self.handle_one_request()
  File "/home/antoine/cpython/34/Lib/http/server.py", line 387, in handle_one_request
    self.wfile.flush() #actually send the response if not already done.
ValueError: I/O operation on closed file.
----------------------------------------
ok
test_basic_auth_success (test.test_urllib2_localnet.BasicAuthTests) ... ----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 60893)
Traceback (most recent call last):
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 305, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 331, in process_request
    self.finish_request(request, client_address)
Exception happened during processing of request from ('127.0.0.1', 60894)
Traceback (most recent call last):
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 305, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 331, in process_request
    self.finish_request(request, client_address)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 344, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/antoine/cpython/34/Lib/test/test_urllib2_localnet.py", line 291, in http_server_with_basic_auth_handler
    return BasicAuthHandler(*args, **kwargs)
  File "/home/antoine/cpython/34/Lib/test/test_urllib2_localnet.py", line 212, in __init__
    http.server.BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/home/antoine/cpython/34/Lib/socketserver.py", line 669, in __init__
    self.handle()
  File "/home/antoine/cpython/34/Lib/http/server.py", line 398, in handle
    self.handle_one_request()
  File "/home/antoine/cpython/34/Lib/http/server.py", line 387, in handle_one_request
    self.wfile.flush() #actually send the response if not already done.
ValueError: I/O operation on closed file.
----------------------------------------
ok


It seems they were introduced by 30e8a8f22a2a.

----------
components: Tests
messages: 225622
nosy: orsenthil, pitrou
priority: normal
severity: normal
status: open
title: test_urllib2_localnet prints out error messages
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Aug 22 01:48:56 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 21 Aug 2014 23:48:56 +0000
Subject: [New-bugs-announce] [issue22246] add strptime(s, '%s')
Message-ID: <1408664936.57.0.427329646216.issue22246@psf.upfronthosting.co.za>


New submission from Akira Li:

issue12750 makes strftime('%s') portable. For symmetry,
datetime.strptime(s, '%s') could be enabled to return local time as an
aware (to avoid loosing info) datetime object for a given integer
(seconds since the Epoch) timestamp string.

I've uploaded a prototype patch with a draft implementation, docs, and
tests.

----------
components: Library (Lib)
files: draft-strptime-%s.diff
keywords: patch
messages: 225624
nosy: akira
priority: normal
severity: normal
status: open
title: add strptime(s, '%s')
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36430/draft-strptime-%s.diff

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

From report at bugs.python.org  Fri Aug 22 04:42:48 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Aug 2014 02:42:48 +0000
Subject: [New-bugs-announce] [issue22247] More incomplete module.__all__
	lists
Message-ID: <1408675368.08.0.766854982306.issue22247@psf.upfronthosting.co.za>


New submission from Martin Panter:

The nntplib.NNTPError exception is documented, but missing from __all__. I ran across another one the other day, but I can?t remember what it was now.

Is there a practical way to automatically test for some of these, perhaps by scanning the documentation for function and class definitions? These sort of bugs keep popping up, as people adding new features, exceptions, etc, forget to append them to __all__.

Another more radical idea: a decorator something like this might avoid copy-paste errors and make unexported APIs stand out more:

def public(api):
    sys.modules[api.__module__].__all__.append(api.__name__)
    return api

__all__ = list()
@public
def public_function(): ...
@public
class PublicClass: ...

Related:
* Issue 18554: os.__all__
* Issue 22191: warnings.__all__

----------
components: Library (Lib)
messages: 225637
nosy: vadmium
priority: normal
severity: normal
status: open
title: More incomplete module.__all__ lists
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 22 10:58:03 2014
From: report at bugs.python.org (Tomas Groth)
Date: Fri, 22 Aug 2014 08:58:03 +0000
Subject: [New-bugs-announce] [issue22248] urllib.request.urlopen raises
	exception when	30X-redirect url contains non-ascii chars
Message-ID: <1408697883.93.0.665294573507.issue22248@psf.upfronthosting.co.za>


New submission from Tomas Groth:

Running this simple test script produces the traceback show below.

import urllib.request
page = urllib.request.urlopen('http://legacy.biblegateway.com/versions/?vid=DN1933&action=getVersionInfo#books')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/urllib/request.py", line 153, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.4/urllib/request.py", line 461, in open
    response = meth(req, response)
  File "/usr/lib/python3.4/urllib/request.py", line 571, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.4/urllib/request.py", line 493, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.4/urllib/request.py", line 433, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.4/urllib/request.py", line 676, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.4/urllib/request.py", line 455, in open
    response = self._open(req, data)
  File "/usr/lib/python3.4/urllib/request.py", line 473, in _open
    '_open', req)
  File "/usr/lib/python3.4/urllib/request.py", line 433, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.4/urllib/request.py", line 1258, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib/python3.4/urllib/request.py", line 1232, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/usr/lib/python3.4/http/client.py", line 1065, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.4/http/client.py", line 1093, in _send_request
    self.putrequest(method, url, **skips)
  File "/usr/lib/python3.4/http/client.py", line 957, in putrequest
    self._output(request.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 31-32: ordinal not in range(128)


Using curl we can see that there is a redirect to an url with a special char:
$ curl -vs "http://legacy.biblegateway.com/versions/?vid=DN1933&action=getVersionInfo#books" >DN1933
* Hostname was NOT found in DNS cache
*   Trying 23.23.93.211...
* Connected to legacy.biblegateway.com (23.23.93.211) port 80 (#0)
> GET /versions/?vid=DN1933&action=getVersionInfo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: legacy.biblegateway.com
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
* Server nginx/1.4.7 is not blacklisted
< Server: nginx/1.4.7
< Date: Fri, 22 Aug 2014 08:35:30 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 0
< Connection: keep-alive
< X-Powered-By: PHP/5.5.7
< Set-Cookie: bg_id=1b9a80d5e6d545487cfd153d6df65c4e; path=/; domain=.biblegateway.com
< Set-Cookie: a9gl=0; path=/; domain=.biblegateway.com
< Location: http://legacy.biblegateway.com/versions/Dette-er-Biblen-p?-dansk-1933/
< 
* Connection #0 to host legacy.biblegateway.com left intact


When the redirect-url doesn't contain special chars everything works as expected, like with this url: "http://legacy.biblegateway.com/versions/?vid=DNB1930&action=getVersionInfo#books"

----------
components: Library (Lib)
messages: 225651
nosy: tomasgroth
priority: normal
severity: normal
status: open
title: urllib.request.urlopen raises exception when 30X-redirect url contains non-ascii chars
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 22 13:43:28 2014
From: report at bugs.python.org (Alexander Patrakov)
Date: Fri, 22 Aug 2014 11:43:28 +0000
Subject: [New-bugs-announce] [issue22249] Possibly incorrect example is
	given for	socket.getaddrinfo()
Message-ID: <1408707808.63.0.0809888327352.issue22249@psf.upfronthosting.co.za>


New submission from Alexander Patrakov:

See the example at https://docs.python.org/2/library/socket.html#socket.getaddrinfo

>>> socket.getaddrinfo("www.python.org", 80, 0, 0, socket.SOL_TCP)

As I am primarily a C programmer, it is quite surprising for me to see a SOL_* being passed into the proto argument. I thought that SOL_* is only for setsockopt(), and IPPROTO_* would be suitable. Yes, for TCP and UDP the SOL_* and IPPROTO_* constants are the same, but see e.g. http://msdn.microsoft.com/en-us/library/windows/desktop/ms737530%28v=vs.85%29.aspx which specifically points out that IPPROTO_* constants as acceptable values.

----------
assignee: docs at python
components: Documentation
messages: 225659
nosy: Alexander.Patrakov, docs at python
priority: normal
severity: normal
status: open
title: Possibly incorrect example is given for socket.getaddrinfo()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 22 16:57:28 2014
From: report at bugs.python.org (Simon Zack)
Date: Fri, 22 Aug 2014 14:57:28 +0000
Subject: [New-bugs-announce] [issue22250] unittest lowercase methods
Message-ID: <1408719448.02.0.0961602464064.issue22250@psf.upfronthosting.co.za>


New submission from Simon Zack:

The python unittest module currently uses camel case. This feels rather inconsistent with the rest of the python library, which is in lower case and follows PEP8.

Would it be a good idea to add lower-case aliases, and possibly deprecate the camel case methods in the future?

----------
components: Library (Lib)
messages: 225673
nosy: simonzack
priority: normal
severity: normal
status: open
title: unittest lowercase methods
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 22 17:59:53 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 22 Aug 2014 15:59:53 +0000
Subject: [New-bugs-announce] [issue22251] Various markup errors in
	documentation
Message-ID: <1408723193.3.0.461529652893.issue22251@psf.upfronthosting.co.za>


New submission from Berker Peksag:

/home/berker/projects/cpython/default/Doc/extending/newtypes.rst:985: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/faq/library.rst:700: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/argparse.rst:1896: ERROR: Error in "warning" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/asyncio-eventloop.rst:200: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/asyncio-protocol.rst:397: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/asyncio-protocol.rst:405: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/asyncio-task.rst:271: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/email.contentmanager.rst:404: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/logging.handlers.rst:867: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/multiprocessing.rst:853: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/os.rst:59: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/pathlib.rst:34: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/pathlib.rst:40: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/pathlib.rst:43: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/pickle.rst:143: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/ssl.rst:269: ERROR: Error in "note" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/ssl.rst:934: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/statistics.rst:138: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/stdtypes.rst:3874: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/sys.rst:800: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/library/warnings.rst:43: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/using/cmdline.rst:109: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/using/cmdline.rst:161: ERROR: Error in "seealso" directive:
invalid option block.

/home/berker/projects/cpython/default/Doc/using/cmdline.rst:364: ERROR: Error in "seealso" directive:
invalid option block.

----------
assignee: berker.peksag
components: Documentation
files: markup.diff
keywords: easy, patch
messages: 225682
nosy: berker.peksag, ezio.melotti, georg.brandl
priority: low
severity: normal
stage: patch review
status: open
title: Various markup errors in documentation
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36435/markup.diff

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

From report at bugs.python.org  Fri Aug 22 19:31:19 2014
From: report at bugs.python.org (Hristo Venev)
Date: Fri, 22 Aug 2014 17:31:19 +0000
Subject: [New-bugs-announce] [issue22252] ssl blocking IO errors
Message-ID: <1408728679.49.0.938853718586.issue22252@psf.upfronthosting.co.za>


New submission from Hristo Venev:

ssl.SSLWantReadError and ssl.SSLWantWriteError should inherit io.BlockingIOError.

Generic code that works with non-blocking sockets will stop working with SSLSockets.

Does anybody have any idea if SSLSocket.read() will need to write to the underlying socket or SSLSocket.write() need to read from it? AFAIK they don't.

Assuming that ssl.SSLWantReadErorr and ssl.SSLWantWriteError perfectly map to io.BlockingIOError (except during handshake).

----------
components: Library (Lib)
messages: 225687
nosy: h.venev
priority: normal
severity: normal
status: open
title: ssl blocking IO errors
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 22 20:22:48 2014
From: report at bugs.python.org (kernc)
Date: Fri, 22 Aug 2014 18:22:48 +0000
Subject: [New-bugs-announce] [issue22253] ConfigParser does not handle files
	without sections
Message-ID: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za>


New submission from kernc:

ConfigParser does not handle files that specify options in the "global" section (first option specified before any section is). This configuration "behavior" is present in the configuration files in the wild [1, 2], and while the naive workaround is simple, ... really?!

The support for section-less configuration would also play nice with various "POSIX-compatible config files" (think /etc/default/*, /etc/os-release, ...).

Ideally, the support could be enabled by default or only when `strict=False` constructor argument is supplied. The options in this global section could likely be accessed in the empty ('') section, e.g. `config.get('', 'option')`.

Thus, ConfigParser could finally really replace the venerable ConfigObj [3].

[1]: http://stackoverflow.com/a/22501121/
[2]: https://www.google.com/search?q=MissingSectionHeaderError%3A+File+contains+no+section+headers
[3]: http://www.voidspace.org.uk/python/configobj.html

----------
components: Library (Lib)
messages: 225693
nosy: kernc
priority: normal
severity: normal
status: open
title: ConfigParser does not handle files without sections
type: behavior
versions: Python 2.7, Python 3.2, Python 3.5

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

From report at bugs.python.org  Fri Aug 22 21:15:49 2014
From: report at bugs.python.org (leiju)
Date: Fri, 22 Aug 2014 19:15:49 +0000
Subject: [New-bugs-announce] [issue22254] match object generated by
	re.finditer cannot call	groups() on mac
Message-ID: <1408734949.75.0.57891888511.issue22254@psf.upfronthosting.co.za>


New submission from leiju:

See the simple test below:


failed on 13.3.0 Darwin Kernel Version 13.3.0, Python 2.7.8:
============================================================

Python 2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> 
>>> 
>>> import re
>>> 
>>> p = '(abc)|(def)|(xyz)'
>>> s = 'abcdefxyz'
>>> 
>>> 
>>> for s in re.finditer(p, s): print s.groups()
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/re.py", line 186, in finditer
    return _compile(pattern, flags).finditer(string)
TypeError: expected string or buffer
>>



same test succeeds on Windows 7 professional:
============================================


Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>> p = '(abc)|(def)|(xyz)'
>>> s = 'abcdefxyz'
>>>
>>> import re
>>>
>>> for x in re.finditer(p, s): print x.groups()
...
('abc', None, None)
(None, 'def', None)
(None, None, 'xyz')
>>>
>>>
>>>
>>>




same test succeeds on freedbsd 7.4. Python 2.7.1:
=================================================



Python 2.7.1 (r271:86832, Jan 31 2011, 17:18:31) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> p = '(abc)|(def)|(xyz)'
>>> s = 'abcdefxyz'
>>> for s in re.finditer(p, s): print s.groups()
... 
('abc', None, None)
(None, 'def', None)
(None, None, 'xyz')
>>> 
>>> 
>>> 
>>>

----------
assignee: ronaldoussoren
components: Macintosh, Regular Expressions
messages: 225697
nosy: ezio.melotti, leiju, mrabarnett, ronaldoussoren
priority: normal
severity: normal
status: open
title: match object generated by re.finditer cannot call groups() on mac
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug 23 02:38:58 2014
From: report at bugs.python.org (Michael McAuliffe)
Date: Sat, 23 Aug 2014 00:38:58 +0000
Subject: [New-bugs-announce] [issue22255] Multiprocessing freeze_support
	raises RuntimeError
Message-ID: <1408754338.93.0.431000117242.issue22255@psf.upfronthosting.co.za>


New submission from Michael McAuliffe:

On Windows, I froze a script that uses multiprocessing with cx-freeze and Python 3.4.1 that had freeze_support() in the "if __name__ == '__main__'" section of the main module, and the resulting executable crashes with a RuntimeError 'context has already been set'.

The error happens in a call to set_start_method in multiprocessing.spawn's prepare function, and changing the line in spawn.py from:

if 'start_method' in data:
    set_start_method(data['start_method'])

to:

if 'start_method' in data:
    set_start_method(data['start_method'], force = True)

allows the frozen executable to successfully run.

----------
components: Library (Lib)
messages: 225719
nosy: Michael.McAuliffe
priority: normal
severity: normal
status: open
title: Multiprocessing freeze_support raises RuntimeError
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 23 11:12:01 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Aug 2014 09:12:01 +0000
Subject: [New-bugs-announce] [issue22256] pyvenv should display a progress
	indicator while	creating an environment
Message-ID: <1408785121.12.0.569760630469.issue22256@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Creating an environment with pyvenv or "python -m venv" in 3.4+ can be a bit disconcerting, as it may take some time (especially on older machines).

It would be good if the command line utility displayed some kind of marking while this operation was in progress.

(The delay seems to be mostly due to ensurepip - running "./python -m venv --without-pip" under my 3.4 checkout is relatively fast, at least on my system)

----------
components: Library (Lib)
messages: 225737
nosy: dstufft, ncoghlan, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: pyvenv should display a progress indicator while creating an environment
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug 23 12:22:31 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Aug 2014 10:22:31 +0000
Subject: [New-bugs-announce] [issue22257] PEP 432: Redesign the interpreter
	startup sequence
Message-ID: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

PEP 432 describes a plan to redesign how the interpreter startup sequence is implemented.

This is a placeholder issue to be used to help track other problems which can't easily be fixed without those changes.

----------
components: Interpreter Core
messages: 225738
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PEP 432: Redesign the interpreter startup sequence
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug 23 15:20:24 2014
From: report at bugs.python.org (Igor Pashev)
Date: Sat, 23 Aug 2014 13:20:24 +0000
Subject: [New-bugs-announce] [issue22258] Use FD_CLOEXEC in
	Python/fileutils.c
Message-ID: <1408800024.14.0.0329688839383.issue22258@psf.upfronthosting.co.za>


New submission from Igor Pashev:

I've found on illumos-based OS that under some conditions python is unable to open any files because set_inheritable() fails. This happens even when building python when it cannot find (open) _sysconfigdata.py.

The problem is that set_inheritable() first checks for FIOCLEX/FIONCLEX ioctls and tries to use them if such macros are defined. These macros can be defined at illumos, but kernel does not support them (inappropriate ioctl). Since other pieces of python already use FD_CLOEXEC unconditionally, including get_inheritable() I patched set_inheritable() to use FD_CLOEXEC. See attached patch.

----------
components: Build, IO
files: dyson-set_inheritable.patch
keywords: patch
messages: 225745
nosy: igor.pashev
priority: normal
severity: normal
status: open
title: Use FD_CLOEXEC in Python/fileutils.c
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file36443/dyson-set_inheritable.patch

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

From report at bugs.python.org  Sat Aug 23 19:37:32 2014
From: report at bugs.python.org (Brian Kearns)
Date: Sat, 23 Aug 2014 17:37:32 +0000
Subject: [New-bugs-announce] [issue22259] fdopen of directory causes
	segmentation fault
Message-ID: <1408815452.53.0.984396531555.issue22259@psf.upfronthosting.co.za>


Changes by Brian Kearns <bdkearns at gmail.com>:


----------
files: fdopen-directory.patch
keywords: patch
nosy: bdkearns
priority: normal
severity: normal
status: open
title: fdopen of directory causes segmentation fault
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file36444/fdopen-directory.patch

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

From report at bugs.python.org  Sat Aug 23 22:10:39 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 23 Aug 2014 20:10:39 +0000
Subject: [New-bugs-announce] [issue22260] Rearrange tkinter tests,
	use test discovery
Message-ID: <1408824639.7.0.685120896496.issue22260@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch rearranges the tkinter tests and strips out all of their custom test finding/loading code in favor of test discovery.  The high points:

- Lib/tkinter/test/ -> Lib/test/test_tkinter/,
  Lib/tkinter/test/test_tkinter/ -> Lib/test/test_tkinter/test_tk/ (all other files keep the same name)
- Lib/test/test_tcl.py -> Lib/test/test_tkinter/test_tcl.py
- test_tk.py, test_ttk_guionly.py, and test_ttk_textonly.py in Lib/test/ disappear.
- setUpModule in test_tkinter.widget_tests is renamed and moved to test_tkinter.support as setUpGUIModule, which takes the name of the module as an argument for a nice message from test.support.requires('gui').  I'm not entirely happy with how setUpGUIModule turned out and works, suggestions are very welcome.
- each ttk test uses a new test_tkinter.support.check_ttk_availability, which is based on the toplevel code from the old test.test_ttk_guionly.  I haven't had a chance to test how it works on a system without ttk.

----------
components: Tests, Tkinter
files: test_tkinter.diff
keywords: patch
messages: 225760
nosy: serhiy.storchaka, terry.reedy, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Rearrange tkinter tests, use test discovery
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36445/test_tkinter.diff

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

From report at bugs.python.org  Sun Aug 24 02:31:27 2014
From: report at bugs.python.org (sbspider)
Date: Sun, 24 Aug 2014 00:31:27 +0000
Subject: [New-bugs-announce] [issue22261] Concurrent Build when using MsBuild
Message-ID: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>


New submission from sbspider:

I was building the cpython code a while back, and noticed that the build system was using msbuild, when 
PCBuild\built.bad -e -d 
was ran. Upon further investigation, it seems that the /m compiler flag is not included. This flag would allow for concurrent builds, considerably speeding up the build time. Therefore, I would like to propose the addition of the /m flag to the build.bat file, so that builds on multi-core systems can be considerable accelerated.

----------
components: Build
messages: 225775
nosy: sbspider
priority: normal
severity: normal
status: open
title: Concurrent Build when using MsBuild
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Aug 24 03:46:06 2014
From: report at bugs.python.org (sbspider)
Date: Sun, 24 Aug 2014 01:46:06 +0000
Subject: [New-bugs-announce] [issue22262] Python External Libraries are
	stored in directory above	where source code is located.
Message-ID: <1408844766.42.0.17140873561.issue22262@psf.upfronthosting.co.za>


New submission from sbspider:

When trying to compile cpython, it puts dependencies like tkinter in the directory above the hg directory. Since I have a highly defined directory structure, this can become quite annoying. Therefore, I would like to propose having the build system download the files into the same root directory as where the code is, but in a folder that will be ignored for source control.

----------
components: Build
messages: 225785
nosy: sbspider
priority: normal
severity: normal
status: open
title: Python External Libraries are stored in directory above where source code is located.
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug 24 08:47:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Aug 2014 06:47:43 +0000
Subject: [New-bugs-announce] [issue22263] Add a resource for CLI tests
Message-ID: <1408862863.59.0.941781918479.issue22263@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some modules have command-line interface (not always documented and tested). Their tests run a lot of subprocesses and requires long time, often longer than other tests of corresponding module. However command-line interface itself is much less important than Python interface. In the face of addition of more CLI tests it would be good to introduce new resource ("commandline" or "cli") which will control the run of such tests.

----------
components: Tests
messages: 225796
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka, zach.ware
priority: normal
severity: normal
status: open
title: Add a resource for CLI tests
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Aug 24 14:45:41 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Aug 2014 12:45:41 +0000
Subject: [New-bugs-announce] [issue22264] Add wsgiref.fix_encoding
Message-ID: <1408884341.89.0.273491669506.issue22264@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The WSGI 1.1 standard mandates that binary data be decoded as latin-1 text: http://www.python.org/dev/peps/pep-3333/#unicode-issues

This means that many WSGI headers will in fact contain *improperly encoded data*. Developers working directly with WSGI (rather than using a WSGI framework like Django, Flask or Pyramid) need to convert those strings back to bytes and decode them properly before passing them on to user applications.

I suggest adding a simple "fix_encoding" function to wsgiref that covers this:

    def fix_encoding(data, encoding, errors="surrogateescape"):
        return data.encode("latin-1").decode(encoding, errors)

The primary intended benefit is to WSGI related code more self-documenting. Compare the proposal with the status quo:

    data = wsgiref.fix_encoding(data, "utf-8")
    data = data.encode("latin-1").decode("utf-8", "surrogateescape")

The proposal hides the mechanical details of what is going on in order to emphasise *why* the change is needed, and provides you with a name to go look up if you want to learn more.

The latter just looks nonsensical unless you're already familiar with this particular corner of the WSGI specification.

----------
messages: 225814
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add wsgiref.fix_encoding
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug 24 22:25:50 2014
From: report at bugs.python.org (Brian Kearns)
Date: Sun, 24 Aug 2014 20:25:50 +0000
Subject: [New-bugs-announce] [issue22265] fix reliance on refcounting in
	test_itertools
Message-ID: <1408911950.94.0.0795549141381.issue22265@psf.upfronthosting.co.za>


New submission from Brian Kearns:

The test fails on Python implementations with non-refcounted GCs without this line.

----------
files: test_itertools.patch
keywords: patch
messages: 225835
nosy: bdkearns
priority: normal
severity: normal
status: open
title: fix reliance on refcounting in test_itertools
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36455/test_itertools.patch

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

From report at bugs.python.org  Sun Aug 24 22:35:11 2014
From: report at bugs.python.org (Brian Kearns)
Date: Sun, 24 Aug 2014 20:35:11 +0000
Subject: [New-bugs-announce] [issue22266] fix reliance on refcounting in
	tarfile.gzopen
Message-ID: <1408912511.19.0.18672535508.issue22266@psf.upfronthosting.co.za>


New submission from Brian Kearns:

tarfile.gzopen relies on refcounting to close the fileobj when the fileobj is created during the call to gzopen (when it is not passed in). Since the fileobj is created outside of GzipFile, GzipFile does not take responsibility for closing the fileobj (so no one does, aside from the GC, which leads to unexpected behavior when using a non-refcounted GC).

This is fixed by having GzipFile open the fileobj itself, so it does take responsibility for closing it when necessary. The same approach is taken in tarfile.py in py3k branch.

----------
files: tarfile.patch
keywords: patch
messages: 225836
nosy: bdkearns
priority: normal
severity: normal
status: open
title: fix reliance on refcounting in tarfile.gzopen
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36456/tarfile.patch

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

From report at bugs.python.org  Sun Aug 24 23:32:46 2014
From: report at bugs.python.org (Brian Kearns)
Date: Sun, 24 Aug 2014 21:32:46 +0000
Subject: [New-bugs-announce] [issue22267] fix reliance on refcounting in
	test_weakref
Message-ID: <1408915966.95.0.000902889858477.issue22267@psf.upfronthosting.co.za>


New submission from Brian Kearns:

The test fails on Python implementations with non-refcounted GCs without these lines. Should go on py3k branches also.

----------
files: test_weakref.patch
keywords: patch
messages: 225839
nosy: bdkearns
priority: normal
severity: normal
status: open
title: fix reliance on refcounting in test_weakref
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36457/test_weakref.patch

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

From report at bugs.python.org  Mon Aug 25 00:17:47 2014
From: report at bugs.python.org (Gregory Salvan)
Date: Sun, 24 Aug 2014 22:17:47 +0000
Subject: [New-bugs-announce] [issue22268] mrohasattr and mrogetattr
Message-ID: <1408918667.95.0.696624554898.issue22268@psf.upfronthosting.co.za>


New submission from Gregory Salvan:

It's a small refactoring.

Lurking at collections.abc I found a lot of: 
>>> any(attr in B.__dict__ for B in C.__mro__)

also repeated in typing.py of mypy:
https://github.com/JukkaL/mypy/blob/master/lib-typing/3.2/typing.py#L117

It seems to be a common operation to check or get an attribute from mro in abc, so I thought it could help to have dedicated functions to enhance readability.
(see patch e.g. Hash.__subclasshook__ takes 1 line intead of 7...)

----------
components: Library (Lib)
files: mroattr.patch
keywords: patch
messages: 225842
nosy: Gregory.Salvan
priority: normal
severity: normal
status: open
title: mrohasattr and mrogetattr
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36458/mroattr.patch

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

From report at bugs.python.org  Mon Aug 25 00:32:24 2014
From: report at bugs.python.org (Min RK)
Date: Sun, 24 Aug 2014 22:32:24 +0000
Subject: [New-bugs-announce] [issue22269] Resolve distutils option conflicts
	with priorities
Message-ID: <1408919544.9.0.398406846461.issue22269@psf.upfronthosting.co.za>


New submission from Min RK:

Background:

Some Python distros (OS X, Debian, Homebrew, others) want the default installation prefix for packages to differ from sys.prefix. OS X and Debian accomplish this by patching distutils itself, with special cases like `if sys.prefix == '/System/Library/...': actually_do_something_else()`. Homebrew accomplishes this by writing a `distutils.cfg` with:

    [install]
    prefix = /usr/local

The distutils.cfg approach is certainly simpler than shipping a patch, but has its own problems, because distutils doesn't differentiate the *source* of configuration options when resolving conflicts. That means that you can't do `python setup.py install --user` because it fails with the error "can't combine user with prefix, ..." without also specifying `--prefix=''` to eliminate the conflict.

Proposal:

I've included a patch for discussion, which uses the fact that the option_dict tracks the source of each option, and keeps track of the load order of each. In the case of an option conflict, the option that came from the lower priority source is unset back to None. If they come from the same source, then the same conflict error message is displayed as before.

Even if this patch is rejected as madness, as I expect it might be, official  recommendations on how to address the root question of `sys.prefix != install_prefix` would be appreciated.

----------
components: Distutils
files: distutils_conflict.patch
keywords: patch
messages: 225843
nosy: dstufft, eric.araujo, minrk
priority: normal
severity: normal
status: open
title: Resolve distutils option conflicts with priorities
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36459/distutils_conflict.patch

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

From report at bugs.python.org  Mon Aug 25 01:33:46 2014
From: report at bugs.python.org (Jonas Jelten)
Date: Sun, 24 Aug 2014 23:33:46 +0000
Subject: [New-bugs-announce] [issue22270] cache version selection for
	documentation
Message-ID: <1408923226.6.0.0114591743234.issue22270@psf.upfronthosting.co.za>


New submission from Jonas Jelten:

The Python version selection for the documentation should be cached.
It's very annoying having to select the preferred version each time one follows a link, e.g. search result, irc post, etc.

I'd like to see caching the preferred version in a cookie and automatically switching to this python version when opening doc pages.

----------
assignee: docs at python
components: Documentation
messages: 225847
nosy: docs at python, thejj
priority: normal
severity: normal
status: open
title: cache version selection for documentation
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/issue22270>
_______________________________________

From report at bugs.python.org  Mon Aug 25 03:41:16 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Aug 2014 01:41:16 +0000
Subject: [New-bugs-announce] [issue22271] Deprecate PyUnicode_AsUnicode():
	emit a	DeprecationWarning
Message-ID: <1408930876.51.0.0157656751737.issue22271@psf.upfronthosting.co.za>


New submission from STINNER Victor:

With the PEP 393 implemented in Python 3.3, PyUnicode_AsUnicode() and all similar functions have to convert the compact string to a heavy wchar_t* string (UCS-4 on Linux: 4 bytes per character, UTF-16 on Windows: 2 or 4 bytes per character) which is stored in the string. The heavy "Py_UNICODE*" storage is kept until the string is destroyed, which may only occur at Python exit.

To reduce the memory footprint, it would be nice to promote the usage of the PEP 393 and start to emit a DeprecationWarning warning. The Py_UNICODE type and all related functions are already deprecated in the documentation.

The deprecate PyUnicode_AsUnicode(), we should stop using it in Python itself. For example, PyUnicode_AsWideCharString() can be used to encode filenames on Windows, it doesn't store the encoded string in the Python object. See for example path_converter() in posixmodule.c.

----------
messages: 225860
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: Deprecate PyUnicode_AsUnicode(): emit a DeprecationWarning
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug 25 18:26:49 2014
From: report at bugs.python.org (A. Libotean)
Date: Mon, 25 Aug 2014 16:26:49 +0000
Subject: [New-bugs-announce] [issue22272] sqlite3 memory leaks in
	cursor.execute
Message-ID: <1408984009.79.0.485457532586.issue22272@psf.upfronthosting.co.za>


New submission from A. Libotean:

There are significant memory leaks when multiple insert statements are executed with distinct values.

sqlite3 version is 2.6.0

The attached file contains two variants:

* one which uses string interpolation to build the query: this generates severe leakeage
* the other one is using parametrized queries and the leakeage is not as bad

I'm assuming that somehow the query string reference is not freed properly.

----------
components: Extension Modules
files: leaking.py
messages: 225878
nosy: alibotean, ghaering
priority: normal
severity: normal
status: open
title: sqlite3 memory leaks in cursor.execute
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file36470/leaking.py

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

From report at bugs.python.org  Mon Aug 25 19:33:22 2014
From: report at bugs.python.org (Weeble)
Date: Mon, 25 Aug 2014 17:33:22 +0000
Subject: [New-bugs-announce] [issue22273] abort when passing certain structs
	by value using ctypes
Message-ID: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za>


New submission from Weeble:

I'm not 100% certain this is a bug yet, but I'm beginning to think it's likely.

On 64-bit Linux, I can't pass a struct like this:

    struct S { uint8_t data[16]; };

...to a function declared like this:

    void f(struct S);

>From experimentation with various integer types and array sizes, it seems this causes an abort somewhere in libffi any time the array is between 9 and 16 bytes in size. If the array is smaller or larger than that, the calls work as expected.

I've asked about this here: http://stackoverflow.com/questions/25487928/is-this-the-correct-way-to-pass-a-struct-by-value-in-ctypes

Here's some test code:

## sum.cpp

    #include <cstdint>

    using std::size_t;

    struct ArrayStruct {
        // We'll define ARRAY_TYPE and ARRAY_SIZE on the
        // command-line when we compile.
        std::ARRAY_TYPE data[ARRAY_SIZE];
    };

    extern "C" int64_t sum(struct ArrayStruct array)
    {
        int64_t acc=0;
        for (size_t i=0; i!=ARRAY_SIZE; ++i)
        {
            acc+=array.data[i];
        }
        return acc;
    }

## sum.py
    import ctypes
    import sys

    def main():
        array_size = int(sys.argv[1])
        array_type = sys.argv[2]

        libsum = ctypes.cdll.LoadLibrary('./libsum.so')

        ArrType = getattr(ctypes, 'c_' + array_type) * array_size

        class MyStruct(ctypes.Structure):
            _fields_ = [("data", ArrType)]

        m=MyStruct()
        for i in range(array_size):
            m.data[i]=i

        print(libsum.sum(m))

    if __name__ == '__main__':
        main()

## Build/run

    $ g++ -g -shared -Wall -fPIC sum.cpp -o libsum.so -std=c++11 -D ARRAY_SIZE=16 -D ARRAY_TYPE=uint8_t && python3 sum.py 16 uint8
    Aborted (core dumped)

I poked around a little bit in gdb. It's aborting in libffi's "ffi_call" function: https://github.com/atgreen/libffi/blob/v3.0.13/src/x86/ffi64.c#L516

(gdb) bt
#0  0x00007ffff782cf79 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff7830388 in __GI_abort () at abort.c:89
#2  0x00007ffff67134f5 in ffi_call (cif=0x7fffffffd7b0, fn=0x7ffff650c625 <sum(ArrayStruct)>, rvalue=0x7fffffffd6f0, avalue=0x7fffffffd6d0) at ../src/x86/ffi64.c:516
#3  0x00007ffff691fee3 in _ctypes_callproc () from /usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m-x86_64-linux-gnu.so
#4  0x00007ffff6920578 in ?? () from /usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m-x86_64-linux-gnu.so
#5  0x000000000043810a in PyObject_Call ()
#6  0x0000000000579f45 in PyEval_EvalFrameEx ()
#7  0x000000000057d3d3 in PyEval_EvalCodeEx ()
#8  0x000000000057bfaa in PyEval_EvalFrameEx ()
#9  0x000000000057d3d3 in PyEval_EvalCodeEx ()
#10 0x000000000060ba83 in PyRun_FileExFlags ()
#11 0x000000000060bc85 in PyRun_SimpleFileExFlags ()
#12 0x000000000060d3ac in Py_Main ()
#13 0x000000000041ec0d in main ()
(gdb) frame 2
#2  0x00007ffff67134f5 in ffi_call (cif=0x7fffffffd7b0, fn=0x7ffff650c625 <sum(ArrayStruct)>, rvalue=0x7fffffffd6f0, avalue=0x7fffffffd6d0) at ../src/x86/ffi64.c:516
516			  abort();
(gdb) info args
cif = 0x7fffffffd7b0
fn = 0x7ffff650c625 <sum(ArrayStruct)>
rvalue = 0x7fffffffd6f0
avalue = 0x7fffffffd6d0
(gdb) info locals
a = <optimized out>
j = <optimized out>
size = 8
n = <optimized out>
classes = {X86_64_INTEGER_CLASS, X86_64_NO_CLASS, 4294956784, 32767}
stack = 0x7fffffffd4f0 ""
argp = 0x7fffffffd5a0 "\001"
arg_types = 0x7fffffffd6b0
gprcount = 1
ssecount = <optimized out>
ngpr = 1
nsse = 0
i = <optimized out>
avn = <optimized out>
ret_in_memory = <optimized out>
reg_args = 0x7fffffffd4f0
(gdb) print *cif
$2 = {abi = FFI_UNIX64, nargs = 1, arg_types = 0x7fffffffd6b0, rtype = 0x7ffff6b5e228, bytes = 0, flags = 10}

It looks like we're trying to pass the struct in two registers, which I think is what's supposed to happen, but something is going wrong with the second register. It aborted because it has class X86_64_NO_CLASS and that's not handled by the switch.

I don't know if this is a bug in libffi, or if ctypes is feeding it bad information, or if I'm feeding ctypes bad information. I hope this information is useful for anyone investigating.

I get the same abort in both Python 2.7.6 and 3.4.0.

I originally stumbled across this issue trying to use PySDL2:

http://pysdl2.readthedocs.org/en/rel_0_9_3/

I was trying to call SDL_JoystickGetGUIDString, which uses a similar struct-by-value call:

http://hg.libsdl.org/SDL/file/92ca74200ea5/include/SDL_joystick.h

----------
components: ctypes
messages: 225881
nosy: weeble
priority: normal
severity: normal
status: open
title: abort when passing certain structs by value using ctypes
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 25 23:46:02 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 25 Aug 2014 21:46:02 +0000
Subject: [New-bugs-announce] [issue22274] subprocess.Popen(stderr=STDOUT)
	fails to redirect	subprocess stderr to stdout
Message-ID: <1409003162.0.0.312391949761.issue22274@psf.upfronthosting.co.za>


New submission from Akira Li:

The following command should not produce any output but it does:

  $ ./python >/dev/null -c 'import subprocess as S, sys; S.call([sys.executable, "-c", "import sys; print(42, file=sys.stderr)"], stderr=S.STDOUT)'

Its stdout is redirected to /dev/null. It starts a subprocess with its
stderr redirected to stdout. See "Redirect subprocess stderr to
stdout" [1] on Stackoverflow.

[1] http://stackoverflow.com/questions/11495783/redirect-subprocess-stderr-to-stdout

I've uploaded a patch that fixes the issue on POSIX.

Please, run the provided test (in the patch), to see whether the code
should be fixed on Windows too (it might work as is there).

No documentation changes are required.

Please, review.

----------
components: Library (Lib)
files: subprocess-stderr_redirect_with_no_stdout_redirect.diff
keywords: patch
messages: 225898
nosy: akira
priority: normal
severity: normal
status: open
title: subprocess.Popen(stderr=STDOUT) fails to redirect subprocess stderr to stdout
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file36472/subprocess-stderr_redirect_with_no_stdout_redirect.diff

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

From report at bugs.python.org  Tue Aug 26 01:00:00 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Aug 2014 23:00:00 +0000
Subject: [New-bugs-announce] [issue22275] asyncio: enhance documentation of
	OS support
Message-ID: <1409007600.34.0.690702465035.issue22275@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When reading asyncio documentation, it's not easy to catch limitations of each operating system and event loop. I propose to mention in each mention if the method is not supported in some cases. See attached patch.

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio_os_support.patch
keywords: patch
messages: 225902
nosy: docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: enhance documentation of OS support
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36474/asyncio_os_support.patch

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

From report at bugs.python.org  Tue Aug 26 13:37:22 2014
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Guerra?=)
Date: Tue, 26 Aug 2014 11:37:22 +0000
Subject: [New-bugs-announce] [issue22276] pathlib glob issues
Message-ID: <1409053042.7.0.771163532868.issue22276@psf.upfronthosting.co.za>


New submission from Jo?o Guerra:

Both fnmatch and glob support the "*/" glob. However, pathlib does not seem to handle this kind of globs correctly.

dir = Path("/a/directory/")
file = Path("/a/file")
print(dir.match("*/")) # True
print(file.match("*/")) # True

The "/" is being discarded by the match, resulting in incorrect matches.

Both the fnmatch and glob libraries support this correct.
print(fnmatch("/a/directory/", "*/")) # True
print(fnmatch("/a/file", "*/")) # False


Issue 21039 may be related to this.

----------
components: Library (Lib)
messages: 225914
nosy: joca.bt
priority: normal
severity: normal
status: open
title: pathlib glob issues
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 26 15:06:36 2014
From: report at bugs.python.org (Cristian Consonni)
Date: Tue, 26 Aug 2014 13:06:36 +0000
Subject: [New-bugs-announce] [issue22277] webbrowser.py add parameters to
	suppress output on	stdout and stderr
Message-ID: <1409058396.11.0.385358825237.issue22277@psf.upfronthosting.co.za>


New submission from Cristian Consonni:

Hello,

I would like to propose a patch for the webbrowser module to actively suppress any output (both on stdout and stderr) from the module itself.

At the moment, doing a quick internet search, the best approximation to obtain this kind of behavior seems to be the ones described in [1] and [2].

In the patch attached I am proposing to add two optional arguments: stdout and stderr to webbroswer.open() (and to the related webbroswer.open_new() and webbroswer.open_new_tab())

Setting stdout and stderr to None effectively suppress any terminal output. The default (True), mimics the current behavior.

There are other minor modifications to clean the code (PEP8).

I will send a similar patch for Python 2.7.X

Cristian

[1] https://stackoverflow.com/questions/2323080/how-can-i-disable-the-webbrowser-message-in-python
[2] https://stackoverflow.com/questions/1352361/suppress-redirect-stderr-when-calling-python-webrowser

----------
components: Library (Lib)
files: webbrowser.py.patch
keywords: patch
messages: 225915
nosy: CristianCantoro
priority: normal
severity: normal
status: open
title: webbrowser.py add parameters to suppress output on stdout and stderr
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file36477/webbrowser.py.patch

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

From report at bugs.python.org  Tue Aug 26 19:58:07 2014
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 26 Aug 2014 17:58:07 +0000
Subject: [New-bugs-announce] [issue22278] urljoin duplicate slashes
Message-ID: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za>


New submission from Demian Brecht:

Reported by Stefan Behnel in issue22118:

I'm now getting duplicated slashes in URLs, e.g.:

https://new//foo.html
http://my.little.server/url//logo.gif

In both cases, the base URL that gets joined with the postfix had a trailing slash, e.g.

"http://my.little.server/url/" + "logo.gif" -> "http://my.little.server/url//logo.gif"

----------
components: Library (Lib)
messages: 225923
nosy: demian.brecht
priority: normal
severity: normal
status: open
title: urljoin duplicate slashes
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug 26 20:36:39 2014
From: report at bugs.python.org (Jack O'Connor)
Date: Tue, 26 Aug 2014 18:36:39 +0000
Subject: [New-bugs-announce] [issue22279] read() vs read1() in
	asyncio.StreamReader documentation
Message-ID: <1409078199.01.0.947994403275.issue22279@psf.upfronthosting.co.za>


New submission from Jack O'Connor:

BufferedIOBase and related classes have a read(n) and read1(n). The first will wait until n bytes are available (or EOF), while the second will return as soon as any bytes are available. In asyncio.StreamReader, there is no read1 method, but the read method seems to behave like BufferedIOBase.read1, and there is a readexactly method that behaves like BufferedIOBase.read.

Is there a reason for this naming change? Either way, could the documentation for asyncio.StreamReader.read be clarified?

----------
components: asyncio
messages: 225924
nosy: gvanrossum, haypo, oconnor663, yselivanov
priority: normal
severity: normal
status: open
title: read() vs read1() in asyncio.StreamReader documentation
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 26 23:56:28 2014
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Aug 2014 21:56:28 +0000
Subject: [New-bugs-announce] [issue22280] _decimal: successful import
	despite build failure
Message-ID: <1409090188.54.0.457029960321.issue22280@psf.upfronthosting.co.za>


New submission from Stefan Krah:

This may be related to PEP 451:  Previously, if the _decimal.so build
failed for whatever reason, decimal.py would be used instead. For that
to work, importing _decimal needs to fail.

But now the import is successful:

# Simulate build failure:
rm Modules/_decimal/_decimal.c
./configure --with-pydebug && make

$ ./python 
Python 3.5.0a0 (default:0337a460f05b+, Aug 26 2014, 23:47:43) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _decimal
>>> _decimal.__path__
_NamespacePath(['/home/stefan/pydev/cpython/Modules/_decimal'])

----------
components: Interpreter Core
messages: 225931
nosy: eric.snow, skrah
priority: normal
severity: normal
status: open
title: _decimal: successful import despite build failure
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug 27 03:56:43 2014
From: report at bugs.python.org (Dan O'Reilly)
Date: Wed, 27 Aug 2014 01:56:43 +0000
Subject: [New-bugs-announce] [issue22281]
	ProcessPoolExecutor/ThreadPoolExecutor should
	provide	introspection APIs
Message-ID: <1409104603.02.0.0732918756664.issue22281@psf.upfronthosting.co.za>


New submission from Dan O'Reilly:

As initially discussed on python-ideas, it would be nice if there was a way to query the concurrent.futures Executor objects for information about their internal state - number of total/active/idle workers, number of total/active/waiting tasks, which tasks are active, which are waiting, etc. Some of this information can be determined today by examining the Executor's internal variables, but not all.

I'm attaching a patch that makes a first attempt at adding this support. Currently it adds quite a few methods, though these could be consolidated somewhat if that's preferable. Here's what's I've added, along with possible consolidations:

worker_count() : Total number of workers currently in the pool
active_worker_count() : Number of workers currently processing a work item
idle_worker_count(): Number of workers not processing a work item
(Possible consolidation: worker_counts(): returns a dict containing total/active/idle keys mapped to the above.)

task_count(): Total number of tasks currently being handled by the pool
active_task_count(): Number of tasks currently being processed by workers (Possibly redundant - it will always match active_worker_count())
waiting_task_count(): Number of submitted tasks not yet being processed by a worker
(Possible consolidation: task_counts(): returns a dict containing total/active/waiting keys mapped to the above.)

active_tasks(): A set of WorkItem objects currently being processed by a worker.
waiting_tasks(): A list of WorkItem objects currently waiting to be processed by a worker.
(Possible consolidation: get_tasks(): returns a dict containing active/waiting keys mapped to the above.)

A WorkItem is an object containing the function object, args tuple, and kwargs dict submitted to the Executor.

ThreadPoolExecutor notes:

For ThreadPoolExecutor, most of this information is made available by changing the worker threads from functions into class instances, and maintaining a small amount of extra state on the instance. The added overhead for users who don't care about using introspection should be very minimal. Note that for waiting_tasks(), we have to introspect the underlying queue.Queue. This is done by locking the queue's internal mutex, and iterating over the queue's internal deque. There was some concern about doing this on the mailing list, so I wanted to call it out. We could alternately implement waiting_tasks by maintaining some data structure (a deque?) of work items that are enqueued in parallel to the actual queue. However, this adds additional memory overhead and implementation complexity (to keep the new deque in sync with the queue's content).

ProcessPoolExecutor notes:

ProcessPoolExecutor uses both a dict and a multiprocessing.Queue internally. Every submitted work item is placed into the dict (which is called _pending_work_items), keyed on a unique work_id. However, only WORKER_COUNT + 1 items are actually placed into the multiprocessing.Queue at a time. This, along with the added IPC complexity and cost, makes the implementation approach a bit different from ThreadPoolExecutor. 

Every method except worker_count() and task_count() require changes in the worker implementation - it now has to send the work_id of the work item it's about to process back to the parent. It does this via a multiprocessing.SimpleQueue that's already being used to send the result of the work item to the parent. The parent process will then store that work_id in a set called _active_work_items. When the actual result of a work item is sent back to the parent, the work_id (which is already included with the result) is removed from the _active_work_items set.

The active_tasks() method can build its set by iterating over work_ids in the _active_tasks set, and looking up the corresponding WorkItem in the _pending_work_items dict. waiting_tasks() can iterate over the _pending_tasks dict and build a list containing any item that isn't present in the _active_tasks set. That list is then sorted by work_id for it to reflect the actual order that the tasks will be placed into the queue. The main source of added overhead for non-users of introspection is the cost of sending the work_id back to the parent process prior to actually processing a WorkItem in the child, along with the small amount of memory used to store the _active_tasks set (which will never be greater than MAX_WORKERS in size). In practice I don't think this will have much noticeable performance impact, except perhaps for cases where there are many tasks which execute very quickly.

Also note that right now there are no docs included in the patch. I want some consensus on the API to be reached prior to writing them.

----------
components: Library (Lib)
files: introspect_executors.diff
keywords: patch
messages: 225941
nosy: dan.oreilly
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor/ThreadPoolExecutor should provide introspection APIs
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36480/introspect_executors.diff

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

From report at bugs.python.org  Wed Aug 27 11:33:26 2014
From: report at bugs.python.org (Fabian)
Date: Wed, 27 Aug 2014 09:33:26 +0000
Subject: [New-bugs-announce] [issue22282] ipaddress module accepts octal
	formatted IPv4 addresses	in IPv6 addresses
Message-ID: <1409132006.4.0.222962839937.issue22282@psf.upfronthosting.co.za>


New submission from Fabian:

The ipaddress module accepts IPv6 addresses if the IPv4 address is formatted as an octal number, but http://tools.ietf.org/html/rfc3986#section-3.2.2 doesn't allow leading zeroes in the IPv4 address.

This is the current behaviour (in 3.4.1):

>>> ipaddress.ip_address("::1.0.0.00")
IPv6Address('::100:0')

Expected:

>>> ipaddress.ip_address("::1.0.0.00")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "3.4.1/lib/python3.4/ipaddress.py", line 54, in ip_address
    address)
ValueError: '::1.0.0.00' does not appear to be an IPv4 or IPv6 address

Because I didn't know it better, I first tried to patch the backport but this might be still applicable the official code: https://github.com/phihag/ipaddress/pull/12

----------
messages: 225950
nosy: xZise
priority: normal
severity: normal
status: open
title: ipaddress module accepts octal formatted IPv4 addresses in IPv6 addresses
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 27 11:43:11 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Aug 2014 09:43:11 +0000
Subject: [New-bugs-announce] [issue22283] "AMD64 FreeBSD 9.0 3.x" fails to
	build the _decimal	module: #error "libmpdec version >= 2.4.1
	required"
Message-ID: <1409132591.68.0.809904957621.issue22283@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/7213/steps/test/logs/stdio

building '_decimal' extension
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DCONFIG_64=1 -DASM=1 -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Include -I/usr/home/buildbot/buildarea/3.x.krah-freebsd/build -c /usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Modules/_decimal/_decimal.c -o build/temp.freebsd-9.0-RELEASE-p3-amd64-3.5-pydebug/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Modules/_decimal/_decimal.o -Wextra -Wno-missing-field-initializers
/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Modules/_decimal/_decimal.c:43:4: error: #error "libmpdec version >= 2.4.1 required"

----------
messages: 225951
nosy: haypo, koobs, skrah
priority: normal
severity: normal
status: open
title: "AMD64 FreeBSD 9.0 3.x" fails to build the _decimal module: #error "libmpdec version >= 2.4.1 required"
type: compile error

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

From report at bugs.python.org  Wed Aug 27 11:59:40 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Aug 2014 09:59:40 +0000
Subject: [New-bugs-announce] [issue22284] decimal module contains less
	symbols when the _decimal	module is missing
Message-ID: <1409133580.95.0.644404743555.issue22284@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While investigation issue #22283, I noticed that when the _decimal is present, the decimal looses its __all__ attribute. dir(decimal) contains 5 more symbols than decimal.__all__:
{'ConversionSyntax',
 'DecimalTuple',
 'DivisionImpossible',
 'DivisionUndefined',
 'InvalidContext'}

These symbols should be added to decimal.__all__, or _decimal should also have a __all__ attribute.

----------
messages: 225954
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: decimal module contains less symbols when the _decimal module is missing
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug 27 12:07:47 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Aug 2014 10:07:47 +0000
Subject: [New-bugs-announce] [issue22285] The Modules/ directory should not
	be added to sys.path
Message-ID: <1409134067.89.0.764298356643.issue22285@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When Python is built from source, the "Modules/" subdirectory is added to sys.path on UNIX. I don't understand why: it does not contain .py files nor .so dynamic modules. Dynamic modules are built in "build/lib.linux-x86_64-3.5-pydebug".

A side effect of adding Modules/ subdirectory to sys.path is that Modules subdirectories (ex: _sqlite, _ctypes, _io, _decimal, etc.) can be used as packages.

For example, when the _decimal module cannot be compiled, Lib/decimal.py uses Modules/_decimal as a Python package which is wrong. The decimal becomes an empty module (no symbol, because Modules/_decimal does not contain an __init__.py nor any .so file) because decimal.py uses "import _decimal" at the end (see decimal.py).

Attached patch removes Modules/ from sys.path on UNIX.

Maybe adding Modules/ to sys.path was useful before the introduction of pybuildir.txt? See issue #9589 and the changeset 4742e7aea2f5 (and the issue #586680).

----------
files: getpath_no_modules.patch
keywords: patch
messages: 225955
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: The Modules/ directory should not be added to sys.path
Added file: http://bugs.python.org/file36484/getpath_no_modules.patch

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

From report at bugs.python.org  Wed Aug 27 12:50:20 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Aug 2014 10:50:20 +0000
Subject: [New-bugs-announce] [issue22286] Allow backslashreplace error
	handler to be used on input
Message-ID: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In the discussion on issue 18814, Antoine pointed out that in a Python 3 world, using backslashescape during decoding actually makes sense - it lets you accurately report arbitrary bytes in the sequence, without needing surrogateescape or surrogatepass to be used when encoding later.

----------
messages: 225966
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow backslashreplace error handler to be used on input
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug 27 12:51:55 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Aug 2014 10:51:55 +0000
Subject: [New-bugs-announce] [issue22287] Use clock_gettime() in pytime.c
Message-ID: <1409136715.28.0.0370137744033.issue22287@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On UNIX, time.time() currently uses clock_gettime(), but _PyTime_gettimeofday() doesn't becauce pytime.c lacks a dependency on the librt module (needed on some platforms).

Attached patch adds the dependency if needed and modify _PyTime_gettimeofday() to use clock_gettime() if available.

The patch alone is not very useful. I wrote it to prepare the work for the issue #22043 (use a monotonic clock in Python modules written in C).

With the patch, Python depends on the librt on Solaris and on Linux with glibc older than 2.17 (clock_gettime is now available directly in the libc since glibc 2.17).

----------
files: clock_gettime.patch
keywords: patch
messages: 225967
nosy: haypo, loewis, neologix
priority: normal
severity: normal
status: open
title: Use clock_gettime() in pytime.c
versions: Python 3.5
Added file: http://bugs.python.org/file36485/clock_gettime.patch

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

From report at bugs.python.org  Wed Aug 27 12:55:55 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 27 Aug 2014 10:55:55 +0000
Subject: [New-bugs-announce] [issue22288] Incorrect Call grammar in
	documentation
Message-ID: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The changes for issue #3473 introduced a documentation bug. The Call expression grammar implies that f(*[1, 2], *[3, 4]) is allowed:

| "*" `expression` ["," "*" `expression`] ["," "**" `expression`]

I think Benjamin meant to use:

| "*" `expression` ["," `keyword_arguments `] ["," "**" `expression`]

instead, see the corresponding commit for Python 3.x: http://hg.python.org/cpython/diff/6abada05c313/Doc/reference/expressions.rst

----------
assignee: docs at python
components: Documentation
messages: 225970
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Incorrect Call grammar in documentation
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 27 14:27:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Aug 2014 12:27:29 +0000
Subject: [New-bugs-announce] [issue22289] support.transient_internet()
	doesn't catch timeout on	FTP tests of test_urllib2net
Message-ID: <1409142449.68.0.105373691369.issue22289@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch should fix the following sporadic error. I wrote the patch for Python 3.5. I will adapt it for Python 2.7 and 3.4 if the review is positive.

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/4837/steps/test/logs/stdio

======================================================================
ERROR: test_ftp_basic (test.test_urllib2net.TimeoutTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1388, in ftp_open
    fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1410, in connect_ftp
    persistent=False)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2232, in __init__
    self.init()
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2238, in init
    self.ftp.connect(self.host, self.port, self.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/ftplib.py", line 153, in connect
    source_address=self.source_address)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 655, in create_connection
    raise err
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 646, in create_connection
    sock.connect(sa)
TimeoutError: [Errno 110] Connection timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 308, in test_ftp_basic
    u = _urlopen_with_retry(self.FTP_HOST)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 33, in wrapped
    return _retry_thrice(func, exc, *args, **kwargs)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 29, in _retry_thrice
    raise last_exc
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice
    return func(*args, **kwargs)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 153, in urlopen
    return opener.open(url, data, timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 455, in open
    response = self._open(req, data)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 473, in _open
    '_open', req)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 433, in _call_chain
    result = func(*args)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1406, in ftp_open
    raise exc.with_traceback(sys.exc_info()[2])
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1388, in ftp_open
    fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1410, in connect_ftp
    persistent=False)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2232, in __init__
    self.init()
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2238, in init
    self.ftp.connect(self.host, self.port, self.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/ftplib.py", line 153, in connect
    source_address=self.source_address)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 655, in create_connection
    raise err
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 646, in create_connection
    sock.connect(sa)
urllib.error.URLError: <urlopen error ftp error: TimeoutError(110, 'Connection timed out')>

----------
components: Tests
files: transient_internet_ftp_timeout.patch
keywords: patch
messages: 225979
nosy: haypo
priority: normal
severity: normal
status: open
title: support.transient_internet() doesn't catch timeout on FTP tests of test_urllib2net
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36486/transient_internet_ftp_timeout.patch

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

From report at bugs.python.org  Wed Aug 27 15:11:23 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Aug 2014 13:11:23 +0000
Subject: [New-bugs-announce] [issue22290] "AMD64 OpenIndiana 3.x" buildbot:
	assertion failed in	PyObject_Call() in
	test_subprocess.test_preexec()
Message-ID: <1409145083.35.0.252869476366.issue22290@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I ran test_subprocess.test_preexec() 2000 times: I'm unable to reproduce the issue on my OpenIndiana VM, nor on Linux. I used this command:
gdb -args ./python -m test -F -m test_preexec test_subprocess 

The command on the buildbot is:
./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 -j4

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8549/steps/test/logs/stdio

[302/390/1] test_subprocess
Assertion failed: (result != NULL && !PyErr_Occurred()) || (result == NULL && PyErr_Occurred()), file Objects/abstract.c, line 2091
Fatal Python error: Aborted

Current thread 0x0000000000000001 (most recent call first):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 1396 in _execute_child
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 865 in __init__
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_subprocess.py", line 1303 in test_preexec
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 577 in run
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 625 in __call__
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 125 in run
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 87 in __call__
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 125 in run
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 87 in __call__
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/runner.py", line 168 in run
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/support/__init__.py", line 1750 in _run_suite
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/support/__init__.py", line 1784 in run_unittest
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_subprocess.py", line 2470 in test_main
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1280 in runtest_inner
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 967 in runtest
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 532 in main
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1564 in main_in_temp_cwd
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1589 in <module>
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 85 in _run_code
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 170 in _run_module_as_main

----------
messages: 225984
nosy: haypo
priority: normal
severity: normal
status: open
title: "AMD64 OpenIndiana 3.x" buildbot: assertion failed in PyObject_Call() in test_subprocess.test_preexec()

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

From report at bugs.python.org  Wed Aug 27 17:17:31 2014
From: report at bugs.python.org (Ben Rodrigue)
Date: Wed, 27 Aug 2014 15:17:31 +0000
Subject: [New-bugs-announce] [issue22291] Typo in docs - Lib/random
Message-ID: <1409152651.69.0.302549196397.issue22291@psf.upfronthosting.co.za>


New submission from Ben Rodrigue:

Small typo: 

In the documentation for the random module. The documentation refers to the semi-open range and then gives an example using a left bracket and then a curved parenthesis on the right. 

Link to page:https://docs.python.org/3.4/library/random.html

>From text:"which generates a random float uniformly in the semi-open range [0.0, 1.0)"  

I am new to programming but I believe this to be incorrect. If there is a way to submit a patch for the documentation, I am happy to do so.

----------
assignee: docs at python
components: Documentation
messages: 225990
nosy: benrodrigue, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Typo in docs - Lib/random
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 27 23:51:47 2014
From: report at bugs.python.org (attilio.dinisio)
Date: Wed, 27 Aug 2014 21:51:47 +0000
Subject: [New-bugs-announce] [issue22292] pickle whichmodule RuntimeError
Message-ID: <1409176307.55.0.719084606817.issue22292@psf.upfronthosting.co.za>


New submission from attilio.dinisio:

= Error message =
pickle.dumps and pickle.dump generate the following error:

  File "/usr/lib/python3.4/pickle.py", line 283, in whichmodule
    for module_name, module in sys.modules.items():
RuntimeError: dictionary changed size during iteration


= Test case = 
The test case is as follows:

    import pickle
    import sys
    import numpy #version 1.8.1
    import scipy.signal #version 0.13.3
    pickle.dumps(numpy.cos)

Sometimes this results in the error

Traceback (most recent call last):
  File "whichmodule_bug.py", line 13, in <module>
    pickle.dumps(numpy.cos)
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 61, in _ufunc_reduce
    return _ufunc_reconstruct, (whichmodule(func, name), name)
  File "/usr/lib/python3.4/pickle.py", line 283, in whichmodule
    for module_name, module in sys.modules.items():
RuntimeError: dictionary changed size during iteration

NOTE: This is not necessarily a problem due to numpy and scipy packages. Explanation follows.


= Relevant code = 
The last version of pickle http://hg.python.org/cpython/file/f6f691ff27b9/Lib/pickle.py contains:
...

def _getattribute(obj, name, allow_qualname=False):
    dotted_path = name.split(".")
    if not allow_qualname and len(dotted_path) > 1:
        raise AttributeError("Can't get qualified attribute {!r} on {!r}; " +
                             "use protocols >= 4 to enable support"
                             .format(name, obj))
    for subpath in dotted_path:
        if subpath == '<locals>':
            raise AttributeError("Can't get local attribute {!r} on {!r}"
                                 .format(name, obj))
        try:
            obj = getattr(obj, subpath)
        except AttributeError:
            raise AttributeError("Can't get attribute {!r} on {!r}"
                                 .format(name, obj))
    return obj

def whichmodule(obj, name, allow_qualname=False):
    """Find the module an object belong to."""
    module_name = getattr(obj, '__module__', None)
    if module_name is not None:
        return module_name
    for module_name, module in sys.modules.items():
        if module_name == '__main__' or module is None:
            continue
        try:
            if _getattribute(module, name, allow_qualname) is obj:
                return module_name
        except AttributeError:
            pass
    return '__main__'
...

= History =
The iteration 

     for module_name, module in sys.modules.items():

in pickle.py was changed in 2007 to

     for name, module in list(sys.modules.items()):

by the BDFL [http://hg.python.org/cpython/rev/0d2dc3611e3b?revcount=800] to "Fix a bizarre error...", then it was reverted by [http://hg.python.org/cpython/rev/992ef855b3ed] in 2013. I hope the BDFL never discover this :-)


= Explanation = 
It seems that while iterating in sys.modules, getattr is called on an instance of scipy.lib.six.MovedModule, which triggers a change in sys.modules (due to an import). This result in the RuntimeError: dictionary changed size during iteration.
Freezing the list, with list(sys.modules.items()) resolves this particular issue.


= Notes on reproducing this error =
Reproducing my test case might be difficult for the following reason.
I installed scipy version 0.13.3 on Kubuntu 14.04 (sudo apt-get install python3-scipy). In the online  source code, module six.py version 1.2.0 is included [https://github.com/scipy/scipy/releases/tag/v0.13.3]. However in my system the module six.py that is actually used is 1.5.2, which probably has been installed independently from scipy. 
Finally, the new version of scipy, 0.14.0, doesn't use the class scipy.lib.six.MovedModule which triggers this error. Unfortunately this new version isn't available in Ubuntu 14.04.

----------
components: Library (Lib)
messages: 226005
nosy: attilio.dinisio, pitrou
priority: normal
severity: normal
status: open
title: pickle whichmodule RuntimeError
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 28 13:05:25 2014
From: report at bugs.python.org (James Westby)
Date: Thu, 28 Aug 2014 11:05:25 +0000
Subject: [New-bugs-announce] [issue22293] mock could be less memory-intensive
Message-ID: <1409223925.36.0.353064472257.issue22293@psf.upfronthosting.co.za>


New submission from James Westby:

Hi,

I'm looking in to the memory usage of our testsuite, which does a fair amount of

  def setUp():
      patcher = patch.multiple(...)
      self.mock_whatever = patcher.start()
      self.addCleanup(patcher.stop)

or other ways of creating a mock and assigning it to an instance variable on a TestCase.

This means that by the end of a run, we have quite a lot of references to MagicMocks.

This then becomes the majority of the memory usage of the python process: (from meliae)

Total 1157176 objects, 1189 types, Total size = 327.1MiB (342972340 bytes)
 Index   Count   %      Size   % Cum     Max Kind
     0  575750  49 198058000  57  57     344 MagicProxy
     1   49955   4  52034888  15  72  196888 dict
     2  124127  10  11881628   3  76  386477 str
     3   12997   1  11749288   3  79     904 type
     4    8225   0   9146200   2  82    1112 MagicMock
     5   66310   5   5282392   1  84   80056 tuple
     6   38161   3   4579320   1  85     120 function
     7    1503   0   3972281   1  86   49488 module
     8   28506   2   3648768   1  87     128 code
     9   25768   2   2869680   0  88   69168 list
    10   12649   1   2803196   0  89   66356 unicode
    11    2251   0   2503112   0  89    1112 ClientHandler
    12    2228   0   2477536   0  90    1112 _patch
    13   28223   2   2257840   0  91      80 instancemethod
    14    2014   0   2239568   0  91    1112 BoundMethodWeakref
    15    2003   0   2227336   0  92    1112 DummyCache
    16   24681   2   2221112   0  93     792 _CallList
    17   18555   1   1632840   0  93      88 weakref
    18    1457   0   1550248   0  94    1064 Morsel
    19   46258   3   1110192   0  94      24 int

The fact that each MagicMock creates 72 MagicProxies means that it is a significant chunk of memory, despite each being small.

John Arbash Meinel suggested setting __slots__ = ['name', 'parent'] on MagicProxy to reduce the memory usage of this simple object.

This helps with the memory usage:

Total 1140377 objects, 1189 types, Total size = 169.5MiB (177755867 bytes)
 Index   Count   %      Size   % Cum     Max Kind
     0   47744   4  51347840  28  28  196888 dict
     1  574210  50  36749440  20  49      64 MagicProxy
     2  122020  10  11769659   6  56  386477 str
     3   12975   1  11729400   6  62     904 type
     4    8203   0   9121736   5  67    1112 MagicMock
     5   64125   5   5141368   2  70   80056 tuple
     6   36024   3   4322880   2  73     120 function
     7    1503   0   3972281   2  75   49488 module
     8   28506   2   3648768   2  77     128 code
     9   12643   1   2801540   1  79   66356 unicode
    10   23634   2   2716064   1  80   69168 list
    11    2251   0   2503112   1  82    1112 ClientHandler
    12   28223   2   2257840   1  83      80 instancemethod
    13    2014   0   2239568   1  84    1112 BoundMethodWeakref
    14    2003   0   2227336   1  85    1112 DummyCache
    15   24615   2   2214536   1  87     792 _CallList
    16   18482   1   1626416   0  87      88 weakref
    17    1457   0   1550248   0  88    1064 Morsel
    18   46259   4   1110216   0  89      24 int
    19    2496   0    858624   0  89     344 ModelState

I'm going to go through and drop references so that these can get garbage collected, but making Mock less memory-intensive would probably be appreciated by its users.

Reducing the memory usage of the tiny MagicProxies would be good, but also if there is a way to reduce the number of them by not pre-assiging 72 of them for every MagicMock, when each is very unlikely to be used, then that would be good as well.

Thanks,

James

----------
components: Library (Lib)
messages: 226017
nosy: james-w
priority: normal
severity: normal
status: open
title: mock could be less memory-intensive
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 28 13:43:01 2014
From: report at bugs.python.org (Edward O)
Date: Thu, 28 Aug 2014 11:43:01 +0000
Subject: [New-bugs-announce] [issue22294] 2to3 consuming_calls:  len, min,
	max, zip, map, reduce, filter, dict, xrange
Message-ID: <1409226181.07.0.476582309368.issue22294@psf.upfronthosting.co.za>


New submission from Edward O:

This is a patch for issues similar to #16573
With this patch, the following new tests are now unchanged:

r = dict(zip(s, range(len(s))), **d)
r = len(filter(attrgetter('t'), self.a))
r = min(map(methodcaller('f'), self.a))
max(map(node.id, self.nodes)) + 1 if self.nodes else 0
reduce(set.union, map(f, self.a))

Note that as part of the patch, the range transformation now calls the generic in_special_context in addition to the customized one (which. I guess, should be removed, but I didn't dare).

All existing tests pass, but the patterns used may not be strict enough, though I tried to stick to how it was done for other consuming calls.

M Lib/lib2to3/fixer_util.py
M Lib/lib2to3/fixes/fix_xrange.py
M Lib/lib2to3/tests/test_fixers.py

----------
components: 2to3 (2.x to 3.x conversion tool)
files: 2to3_more_consuming_calls.diff
hgrepos: 271
keywords: patch
messages: 226019
nosy: eddygeek
priority: normal
severity: normal
status: open
title: 2to3 consuming_calls:  len, min, max, zip, map, reduce, filter, dict, xrange
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36495/2to3_more_consuming_calls.diff

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

From report at bugs.python.org  Thu Aug 28 22:49:05 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Aug 2014 20:49:05 +0000
Subject: [New-bugs-announce] [issue22295] Clarify available commands for
	package installation
Message-ID: <1409258945.79.0.640887405807.issue22295@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

https://docs.python.org/3/installing/index.html is too subtle in pointing out the command in a source build or system Python on POSIX is "pip3" or "pip3.4" rather than the unadorned "pip".

At least one example should show pip3, and it's likely worth having an explanation in the last section on building from source.

----------
assignee: ncoghlan
components: Devguide, Documentation
messages: 226042
nosy: ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: Clarify available commands for package installation
type: enhancement

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

From report at bugs.python.org  Fri Aug 29 12:00:50 2014
From: report at bugs.python.org (Rebecka)
Date: Fri, 29 Aug 2014 10:00:50 +0000
Subject: [New-bugs-announce] [issue22296] cookielib uses time.time(),
	making incorrect checks of expiration times in cookies
Message-ID: <1409306450.24.0.723741077293.issue22296@psf.upfronthosting.co.za>


New submission from Rebecka:

The cookielib module uses time.time(), which produces a timestamp in the local timezone (as read from the system time?), as the timestamp against which expiration dates in cookies are compared.

However, typical usage of HTTP cookies would be specifying the expiration date in UTC. This assumption seems to be supported for example by the inclusion of cookielib.http2time, which (only) supports UTC timestamps.

This behaviour is also included in e.g. MozillaCookieJar, which (erroneously) excludes cookies from being saved/loaded based on the local timestamp from time.time().

See the attached file for a small example where the check if a cookie is expired against a UTC time is correct but the check against local time fails (simulating the behaviour of the cookielib module).

----------
components: Library (Lib)
files: cookie_timestamp_test.py
messages: 226056
nosy: regu0004
priority: normal
severity: normal
status: open
title: cookielib uses time.time(), making incorrect checks of expiration times in cookies
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36502/cookie_timestamp_test.py

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

From report at bugs.python.org  Fri Aug 29 13:00:34 2014
From: report at bugs.python.org (Edward O)
Date: Fri, 29 Aug 2014 11:00:34 +0000
Subject: [New-bugs-announce] [issue22297] json encoding broken for
Message-ID: <1409310034.91.0.63329091583.issue22297@psf.upfronthosting.co.za>


New submission from Edward O:

_make_iterencode in python2.7/json/encoder.py encodes custom enum types incorrectly (the label will be printed without '"') because of these lines (line 320 in 2.7.6):
    elif isinstance(value, (int, long)):
        yield buf + str(value)

in constract, _make_iterencode in python 3 explicitly supports the enum types:

    elif isinstance(value, int):
        # Subclasses of int/float may override __str__, but we still
        # want to encode them as integers/floats in JSON. One example
        # within the standard library is IntEnum.
        yield buf + str(int(value))

----------
components: Library (Lib)
messages: 226057
nosy: eddygeek
priority: normal
severity: normal
status: open
title: json encoding broken for
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 29 14:29:03 2014
From: report at bugs.python.org (Julius Lehmann-Richter)
Date: Fri, 29 Aug 2014 12:29:03 +0000
Subject: [New-bugs-announce] [issue22298] Lib/warnings.py _show_warning does
	not protect against	being called with a file like object
	which is closed
Message-ID: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za>


New submission from Julius Lehmann-Richter:

In Lib/warnings.py the _show_warning function catches IOError with the commented intention to ward against an "invalid file":

def _show_warning(message, category, filename, lineno, file=None, line=None):
    """Hook to write a warning to a file; replace if you like."""
    if file is None:
        file = sys.stderr
    try:
        file.write(formatwarning(message, category, filename, lineno, line))
    except IOError:
        pass # the file (probably stderr) is invalid - this warning gets lost.

If for some reason the file like object, and in the default case stderr, is closed, a calling program is faced with a ValueError, which is not being caught.

It seems to me, and correct me if I am wrong, that a file object which has been closed is a case of an "invalid file" and that the warning subsystem should in that case behave in the same manner as in the case of the IOError.

This behavior is the same for python 3.2 with the function renamed to showwarning and can be reproduced with for example

from sys import stderr                      
from warnings import warn
                     
stderr.close()
try:
    warn("foo")
except ValueError as e:
    print(e)

----------
components: Library (Lib)
messages: 226058
nosy: Julius.Lehmann-Richter
priority: normal
severity: normal
status: open
title: Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Aug 29 15:17:08 2014
From: report at bugs.python.org (Kevin Norris)
Date: Fri, 29 Aug 2014 13:17:08 +0000
Subject: [New-bugs-announce] [issue22299] resolve() on Windows makes some
	pathological paths	unusable
Message-ID: <1409318228.27.0.489471733533.issue22299@psf.upfronthosting.co.za>


New submission from Kevin Norris:

Run Python as an administrator:

    >>> import pathlib 
    >>> pth = pathlib.Path('//?/C:/foo.')
    >>> pth.mkdir()
    >>> pth.resolve().rmdir()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "C:\Python34\lib\pathlib.py", line 1141, in rmdir
        self._accessor.rmdir(self)
      File "C:\Python34\lib\pathlib.py", line 323, in wrapped
        return strfunc(str(pathobj), *args)
    FileNotFoundError: [WinError 2] The system cannot find the file specified: 'C:\\foo.'
    >>> pth.rmdir()

You do not need to be an administrator so long as you can create a directory in the requested location, but the \\?\ prefix only works with absolute paths so it's easier to demonstrate in the root of the drive.

----------
components: Library (Lib), Windows
messages: 226060
nosy: Kevin.Norris
priority: normal
severity: normal
status: open
title: resolve() on Windows makes some pathological paths unusable
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 29 16:08:29 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Aug 2014 14:08:29 +0000
Subject: [New-bugs-announce] [issue22300] PEP 446 What's New Updates for
	2.7.9
Message-ID: <1409321309.08.0.340268748311.issue22300@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The Python 2.7 What's New now has a section recording the feature updates in maintenance releases.

Because of the live docs updates, these need to be added on the day of the release, rather than being able to be done in advance.

----------
assignee: benjamin.peterson
files: pep466_whats_new_py279.diff
keywords: patch
messages: 226063
nosy: benjamin.peterson, ncoghlan
priority: release blocker
severity: normal
stage: commit review
status: open
title: PEP 446 What's New Updates for 2.7.9
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file36503/pep466_whats_new_py279.diff

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

From report at bugs.python.org  Fri Aug 29 22:33:03 2014
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 29 Aug 2014 20:33:03 +0000
Subject: [New-bugs-announce] [issue22301] smtplib.SMTP.starttls'
	documentation is just confusing
Message-ID: <1409344383.54.0.340854314506.issue22301@psf.upfronthosting.co.za>


New submission from Michele Orr?:

<maker> hello! In <https://docs.python.org/2/library/smtplib.html#smtplib.SMTP.starttls> I read::
<maker> "If keyfile and certfile are provided, these are passed to the socket module?s ssl() function."
<maker> socket.ssl() exists, though it is not documented (not even in /dev/library/socket)
<maker> and furthermore, the link on ssl() points to the ssl module, which is just confusing.
<bitdancer> maker: open an issue.

(I'm noising ap and chris because afaik they were working on the latest ssl security stuff)

----------
assignee: docs at python
components: Documentation, Library (Lib), email
messages: 226074
nosy: barry, christian.heimes, docs at python, maker, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: smtplib.SMTP.starttls' documentation is just confusing
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/issue22301>
_______________________________________

From report at bugs.python.org  Fri Aug 29 23:58:22 2014
From: report at bugs.python.org (Akima)
Date: Fri, 29 Aug 2014 21:58:22 +0000
Subject: [New-bugs-announce] [issue22302] Windows os.path.isabs UNC path bug
Message-ID: <1409349502.55.0.177656049078.issue22302@psf.upfronthosting.co.za>


New submission from Akima:

A UNC path pointing to the root of a share is not being recognised as an absolute path when it should be.

See this interpreter session.

PythonWin 3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information.
>>> import os.path
>>> os.path.isabs(r"\\server")
True
>>> os.path.isabs(r"\\server\share")
False
>>> os.path.isabs(r"\\server\share\folder")
True
>>> os.path.isabs(r"\\server\share\folder\folder")
True
>>>

----------
components: Library (Lib), Windows
messages: 226091
nosy: akima
priority: normal
severity: normal
status: open
title: Windows os.path.isabs UNC path bug
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug 30 00:24:14 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2014 22:24:14 +0000
Subject: [New-bugs-announce] [issue22303] Write better test for
	SSLContext.load_verify_locations
Message-ID: <1409351054.72.0.141449217965.issue22303@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

SSLContext.load_verify_locations() probably takes into account the SSL_CERT_FILE and SSL_CERT_DIR environment variables, when set. This should allow us to write a better test than the existing, minimal one.

----------
components: Tests
messages: 226092
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: Write better test for SSLContext.load_verify_locations
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug 30 01:25:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2014 23:25:38 +0000
Subject: [New-bugs-announce] [issue22304] Update multiprocessing examples to
	Py3 and test
Message-ID: <1409354738.95.0.628176067564.issue22304@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/2/library/multiprocessing.html#examples
contains several examples in Python2 code that need to be updated for Python 3. Richard, if you have them in .py files, perhaps you could run them through 2to3 and then test.

# Example where a pool of http servers share a single listening socket
from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
...
    print 'Serving at http://%s:%d using %d worker processes' % \
          (ADDRESS[0], ADDRESS[1], NUMBER_OF_PROCESSES)
    print 'To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32']

#update
from http.server import HTTPServer, SimpleHTTPRequestHandler
...
    print('Serving at http://%s:%d using %d worker processes' % \
          (ADDRESS[0], ADDRESS[1], NUMBER_OF_PROCESSES))
    print('To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32'])


This still does not run on Windows 
_pickle.PicklingError: Can't pickle <class '_thread.lock'>: attribute lookup lock on _thread failed
but that was true in 2.7 also (#21204).

----------
assignee: docs at python
components: Documentation
messages: 226103
nosy: docs at python, sbt, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update multiprocessing examples to Py3 and test
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug 30 09:41:40 2014
From: report at bugs.python.org (Shailesh Hegde)
Date: Sat, 30 Aug 2014 07:41:40 +0000
Subject: [New-bugs-announce] [issue22305] Documentation on deepcopy's
	problems is misleading
Message-ID: <1409384500.34.0.359700008646.issue22305@psf.upfronthosting.co.za>


New submission from Shailesh Hegde:

https://docs.python.org/<version>/library/copy.html

"Two problems often exist with deep copy operations that don?t exist with shallow copy operations:

Recursive objects (compound objects that, directly or indirectly, contain a reference to themselves) may cause a recursive loop.
Because deep copy copies everything it may copy too much, e.g., administrative data structures that should be shared even between copies."

I believe the last line in above paragraph is missing a 'not' ahead of 'be shared'. 

It should read:
"administrative data structures that should be not shared even between copies"

----------
assignee: docs at python
components: Documentation
messages: 226123
nosy: docs at python, shlsh
priority: normal
severity: normal
status: open
title: Documentation on deepcopy's problems is misleading
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/issue22305>
_______________________________________

From report at bugs.python.org  Sat Aug 30 09:58:55 2014
From: report at bugs.python.org (Akima)
Date: Sat, 30 Aug 2014 07:58:55 +0000
Subject: [New-bugs-announce] [issue22306] Inconsistent division by 0
	behaviour in decimal module
Message-ID: <1409385535.02.0.413020952628.issue22306@psf.upfronthosting.co.za>


New submission from Akima:

1 / 0 (where both numbers are decimal.Decimal) produces a decimal.DivisionByZero exception as I would expect.  This is useful.  I can use a simple try except block to catch a potential division by zero error in my code.

0 / 0 (where both numbers are decimal.Decimal) produces a decimal.InvalidOperation exception.  This is undesirable.  I would expect another decimal.DivisionByZero exception.  This means that if I want to catch a division by zero error in my code using a try except block, I now have to catch exceptions for both decimal.DivisionByZero and decimal.InvalidOperation.  Presumably decimal.InvalidOperation can be raised in other scenarios, so catching it may result in masking a programming fault (which isn't just a division by zero: 0 / 0).

If you perform the same division but using standard Python integers instead of decimal.Decimal objects, the behaviour is exactly as you would expect: 0 / 0 and 1 / 0 both produce a ZeroDivisionError exception.

I have tested this in CPython 3.3.5, 3.2.3 and 2.7.3.  All versions produce the same behaviour.


Demonstration:


Python 2.7.3 (default, Feb 27 2014, 19:58:35) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal as d
>>> d(1) / d(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 1323, in __truediv__
    return context._raise_error(DivisionByZero, 'x / 0', sign)
  File "/usr/lib/python2.7/decimal.py", line 3866, in _raise_error
    raise error(explanation)
decimal.DivisionByZero: x / 0
>>> d(0) / d(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 1322, in __truediv__
    return context._raise_error(DivisionUndefined, '0 / 0')
  File "/usr/lib/python2.7/decimal.py", line 3866, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: 0 / 0
>>> 1 / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero
>>> 0 / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero
>>>


Here is the same demonstration but using a Python 3.2.3 interpreter:


Python 3.2.3 (default, Feb 27 2014, 21:31:18) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal as d
>>> d(1) / d(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/decimal.py", line 1300, in __truediv__
    return context._raise_error(DivisionByZero, 'x / 0', sign)
  File "/usr/lib/python3.2/decimal.py", line 3926, in _raise_error
    raise error(explanation)
decimal.DivisionByZero: x / 0
>>> d(0) / d(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/decimal.py", line 1299, in __truediv__
    return context._raise_error(DivisionUndefined, '0 / 0')
  File "/usr/lib/python3.2/decimal.py", line 3926, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: 0 / 0
>>> 1 / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
>>> 0 / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
>>>

----------
messages: 226125
nosy: akima
priority: normal
severity: normal
status: open
title: Inconsistent division by 0 behaviour in decimal module
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 30 14:23:21 2014
From: report at bugs.python.org (Carlo)
Date: Sat, 30 Aug 2014 12:23:21 +0000
Subject: [New-bugs-announce] [issue22307] os.getlogin() documentation has
	misleading side note
Message-ID: <1409401401.25.0.41962745955.issue22307@psf.upfronthosting.co.za>


New submission from Carlo:

The documentation for os.getlogin() says:

... ``pwd.getpwuid(os.getuid())[0]`` to get the login name of the currently effective user id

Either, os.getuid() should be changed to os.geteuid(), or the wording should be changed.

----------
assignee: docs at python
components: Documentation
messages: 226139
nosy: Carlo, docs at python
priority: normal
severity: normal
status: open
title: os.getlogin() documentation has misleading side note
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug 30 20:49:36 2014
From: report at bugs.python.org (mattip)
Date: Sat, 30 Aug 2014 18:49:36 +0000
Subject: [New-bugs-announce] [issue22308] add {implementation} to
	sysconfig.py
Message-ID: <1409424576.55.0.363891426892.issue22308@psf.upfronthosting.co.za>


New submission from mattip:

An issue was reported on PyPy where a user had a ~/.local/lib/python2.7/site-packages directory that contained cpython specific libraries. We trakced it down to posix_user in sysconfig.py being set to an implementation-specific cpython path, but used by pypy.
This patch  against HEAD adds {implementation} and {implementation_lower} fields to _CONFIG_VARS, making sysconfig.py compatable with other python implementations. Perhaps valuable to jython as well, which would require modifying _get_implementation() accordingly

----------
components: Library (Lib)
files: sysconfig_head.patch
keywords: patch
messages: 226143
nosy: mattip
priority: normal
severity: normal
status: open
title: add {implementation} to sysconfig.py
type: behavior
Added file: http://bugs.python.org/file36507/sysconfig_head.patch

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

From report at bugs.python.org  Sat Aug 30 23:10:37 2014
From: report at bugs.python.org (John Malmberg)
Date: Sat, 30 Aug 2014 21:10:37 +0000
Subject: [New-bugs-announce] [issue22309] distutils/spawn.py handle fork()
	not implemented.
Message-ID: <1409433037.52.0.225577593966.issue22309@psf.upfronthosting.co.za>


New submission from John Malmberg:

Distutils currently can not handle a Posix platform that does not implement fork().

This patch retries with the _spawn_nt to use the spawn() methods if fork() is not implemented.

A platform that does not implement fork() can provide spawn*() methods for python to use.

----------
components: Distutils
files: lib_distutils_spawn_py.gdiff
messages: 226151
nosy: John.Malmberg, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils/spawn.py handle fork() not implemented.
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36510/lib_distutils_spawn_py.gdiff

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

From report at bugs.python.org  Sun Aug 31 01:31:56 2014
From: report at bugs.python.org (John Malmberg)
Date: Sat, 30 Aug 2014 23:31:56 +0000
Subject: [New-bugs-announce] [issue22310] Report actual EOF character
	instead of assuming Ctrl-D
Message-ID: <1409441516.6.0.467448307421.issue22310@psf.upfronthosting.co.za>


New submission from John Malmberg:

Have setquit() use the actual EOF character where available instead of assuming Ctrl-D.

----------
components: Library (Lib)
files: lib_site_py.gdiff
messages: 226154
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: Report actual EOF character instead of assuming Ctrl-D
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36511/lib_site_py.gdiff

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

From report at bugs.python.org  Sun Aug 31 11:34:41 2014
From: report at bugs.python.org (Wilberto Morales)
Date: Sun, 31 Aug 2014 09:34:41 +0000
Subject: [New-bugs-announce] [issue22311] Pip 404's
Message-ID: <1409477681.69.0.43132778549.issue22311@psf.upfronthosting.co.za>


New submission from Wilberto Morales:

I know that issues like this one are usually on the users(my) fault, but I think pip might be broken this time for real.

Every time I run pip install, a 404 error is raised:

(venv) /tmp wil
>>> pip install flask
Requirement already satisfied (use --upgrade to upgrade): flask in /home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/Flask-0.11_dev-py3.5.egg
Downloading/unpacking Werkzeug>=0.7 (from flask)
  HTTP error 404 while getting https://pypi.python.org/simple/packages/source/W/Werkzeug/Werkzeug-0.9.6.tar.gz#md5=f7afcadc03b0f2267bdc156c34586043 (from https://pypi.python.org/simple/werkzeug/)
Cleaning up...
Exception:
Traceback (most recent call last):
  File "/home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/pip/basecommand.py", line 122, in main
    status = self.run(options, args)
  File "/home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/pip/commands/install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/pip/req.py", line 1197, in prepare_files
    do_download,
  File "/home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/pip/req.py", line 1375, in unpack_url
    self.session,
  File "/home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/pip/download.py", line 547, in unpack_http_url
    resp.raise_for_status()
  File "/home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/pip/_vendor/requests/models.py", line 795, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
pip._vendor.requests.exceptions.HTTPError: 404 Client Error: Not Found

/home/wil/Programming/open/skinner/venv/lib/python3.5/site-packages/pip/basecommand.py:158: ResourceWarning: unclosed <ssl.SSLSocket fd=4, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('10.0.0.6', 52061), raddr=('23.235.44.175', 443)>
  exit = UNKNOWN_ERROR
Storing debug log for failure in /home/wil/.pip/pip.log

With flask-sqlalchemy as a example.

Right: 

https://pypi.python.org/packages/source/F/Flask-SQLAlchemy/Flask-SQLAlchemy-2.0.tar.gz#md5=06ae73194cca73b72e178f870d1dac7c

PIP(wrong):

https://pypi.python.org/simple/packages/source/F/Flask-SQLAlchemy/Flask-SQLAlchemy-2.0.tar.gz/#md5=06ae73194cca73b72e178f870d1dac7c

Notice the simple added after to .org and the / added after .tar.gz

----------
messages: 226160
nosy: wilbertom
priority: normal
severity: normal
status: open
title: Pip 404's
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug 31 12:14:02 2014
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 31 Aug 2014 10:14:02 +0000
Subject: [New-bugs-announce] [issue22312] ntpath.splitdrive('//') ->
	IndexError
Message-ID: <1409480042.02.0.343701300386.issue22312@psf.upfronthosting.co.za>


New submission from Armin Rigo:

Calling Python 2.7's new version of ntpath.splitdrive() with argument either '//' or r'\\' results in an IndexError: string index out of range.

----------
messages: 226163
nosy: arigo
priority: normal
severity: normal
status: open
title: ntpath.splitdrive('//') -> IndexError
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 31 12:22:00 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 31 Aug 2014 10:22:00 +0000
Subject: [New-bugs-announce] [issue22313] Make PYLONG_BITS_IN_DIGIT always
	available to non-core	extensions
Message-ID: <1409480520.8.0.291215275837.issue22313@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

"longintrepr.h" is a non-public header file (not included by Python.h) that defines the inner struct layout of PyLong objects. Including it allows for very fast access to "small" integers through ob_digit[0] when -1 <= Py_SIZE(n) <= 1, which is a great feature.

However, the header file depends on PYLONG_BITS_IN_DIGIT being defined and matching exactly the value that was used when building CPython. In the case that --enable-big-digits=X was passed to configure, this value is available from pyconfig.h. Otherwise, it will be determined by pyport.h, where it depends on the current configuration of the C compiler and may in some cases come up with a different definition than it did when building CPython (which then leads to crashes).

I'd like to have the correct build-time value always available in one way or another, e.g. by always storing it in pyconfig.h even when it was not user configured, so that including and using longintrepr.h becomes a safe and simple thing.

----------
components: Build
messages: 226167
nosy: mark.dickinson, scoder
priority: normal
severity: normal
status: open
title: Make PYLONG_BITS_IN_DIGIT always available to non-core extensions
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug 31 15:17:07 2014
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 31 Aug 2014 13:17:07 +0000
Subject: [New-bugs-announce] [issue22314] pydoc.py: TypeError with a $LINES
	defined to anything
Message-ID: <1409491027.45.0.991041704506.issue22314@psf.upfronthosting.co.za>


New submission from Armin Rigo:

$ LINES=20 python Lib/test/test_pydoc.py

...
  File ".../Lib/pydoc.py", line 1448, in ttypager
    r = inc = os.environ.get('LINES', 25) - 1
TypeError: unsupported operand type(s) for -: 'str' and 'int'

duh.

----------
components: Library (Lib)
messages: 226177
nosy: arigo
priority: normal
severity: normal
status: open
title: pydoc.py: TypeError with a $LINES defined to anything
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 31 17:15:05 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 31 Aug 2014 15:15:05 +0000
Subject: [New-bugs-announce] [issue22315] TypeError in error handling
	in	distutils.dir_util.copy_tree
Message-ID: <1409498105.67.0.812360133901.issue22315@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

This morning, I was running an install of a package on Python 3.4.1 when I encountered this error:

C:\Users\jaraco\projects\jaraco.financial [default tip]> ./setup install
?running install
running bdist_egg
running egg_info
writing namespace_packages to jaraco.financial.egg-info\namespace_packages.txt
writing jaraco.financial.egg-info\PKG-INFO
writing top-level names to jaraco.financial.egg-info\top_level.txt
writing requirements to jaraco.financial.egg-info\requires.txt
writing dependency_links to jaraco.financial.egg-info\dependency_links.txt
writing entry points to jaraco.financial.egg-info\entry_points.txt
writing manifest file 'jaraco.financial.egg-info\SOURCES.txt'
installing library code to build\bdist.win-amd64\egg
running install_lib
running build_py
copying jaraco\financial\records.py -> build\lib\jaraco\financial
creating build\bdist.win-amd64\egg
creating build\bdist.win-amd64\egg\jaraco
creating build\bdist.win-amd64\egg\jaraco\financial
copying build\lib\jaraco\financial\ledger.py -> build\bdist.win-amd64\egg\jaraco\financial
copying build\lib\jaraco\financial\qif.py -> build\bdist.win-amd64\egg\jaraco\financial
copying build\lib\jaraco\financial\merchant.py -> build\bdist.win-amd64\egg\jaraco\financial
?Traceback (most recent call last):
  File "C:\Program Files\Python34\lib\distutils\dir_util.py", line 126, in copy_tree
    names = os.listdir(src)
OSError: [WinError 59] An unexpected network error occurred: 'build\\lib\\jaraco\\financial\\records.py'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\jaraco\projects\jaraco.financial\setup.py", line 72, in <module>
    setuptools.setup(**setup_params)
  File "C:\Program Files\Python34\lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "C:\Program Files\Python34\lib\distutils\dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "C:\Program Files\Python34\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "C:\Program Files\Python34\lib\site-packages\setuptools-5.7-py3.4.egg\setuptools\command\install.py", line 67, in run
  File "C:\Program Files\Python34\lib\site-packages\setuptools-5.7-py3.4.egg\setuptools\command\install.py", line 109, in do_egg_install
  File "C:\Program Files\Python34\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\Program Files\Python34\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "C:\Program Files\Python34\lib\site-packages\setuptools-5.7-py3.4.egg\setuptools\command\bdist_egg.py", line 161, in run
  File "C:\Program Files\Python34\lib\site-packages\setuptools-5.7-py3.4.egg\setuptools\command\bdist_egg.py", line 147, in call_command
  File "C:\Program Files\Python34\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\Program Files\Python34\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "C:\Program Files\Python34\lib\site-packages\setuptools-5.7-py3.4.egg\setuptools\command\install_lib.py", line 10, in run
  File "C:\Program Files\Python34\lib\distutils\command\install_lib.py", line 111, in install
    outfiles = self.copy_tree(self.build_dir, self.install_dir)
  File "C:\Program Files\Python34\lib\site-packages\setuptools-5.7-py3.4.egg\setuptools\command\install_lib.py", line 38, in copy_tree
  File "C:\Program Files\Python34\lib\distutils\cmd.py", line 357, in copy_tree
    not self.force, dry_run=self.dry_run)
  File "C:\Program Files\Python34\lib\distutils\dir_util.py", line 160, in copy_tree
    verbose=verbose, dry_run=dry_run))
  File "C:\Program Files\Python34\lib\distutils\dir_util.py", line 160, in copy_tree
    verbose=verbose, dry_run=dry_run))
  File "C:\Program Files\Python34\lib\distutils\dir_util.py", line 160, in copy_tree
    verbose=verbose, dry_run=dry_run))
  File "C:\Program Files\Python34\lib\distutils\dir_util.py", line 128, in copy_tree
    (errno, errstr) = e
TypeError: 'OSError' object is not iterable

The original traceback indicates a network error occurred. The secondary error occurs when the error is assumed to be an iterable of two elements. I suspect this issue arises from the conversion of WindowsError to OSError or similar.

I plan to look at this in more depth later.

----------
assignee: jason.coombs
components: Distutils
messages: 226182
nosy: dstufft, eric.araujo, jason.coombs
priority: normal
severity: normal
status: open
title: TypeError in error handling in distutils.dir_util.copy_tree
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Aug 31 18:02:43 2014
From: report at bugs.python.org (Anthony Mayer)
Date: Sun, 31 Aug 2014 16:02:43 +0000
Subject: [New-bugs-announce] [issue22316] Add rule about "extraneous
	whitespace around colon" to	"Whitespace In Expressions and
	Statements" of PEP8
Message-ID: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za>


New submission from Anthony Mayer:

After discussion about extraneous whitespace around colons in a list slice not being an error on the pep8 checker project (see https://github.com/jcrocholl/pep8/issues/321#issuecomment-53649841), ncoghlan suggested filing a ticket here to get the issue added to PEP8. The issue being that PEP8 doesn't say that

x = [1, 2, 3, 4]
x[1: 3]

is wrong. It should suggest doing

x = [1, 2, 3, 4]
x[1:3]

instead. This rule should probably be added to the "Whitespace In Expressions and Statements" section of PEP8 (http://legacy.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements)

----------
assignee: docs at python
components: Documentation
messages: 226185
nosy: Guido.van.Rossum, anthonymayer, barry, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Add rule about "extraneous whitespace around colon" to "Whitespace In Expressions and Statements" of PEP8

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

From report at bugs.python.org  Sun Aug 31 22:39:23 2014
From: report at bugs.python.org (Ubik)
Date: Sun, 31 Aug 2014 20:39:23 +0000
Subject: [New-bugs-announce] [issue22317] action argument is not documented
	in argparse	add_subparser() docs
Message-ID: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>


New submission from Ubik:

See: https://docs.python.org/2/library/argparse.html#argparse.ArgumentParser.add_subparsers

----------
assignee: docs at python
components: Documentation
messages: 226190
nosy: Ubik, docs at python
priority: normal
severity: normal
status: open
title: action argument is not documented in argparse add_subparser() docs
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 31 23:55:54 2014
From: report at bugs.python.org (Tony Flury)
Date: Sun, 31 Aug 2014 21:55:54 +0000
Subject: [New-bugs-announce] [issue22318] unitest documentation on
	assertItemsEqual misleading
Message-ID: <1409522154.37.0.82658213186.issue22318@psf.upfronthosting.co.za>


New submission from Tony Flury:

The notes on assertItemsEqual do not make it clear that the comparison works by using their hash value, and not their __eq__ implementation - i.e. it does an 'is' not an '==' between objects in the sequence.

If the sequences being compared contain user created objects which don't implement their own specific __hash__ method (and therefore inherit their __hash__ from the base object - based on the object id), then the assertion will ALWAYS be false, regardless of their __eq__ value.

This only became clear when trying to use unitest, getting strange results, and I eventually read the code.

----------
assignee: docs at python
components: Documentation
messages: 226193
nosy: TonyFlury, docs at python
priority: normal
severity: normal
status: open
title: unitest documentation on assertItemsEqual misleading
type: behavior
versions: Python 2.7

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