From report at bugs.python.org  Sat Nov  1 00:11:11 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Oct 2014 23:11:11 +0000
Subject: [New-bugs-announce] [issue22780] NotImplemented doc section needs
	update
Message-ID: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>


New submission from Ethan Furman:

https://docs.python.org/3/library/constants.html

current
-------
    Special value which can be returned by the ?rich comparison? special methods (__eq__(), __lt__(), and friends), to indicate that the comparison is not implemented with respect to the other type.


more accurate
-------------
    Special value which should be returned by the __dunder__ methods to indicate the requested operation is not implemented with respect to the other type.

----------
messages: 230412
nosy: eric.araujo, ethan.furman, ezio.melotti, georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: NotImplemented doc section needs update

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

From report at bugs.python.org  Sat Nov  1 18:16:25 2014
From: report at bugs.python.org (Geoff Clements)
Date: Sat, 01 Nov 2014 17:16:25 +0000
Subject: [New-bugs-announce] [issue22781] ctypes: Differing results between
	Python and C.
Message-ID: <1414862185.49.0.654024451078.issue22781@psf.upfronthosting.co.za>


New submission from Geoff Clements:

I have used ctypes to create a binding to libdvdread but I am getting some bad values back from libdvdread when using python. I have used ctypeslib to generate the python bindings, i.e. h2xml and xml2py and, as far as I can tell, the bind is a faithful representation of the h files.

In order to demonstrate this I have created a small C program and a small Python3 program both doing the same thing. When run they should produce the same output but they do not. In order to run these you need a DVD inserted in a DVD drive, I've hard-coded the device path to the DVD drive as /dev/sr0 in both programs so this may need to be changed.

----------
components: ctypes
files: dvdtest.tar.gz
messages: 230453
nosy: Geoff.Clements
priority: normal
severity: normal
status: open
title: ctypes: Differing results between Python and C.
versions: Python 3.4
Added file: http://bugs.python.org/file37101/dvdtest.tar.gz

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

From report at bugs.python.org  Sat Nov  1 19:09:38 2014
From: report at bugs.python.org (Paul Moore)
Date: Sat, 01 Nov 2014 18:09:38 +0000
Subject: [New-bugs-announce] [issue22782] Python 3.4.2 Windows installer -
	cannot install 32 bit	then 64 bit version
Message-ID: <1414865378.95.0.654751043147.issue22782@psf.upfronthosting.co.za>


New submission from Paul Moore:

When you install Python 3.4.2 32 bit and 64 bit on the same PC, in that order, the second one you install shows a red error message on the install screen, saying "This update will replace your existing Python 3.4 installation", and proceeds to uninstall the 32-bit version before installing. This is even though the two are being installed into different directories.

This does not happen if the 64 bit install is done first (which is a huge relief, as otherwise it's not possible to install the 2 versions side by side).

----------
assignee: steve.dower
components: Windows
messages: 230455
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.4.2 Windows installer - cannot install 32 bit then 64 bit version
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov  2 16:28:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:28:42 +0000
Subject: [New-bugs-announce] [issue22783] Pickle: use NEWOBJ instead of
	NEWOBJ_EX if possible
Message-ID: <1414942122.91.0.879577274082.issue22783@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently in pickle with protocol 4 the NEWOBJ_EX opcode is used to reconstruct objects with __getnewargs__() or __getnewargs_ex__() even if there no keyword arguments.

>>> import pickle, pickletools, collections
>>> P = collections.namedtuple('P', 'x y')
>>> pickletools.dis(pickle.dumps(P(12, 34), 3))
    0: \x80 PROTO      3
    2: c    GLOBAL     '__main__ P'
   14: q    BINPUT     0
   16: K    BININT1    12
   18: K    BININT1    34
   20: \x86 TUPLE2
   21: q    BINPUT     1
   23: \x81 NEWOBJ
   24: q    BINPUT     2
   26: .    STOP
highest protocol among opcodes = 2
>>> pickletools.dis(pickle.dumps(P(12, 34), 4))
    0: \x80 PROTO      4
    2: \x95 FRAME      28
   11: \x8c SHORT_BINUNICODE '__main__'
   21: \x94 MEMOIZE
   22: \x8c SHORT_BINUNICODE 'P'
   25: \x94 MEMOIZE
   26: \x93 STACK_GLOBAL
   27: \x94 MEMOIZE
   28: K    BININT1    12
   30: K    BININT1    34
   32: \x86 TUPLE2
   33: \x94 MEMOIZE
   34: }    EMPTY_DICT
   35: \x94 MEMOIZE
   36: \x92 NEWOBJ_EX
   37: \x94 MEMOIZE
   38: .    STOP
highest protocol among opcodes = 4

These EMPTY_DICT//MEMOIZE//NEWOBJ_EX can be replaced by single NEWOBJ. Actually there is a regression in protocol 4 against protocol 3, so may be following patch should be applied on 3.4 too.

Here is a patch which uses __newobj__ instead of __newobj_ex__ if there are no keywords arguments. Also it reduce the number of lines of C code and adds tests for classes with __getnewargs__() and __getnewargs_ex__().

----------
components: Library (Lib)
files: pickle_newobj.patch
keywords: patch
messages: 230490
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pickle: use NEWOBJ instead of NEWOBJ_EX if possible
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37107/pickle_newobj.patch

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

From report at bugs.python.org  Sun Nov  2 17:20:57 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 16:20:57 +0000
Subject: [New-bugs-announce] [issue22784] test_asyncio fails without the ssl
	module
Message-ID: <1414945257.4.0.921150586656.issue22784@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Patch attached. I don't know whether this applies to 3.4 as well.

----------
components: Tests, asyncio
files: ssl_test_asyncio.patch
keywords: patch
messages: 230502
nosy: gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: test_asyncio fails without the ssl module
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file37109/ssl_test_asyncio.patch

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

From report at bugs.python.org  Sun Nov  2 22:07:03 2014
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 02 Nov 2014 21:07:03 +0000
Subject: [New-bugs-announce] [issue22785] range docstring is less useful
	than in python 2
Message-ID: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The Python 3.4 docstring for range is:
{{{
 |  range(stop) -> range object
 |  range(start, stop[, step]) -> range object
 |
 |  Return a virtual sequence of numbers from start to stop by step.
}}}

In Python 2.7, it said:
{{{
    range(stop) -> list of integers
    range(start, stop[, step]) -> list of integers

    Return a list containing an arithmetic progression of integers.
    range(i, j) returns [i, i+1, i+2, ..., j-1]; start (!) defaults to 0.
    When step is given, it specifies the increment (or decrement).
    For example, range(4) returns [0, 1, 2, 3].  The end point is omitted!
    These are exactly the valid indices for a list of 4 elements.
}}}

Note that Python 3 seems to imply that the end-point is included, while Python 2 made clear that it was not.  "Arithmetic progression" is a bit involved, but it would be good to mention that the end-point is omitted in the Python 3 docstring.

----------
assignee: docs at python
components: Documentation
messages: 230525
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: range docstring is less useful than in python 2
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov  3 16:09:21 2014
From: report at bugs.python.org (Till Maas)
Date: Mon, 03 Nov 2014 15:09:21 +0000
Subject: [New-bugs-announce] [issue22787] ssl.SSLContext.load_cert_chain()
	backport regression	with None as keyfile
Message-ID: <1415027361.25.0.159833627415.issue22787@psf.upfronthosting.co.za>


New submission from Till Maas:

https://github.com/python/cpython/commit/71a4ee3ea2c6847b9fc4b33cbc8d565a7bf2424a

introduces a regression in ssl.SSLContext.load_cert_chain()

https://github.com/python/cpython/blob/2.7/Modules/_ssl.c#L2462

With this change it is not possible to specify None as keyfile which can 
be triggered on Debian Testing? (there the change is backported) in requests.get("https://example.com", cerf="keycert.pem"). It can also be triggered with the sample code in the attached file. It is fixed in recent python 3.

----------
components: Library (Lib)
files: poc.txt
messages: 230539
nosy: till
priority: normal
severity: normal
status: open
title: ssl.SSLContext.load_cert_chain() backport regression with None as keyfile
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37120/poc.txt

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

From report at bugs.python.org  Mon Nov  3 19:49:27 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 18:49:27 +0000
Subject: [New-bugs-announce] [issue22788] allow HTTPHandler to take an
	SSLContext
Message-ID: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

It would be nice if HTTPHandler could take an SSLContext as a parameter, which would be passed to HTTPSConnection to configure the security of the connection.

----------
components: Library (Lib)
messages: 230549
nosy: benjamin.peterson, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: allow HTTPHandler to take an SSLContext
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  4 06:00:45 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 05:00:45 +0000
Subject: [New-bugs-announce] [issue22789] Compress the marshalled data in
	PYC files
Message-ID: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Save space and reduce I/O time (reading and writing) by compressing the marshaled code in  files.

In my code tree for Python 3, there was a nice space savings 19M to 7M.  Here's some of the output from my test:

    8792 ->     4629 ./Tools/scripts/__pycache__/reindent.cpython-35.pyc
    1660 ->     1063 ./Tools/scripts/__pycache__/rgrep.cpython-35.pyc
    1995 ->     1129 ./Tools/scripts/__pycache__/run_tests.cpython-35.pyc
    1439 ->      973 ./Tools/scripts/__pycache__/serve.cpython-35.pyc
     727 ->      498 ./Tools/scripts/__pycache__/suff.cpython-35.pyc
    3240 ->     1808 ./Tools/scripts/__pycache__/svneol.cpython-35.pyc
   74866 ->    23611 ./Tools/scripts/__pycache__/texi2html.cpython-35.pyc
    5562 ->     2870 ./Tools/scripts/__pycache__/treesync.cpython-35.pyc
    1492 ->      970 ./Tools/scripts/__pycache__/untabify.cpython-35.pyc
    1414 ->      891 ./Tools/scripts/__pycache__/which.cpython-35.pyc
19627963 ->  6976410 Total

I haven't measured it yet, but I believe this will improve Python's start-up time (because fewer bytes get transferred from disk).

----------
files: compress_pyc.py
messages: 230576
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Compress the marshalled data in PYC files
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37125/compress_pyc.py

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

From report at bugs.python.org  Tue Nov  4 09:44:04 2014
From: report at bugs.python.org (Sam Bishop)
Date: Tue, 04 Nov 2014 08:44:04 +0000
Subject: [New-bugs-announce] [issue22790] __qualname__ missing from
	dir(__class__) during class	initialisation
Message-ID: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>


New submission from Sam Bishop:

The output of performing "dir(__class__)" during a class' __init__ method, seems to be lacking the new '__qualname__' attribute in python 3.

This rough test can be pasted right into the python 3.4 REPL to see the issue.
Tested on 64bit python 3.4 running on OSX 10.9
 
"
class Foo:
    class Bar(object):
        keywords = dict()
        def __init__(self, **kwargs):
            print(dir(__class__))
            print(''.join(('"str(__class__.__qualname__)" = ', str(__class__.__qualname__))))
            print(''.join((
                'Is "__qualname__" in the output of the dir() function? : ',
                str(('__qualname__' in dir(__class__))))))
            self.keywords = kwargs


test = Foo.Bar(see='We are missing something here')


"

----------
components: Interpreter Core
messages: 230591
nosy: techdragon
priority: normal
severity: normal
status: open
title: __qualname__ missing from dir(__class__) during class initialisation
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov  4 09:44:40 2014
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 04 Nov 2014 08:44:40 +0000
Subject: [New-bugs-announce] [issue22791] datetime.utcfromtimestamp() shoud
	have option for create	tz aware datetime
Message-ID: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>


New submission from INADA Naoki:

In [1]: import datetime

In [2]: datetime.datetime.utcfromtimestamp(0)
Out[2]: datetime.datetime(1970, 1, 1, 0, 0)

In [3]: datetime.datetime.utcfromtimestamp(0).replace(tzinfo=datetime.timezone.utc)
Out[3]: datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)

datetime.utcfromtimestamp() returns naive datetime.
But some methods assumes naive datetime is localtime. (e.g. datetime.timestamp()).
This is big pitfall for many Pythonistas.

We can't change default behavior for backward compatibility.
How about adding `aware` keyword-only option?

>>> datetime.datetime.utcfromtimestamp(0, aware=True)
datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)

----------
components: Library (Lib)
messages: 230592
nosy: naoki
priority: normal
severity: normal
status: open
title: datetime.utcfromtimestamp() shoud have option for create tz aware datetime
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  4 10:50:41 2014
From: report at bugs.python.org (housetier)
Date: Tue, 04 Nov 2014 09:50:41 +0000
Subject: [New-bugs-announce] [issue22792] string replace() not documented
Message-ID: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>


New submission from housetier:

https://docs.python.org/3.4/library/string.html does not explain the replace() function. I suppose it is very similar, if not identical, to 2.7: https://docs.python.org/2.7/library/string.html#string.replace

----------
components: Distutils
messages: 230601
nosy: dstufft, eric.araujo, housetier
priority: normal
severity: normal
status: open
title: string replace() not documented
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov  4 15:21:43 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 14:21:43 +0000
Subject: [New-bugs-announce] [issue22793] test_uuid failure on OpenIndiana
Message-ID: <1415110903.37.0.741513995713.issue22793@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8840/steps/test/logs/stdio

testIssue8621 (test.test_uuid.TestUUID) ... ok
test_UUID (test.test_uuid.TestUUID) ... ok
test_exceptions (test.test_uuid.TestUUID) ... ok
test_find_mac (test.test_uuid.TestUUID) ... ok
test_getnode (test.test_uuid.TestUUID) ... ok
test_ifconfig_getnode (test.test_uuid.TestUUID) ... ERROR
test_ipconfig_getnode (test.test_uuid.TestUUID) ... skipped 'requires Windows'
test_netbios_getnode (test.test_uuid.TestUUID) ... skipped 'requires win32wnet'
test_random_getnode (test.test_uuid.TestUUID) ... ok
test_unixdll_getnode (test.test_uuid.TestUUID) ... skipped 'requires ctypes'
test_uuid1 (test.test_uuid.TestUUID) ... skipped 'requires ctypes'
test_uuid3 (test.test_uuid.TestUUID) ... ok
test_uuid4 (test.test_uuid.TestUUID) ... skipped 'requires ctypes'
test_uuid5 (test.test_uuid.TestUUID) ... ok
test_windll_getnode (test.test_uuid.TestUUID) ... skipped 'requires Windows'

======================================================================
ERROR: test_ifconfig_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_uuid.py", line 319, in test_ifconfig_getnode
    node = uuid._ifconfig_getnode()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/uuid.py", line 360, in _ifconfig_getnode
    mac = _find_mac('arp', '-an', [os.fsencode(ip_addr)], lambda i: -1)
NameError: name 'os' is not defined

----------------------------------------------------------------------
Ran 15 tests in 0.211s

----------
components: Library (Lib)
messages: 230626
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_uuid failure on OpenIndiana
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  4 16:03:57 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Nov 2014 15:03:57 +0000
Subject: [New-bugs-announce] [issue22794] missing test for issue 22457
	regression commit
Message-ID: <1415113437.67.0.13245212924.issue22794@psf.upfronthosting.co.za>


New submission from Robert Collins:

I did a brownbag fix for my change to issue22457 which exposed a untested corner case - this issue is for me to come back and add a regression test for it.

----------
messages: 230628
nosy: rbcollins
priority: normal
severity: normal
status: open
title: missing test for issue 22457 regression commit
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  4 16:28:27 2014
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 04 Nov 2014 15:28:27 +0000
Subject: [New-bugs-announce] [issue22795] Intermittent
Message-ID: <1415114907.55.0.414991174026.issue22795@psf.upfronthosting.co.za>


Changes by David Edelsohn <dje.gcc at gmail.com>:


----------
components: Tests
nosy: David.Edelsohn, haypo
priority: normal
severity: normal
status: open
title: Intermittent
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov  4 17:47:43 2014
From: report at bugs.python.org (Tim Graham)
Date: Tue, 04 Nov 2014 16:47:43 +0000
Subject: [New-bugs-announce] [issue22796] Support for httponly/secure
	cookies reintroduced lax	parsing behavior
Message-ID: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>


New submission from Tim Graham:

As noted in the comments of #22758 by Georg Brandle: 

* Django uses __init__(str()) roundtripping, which is not explicitly supported by the library, and worked by accident with previous versions.  That it works again with 3.3+ is another accident, and a bug.

(The change for #16611 reintroduces "lax" parsing behavior that the security fix [1] was supposed to prevent.)

[1] https://hg.python.org/cpython/rev/d3663a0f97ed

----------
components: Library (Lib)
messages: 230637
nosy: Tim.Graham, berker.peksag, georg.brandl, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Support for httponly/secure cookies reintroduced lax parsing behavior
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov  4 18:04:57 2014
From: report at bugs.python.org (Joshua Chin)
Date: Tue, 04 Nov 2014 17:04:57 +0000
Subject: [New-bugs-announce] [issue22797] urllib.request.urlopen
	documentation falsely guarantees	that a URLError will be
	raised on errors
Message-ID: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>


New submission from Joshua Chin:

The documentation for urlopen states that it "Raises URLError on errors." However, urlopen can raise a ValueError. In fact, test_urllib. urlopen_FileTests.test_relativelocalfile  specifically checks if urlopen raises a ValueError. I suggest removing the guarantee from the documentation.

----------
assignee: docs at python
components: Documentation
files: urlopen_doc.patch
keywords: patch
messages: 230640
nosy: Joshua.Chin, docs at python, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37129/urlopen_doc.patch

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

From report at bugs.python.org  Wed Nov  5 13:12:28 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 05 Nov 2014 12:12:28 +0000
Subject: [New-bugs-announce] [issue22798] time.mktime doesn't update
	time.tzname
Message-ID: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>


New submission from Akira Li:

time.tzname is initialized from C tzname variable or tm_zone around Jan, Jul of the current year.

If time.mktime() is called with a time tuple from the past/future then after the call time.tzname might be out-of-sync with the corresponding C tzname and tm_zone values. Because C mktime may change tzname, tm_zone values on some systems and time.mktime calls C mktime.

I've attached test_mktime_changes_tzname.c file that demonstrates that mktime() may change tzname.

----------
components: Library (Lib)
files: test_mktime_changes_tzname.c
messages: 230674
nosy: akira
priority: normal
severity: normal
status: open
title: time.mktime doesn't update time.tzname
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37132/test_mktime_changes_tzname.c

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

From report at bugs.python.org  Wed Nov  5 16:00:06 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 05 Nov 2014 15:00:06 +0000
Subject: [New-bugs-announce] [issue22799] wrong time.timezone
Message-ID: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za>


New submission from Akira Li:

$ TZ=:Europe/Moscow ./python -mtest -v test_time
  ======================================================================
  FAIL: test_localtime_timezone (test.test_time.TestPytime)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File ".../Lib/test/test_time.py", line 721, in test_localtime_timezone
      self.assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst])
  AssertionError: 10800 != 14400
  
  ----------------------------------------------------------------------
  Ran 45 tests in 1.832s
  
  FAILED (failures=1, skipped=3)
  test test_time failed
  1 test failed:
      test_time


UTC offset had changed on 2014-10-26 in Europe/Moscow timezone from
MSK+0400 to MSK+0300.

Python time.timezone returns -14400 (old utc offset) despite C timezone
variable having the correct value (Python uses tm_gmtoff from Jan here).

Similar case where timezone, altzone may be wrong
http://bugs.python.org/msg31138

The issue again http://bugs.python.org/issue22798 is that time timezone
attribute is out-of-sync with the corresponding C variable i.e., C
library provides correct values but time module doesn't use them.

----------
components: Library (Lib)
messages: 230684
nosy: akira
priority: normal
severity: normal
status: open
title: wrong time.timezone
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Nov  5 16:34:45 2014
From: report at bugs.python.org (Chris PeBenito)
Date: Wed, 05 Nov 2014 15:34:45 +0000
Subject: [New-bugs-announce] [issue22800] IPv6Network constructor sometimes
	does not recognize	legitimate netmask
Message-ID: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>


New submission from Chris PeBenito:

Python 3.3/3.4 sometimes does not recognize a legitimate IPv6Network netmask:

$ python3
Python 3.3.5 (default, May 28 2014, 13:56:57) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress as ip
>>> nodecon = ip.IPv6Network('ff00::/ff00::')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/ipaddress.py", line 2084, in __init__
    self._prefixlen = self._prefix_from_prefix_string(addr[1])
  File "/usr/lib64/python3.3/ipaddress.py", line 514, in _prefix_from_prefix_string
    self._report_invalid_netmask(prefixlen_str)
  File "/usr/lib64/python3.3/ipaddress.py", line 497, in _report_invalid_netmask
    raise NetmaskValueError(msg) from None
ipaddress.NetmaskValueError: 'ff00::' is not a valid netmask
>>> nodecon = ip.IPv6Network('ff00::/8')
>>> print(nodecon)
ff00::/8
>>> print(nodecon.with_netmask)
ff00::/ff00::

I get the same behavior on Python 3.4.2.

----------
components: Library (Lib)
messages: 230686
nosy: pebenito
priority: normal
severity: normal
status: open
title: IPv6Network constructor sometimes does not recognize legitimate netmask
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov  5 18:44:31 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 05 Nov 2014 17:44:31 +0000
Subject: [New-bugs-announce] [issue22801] collections.Counter, when empty,
	doesn't raise an error with &= when other is an incompatible type
Message-ID: <1415209471.77.0.966779934151.issue22801@psf.upfronthosting.co.za>


New submission from Ethan Furman:

test script:
---------------------------------------
from collections import Counter
empty_counter = Counter()
counter = Counter('abbc')
empty_counter &= 5
counter &= 5
---------------------------------------

results:
---------------------------------------
Traceback (most recent call last):
  File "blah.py", line 5, in <module>
    counter &= 5
  File "/home/ethan/source/python/issue22778/Lib/collections/__init__.py", line 780, in __iand__
    other_count = other[elem]
TypeError: 'int' object is not subscriptable
----------------------------------------

As can be seen, the error does not show up when the Counter is empty, which could lead to hard to diagnose bugs.

----------
assignee: rhettinger
files: issue22778.stoneleaf.01.patch
keywords: patch
messages: 230699
nosy: ethan.furman, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: collections.Counter, when empty, doesn't raise an error with &= when other is an incompatible type
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37136/issue22778.stoneleaf.01.patch

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

From report at bugs.python.org  Wed Nov  5 20:12:41 2014
From: report at bugs.python.org (Alex Earl)
Date: Wed, 05 Nov 2014 19:12:41 +0000
Subject: [New-bugs-announce] [issue22802] On Windows,
	if you try and use ccs=UTF-8 (or other variants) the U is removed
Message-ID: <1415214761.19.0.969078591014.issue22802@psf.upfronthosting.co.za>


New submission from Alex Earl:

As you can see below, the code in fileobject.c is removing the U from the UTF-8 (or UNICODE) when it tries to replace a U for universal line ending mode.


Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('newfile.txt', 'rt+,ccs=UNICODE')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid mode ('rbt+,ccs=NICODE')
>>> f = open('newfile.txt', 'rt+,ccs=UTF-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid mode ('rbt+,ccs=TF-8')


It looks to be an issue with the code around:

https://hg.python.org/cpython/file/ee879c0ffa11/Objects/fileobject.c#l283

----------
components: IO, Windows
messages: 230705
nosy: Alex.Earl, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: On Windows, if you try and use ccs=UTF-8 (or other variants) the U is removed
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  6 05:35:13 2014
From: report at bugs.python.org (Christopher Foo)
Date: Thu, 06 Nov 2014 04:35:13 +0000
Subject: [New-bugs-announce] [issue22803] textwrap.indent version added not
	documented
Message-ID: <1415248513.64.0.157096168022.issue22803@psf.upfronthosting.co.za>


New submission from Christopher Foo:

I was running my program under CI and it failed under 3.2:

    text = textwrap.indent(text, '* ', predicate=lambda line: True)

    AttributeError: 'module' object has no attribute 'indent'

textwrap.indent appears to be a new feature in 3.3 but Doc/library/textwrap.rst is not documented with ".. versionadded:: 3.3"

----------
assignee: docs at python
components: Documentation
messages: 230725
nosy: chfoo, docs at python
priority: normal
severity: normal
status: open
title: textwrap.indent version added not documented
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Nov  6 11:10:49 2014
From: report at bugs.python.org (nx u)
Date: Thu, 06 Nov 2014 10:10:49 +0000
Subject: [New-bugs-announce] [issue22804] Can't run Idle in Windows 8 or
	windows 64
Message-ID: <1415268649.04.0.373697042917.issue22804@psf.upfronthosting.co.za>


New submission from nx u:

Hi,

I have just downloaded and installed python34. When I run the short cut  IDLE python gui nothing happens  ( I think a command window appears briefly - not sure as this happens so quickly).  My machine runs windows 8 and 64 bit version of . I did the same on a windows 7 64 bit machine and double clicking the Python IDLE gui 32 bit doesn't work.

Not quite sure what's going on. Our machines are located in a school with GPOs controlling access and security. I am from the ICT support team. There isn't much reported on this issue on the internet either except a couple of entries in stackoverflow. But the solutions offered are far off the mark. Please help. The documentation on the Python web site is not clear or not detailed enough to diagnose the fault.

----------
components: IDLE
messages: 230732
nosy: nx.u
priority: normal
severity: normal
status: open
title: Can't run Idle in Windows 8 or windows 64
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov  6 15:48:35 2014
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Nov 2014 14:48:35 +0000
Subject: [New-bugs-announce] [issue22805] Having pythontest.net index.html
	link to hg repo
Message-ID: <1415285315.17.0.355776153146.issue22805@psf.upfronthosting.co.za>


New submission from Brett Cannon:

For pythontest.net, it would be nice if the index.html page that is (supposed to be) served linked to the hg repo to make it more discoverable how to add files to the domain.

----------
assignee: brett.cannon
messages: 230747
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Having pythontest.net index.html link to hg repo
type: enhancement

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

From report at bugs.python.org  Thu Nov  6 15:59:16 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2014 14:59:16 +0000
Subject: [New-bugs-announce] [issue22806] regrtest: add switch -c to run
	only modified tests
Message-ID: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>


New submission from Georg Brandl:

A quick way to select only tests that are modified in the checkout.

----------
components: Tests
files: regrtest_changed.diff
keywords: patch
messages: 230748
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: regrtest: add switch -c to run only modified tests
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37138/regrtest_changed.diff

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

From report at bugs.python.org  Thu Nov  6 21:07:26 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2014 20:07:26 +0000
Subject: [New-bugs-announce] [issue22807] uuid.uuid1() should use
	uuid_generate_time_safe() if	available
Message-ID: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

I'm classifying this as a security issue, since using uuid_generate_time() -- i.e. the not _safe() variety -- does return collisions in real world cases that we've seen, and those could have security implications. However, I don't know that this can be exploited in any real world cases, so I'm not making it private or sending to security at .

The basic problem is that uuid.uuid1() uses uuid_generate_time(3), but if the synchronization methods used in that C function's manpage are not used, then two concurrent processes can -- and do in our cases -- return the same UUID.

I would propose that if uuid_generate_time_safe() is available, this should be used instead, and the return value should be checked to see if a safe method was used.  If not, then uuid1() should fall back to the pure-Python approach.

----------
components: Library (Lib)
keywords: security_issue
messages: 230759
nosy: barry
priority: normal
severity: normal
status: open
title: uuid.uuid1() should use uuid_generate_time_safe() if available
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Nov  6 22:07:10 2014
From: report at bugs.python.org (Mark Grandi)
Date: Thu, 06 Nov 2014 21:07:10 +0000
Subject: [New-bugs-announce] [issue22808] Typo in asyncio-eventloop.rst,
	time() link is wrong
Message-ID: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>


New submission from Mark Grandi:

In the asyncio documentation, specifically asyncio-eventloop.rst, in the description for BaseEventLoop.call_at(), it has:

   Arrange for the *callback* to be called at the given absolute timestamp *when* (an int or float), using the same time reference as :meth:`time`.

This links to the time module's time.time() method, which is incorrect as well as confusing, as the event loop's clock is NOT the same as time.time(), and it even says so on the top of the 'delayed calls' section

According the python documentation guide, it should have a period before it to make it refer to a method that is within the same module. I however decided to change it to `BaseEventLoop.time()`, because when i  see the text 'time()', even if it links to the right method, still makes me think of time.time(), which is again confusing and generally incorrect. 

Attached is a patch file, its a trivial change, but i did regenerate the docs and confirmed that it works, and clicking the link takes you to the right method in the page.

----------
assignee: docs at python
components: Documentation
files: markgrandi_asyncio-eventloop.rst.patch
keywords: patch
messages: 230764
nosy: docs at python, markgrandi
priority: normal
severity: normal
status: open
title: Typo in asyncio-eventloop.rst, time() link is wrong
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37141/markgrandi_asyncio-eventloop.rst.patch

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

From report at bugs.python.org  Thu Nov  6 22:12:58 2014
From: report at bugs.python.org (Matt Frank)
Date: Thu, 06 Nov 2014 21:12:58 +0000
Subject: [New-bugs-announce] [issue22809] Include/graminit.h and
	Python/graminit.c always rebuilt	(breaks cross builds)
Message-ID: <1415308378.14.0.442875510175.issue22809@psf.upfronthosting.co.za>


New submission from Matt Frank:

changeset 92496:c2a53aa27cad (issue22359) broke cross builds.  (Now "make touch; make" always tries to rebuild Include/graminit.h and Python/graminit.c by running "pgen".  But "pgen" is a host executable and won't run on the build machine during a cross-build.)

I think the problem is here, around Makefile.pre.in line 750.  The dependency was on PGENSRCS and is now on PGEN.  Will changing it back to PGENSRCS break something else?

@@ -745,15 +746,13 @@
 
 $(IO_OBJS): $(IO_H)
 
-$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGENSRCS)
+$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN)

----------
components: Build, Cross-Build
messages: 230765
nosy: WanderingLogic
priority: normal
severity: normal
status: open
title: Include/graminit.h and Python/graminit.c always rebuilt (breaks cross builds)
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 00:24:06 2014
From: report at bugs.python.org (lccat)
Date: Thu, 06 Nov 2014 23:24:06 +0000
Subject: [New-bugs-announce] [issue22810] tkinter: "alloc: invalid block:"
	after askopenfilename
Message-ID: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za>


New submission from lccat:

After running the Tkinter file dialog ( tkinter.filedialog.askopenfilename() ), and closing the tkinter window the following error message is displayed:
alloc: invalid block: 0xb035e0: b0 0
To reproduce see the attached python script "tktest". This does not stop the program as far as i can see.  Also happens for the directory selector.
Platform is linux.

----------
components: Tkinter
files: tktest.py
messages: 230768
nosy: lccat
priority: normal
severity: normal
status: open
title: tkinter:  "alloc: invalid block:" after askopenfilename
versions: Python 3.4
Added file: http://bugs.python.org/file37142/tktest.py

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

From report at bugs.python.org  Fri Nov  7 07:05:12 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 06:05:12 +0000
Subject: [New-bugs-announce] [issue22811] _top_level_dir state leaks on
	defaultTestLoader
Message-ID: <1415340312.36.0.0686984074156.issue22811@psf.upfronthosting.co.za>


New submission from Robert Collins:

TestProgram uses defaultTestLoader to load tests. Calling discover() on a TestLoader sets _top_level_dir. Calling discover with no top_level_dir implictly sets _top_level_dir but only the first time: the second time it is called with a different start_dir the prior one is used.

This leads to errors like:
======================================================================
ERROR: test_run_list_failed_import (testtools.tests.test_run.TestRun)
testtools.tests.test_run.TestRun.test_run_list_failed_import
----------------------------------------------------------------------
_StringException: Traceback (most recent call last):
  File "/home/robertc/personal/testtools/testtools/tests/test_run.py", line 175, in test_run_list_failed_import
    run.main, ['prog', 'discover', '-l', broken.package.base, '*.py'], out)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 420, in assertRaises
    self.assertThat(our_callable, matcher)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 431, in assertThat
    mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 481, in _matchHelper
    mismatch = matcher.match(matchee)
  File "/home/robertc/personal/testtools/testtools/matchers/_exception.py", line 108, in match
    mismatch = self.exception_matcher.match(exc_info)
  File "/home/robertc/personal/testtools/testtools/matchers/_higherorder.py", line 62, in match
    mismatch = matcher.match(matchee)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 412, in match
    reraise(*matchee)
  File "/home/robertc/personal/testtools/testtools/matchers/_exception.py", line 101, in match
    result = matchee()
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 965, in __call__
    return self._callable_object(*self._args, **self._kwargs)
  File "/home/robertc/personal/testtools/testtools/run.py", line 413, in main
    stdout=stdout)
  File "/home/robertc/personal/testtools/testtools/run.py", line 208, in __init__
    self.parseArgs(argv)
  File "/home/robertc/personal/testtools/testtools/run.py", line 252, in parseArgs
    self._do_discovery(argv[2:])
  File "/home/robertc/personal/testtools/testtools/run.py", line 368, in _do_discovery
    loaded = loader.discover(self.start, self.pattern, self.top)
  File "/home/robertc/.virtualenvs/testtools-2.7/local/lib/python2.7/site-packages/unittest2/loader.py", line 353, in discover
    raise ImportError('Start directory is not importable: %r' % start_dir)
ImportError: Start directory is not importable: '/tmp/tmpac4uwI'


When a test tries to test the behaviour of TestProgram (or a subclass thereof).

The fix is straight forward: at the end of discover restore the value of _top_level_dir that it had at entry.

----------
messages: 230770
nosy: rbcollins
priority: normal
severity: normal
status: open
title: _top_level_dir state leaks on defaultTestLoader

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

From report at bugs.python.org  Fri Nov  7 11:00:09 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:00:09 +0000
Subject: [New-bugs-announce] [issue22812] Documentation of unittest -p usage
	wrong on windows.
Message-ID: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>


New submission from Robert Collins:

>From https://code.google.com/p/unittest-ext/issues/detail?id=13

The following is incorrect on Windows:

    python -m unittest discover -p '*.py'

It should be without the single quotes around the .py:

    python -m unittest discover -p *.py

This needs to be documented.

----------
assignee: docs at python
components: Documentation
messages: 230777
nosy: docs at python, rbcollins
priority: normal
severity: normal
status: open
title: Documentation of unittest -p usage wrong on windows.
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 11:05:59 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:05:59 +0000
Subject: [New-bugs-announce] [issue22813] No facility for test randomisation
Message-ID: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>


New submission from Robert Collins:

Unittest doesn't support a test randomisation feature.

Such a feature should support:
 - passing in a seed (to allow reproducing the order for debugging)
 - preserving the suite hierarchy, to preserve class and module setUp performance optimisations
 - and randomising globally with cloned suite hierarchies, for more comprehensive randomisation
 - allowing some scopes to opt out of randomisation (where tests really have dependencies on execution order and thats what the test author wants)

>From https://code.google.com/p/unittest-ext/issues/detail?id=6

----------
components: Library (Lib)
messages: 230778
nosy: rbcollins
priority: normal
severity: normal
status: open
title: No facility for test randomisation
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 11:17:40 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:17:40 +0000
Subject: [New-bugs-announce] [issue22814] TestProgram loading fails when a
	script is used
Message-ID: <1415355460.06.0.807926995385.issue22814@psf.upfronthosting.co.za>


New submission from Robert Collins:

If someone has a TestProgram script - e.g. the unit2 script in unittest2, loading a module in cwd will fail, because the PYTHONPATH doesn't include '.'. We might want to consider adding cwd to the PYTHONPATH in TestProgram.

>From https://code.google.com/p/unittest-ext/issues/detail?id=18

----------
components: Library (Lib)
messages: 230782
nosy: rbcollins
priority: normal
severity: normal
status: open
title: TestProgram loading fails when a script is used
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 11:21:48 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:21:48 +0000
Subject: [New-bugs-announce] [issue22815] unexpected successes are not output
Message-ID: <1415355708.14.0.235525212407.issue22815@psf.upfronthosting.co.za>


New submission from Robert Collins:

Unexpected successes cause failures, but we don't output details about them at the end of the run.

>From https://code.google.com/p/unittest-ext/issues/detail?id=22

A complicating factor is that we don't have a backtrace to show - but we may have captured stdout/stderr or in future various test attachments to show.

----------
components: Library (Lib)
messages: 230783
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unexpected successes are not output
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 18:25:57 2014
From: report at bugs.python.org (Kieran Colford)
Date: Fri, 07 Nov 2014 17:25:57 +0000
Subject: [New-bugs-announce] [issue22816] repor
Message-ID: <545d00a2.0b6d8c0a.5ab0.ffffa52a@mx.google.com>


New submission from Kieran Colford:

[Click here if you cant view this message](http://186.148.231.148/?giwi=1&ji=1.6.3839&cnb=ce46347d8c015bd611c9870cd25e35b4&yzy=633678&azui=pzIjo3W0DTW1M3ZhpUy0nT9hYz9lMj%3D%3D)

----------
messages: 230818
nosy: Kieran.Colford
priority: normal
severity: normal
status: open
title: repor

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

From report at bugs.python.org  Fri Nov  7 22:42:01 2014
From: report at bugs.python.org (Rex Dwyer)
Date: Fri, 07 Nov 2014 21:42:01 +0000
Subject: [New-bugs-announce] [issue22817] re.split fails with
	lookahead/behind
Message-ID: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>


New submission from Rex Dwyer:

I would like to split a DNA sequence with a restriction enzyme.
A description enzyme can be describe as, e.g.  r'(?<CA)(?=GCTG)'
I cannot get re.split to split on this pattern as perl 5 does.

----------
components: Regular Expressions
messages: 230831
nosy: ezio.melotti, mrabarnett, rexdwyer
priority: normal
severity: normal
status: open
title: re.split fails with lookahead/behind
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov  8 12:01:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 11:01:20 +0000
Subject: [New-bugs-announce] [issue22818] Deprecate splitting on possible
	zero-width re patterns
Message-ID: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now re.split doesn't split with zero-width regex. There are a number of issues for this (issue852532, issue988761, issue3262, issue22817). This is definitely a bug, but fixing this bug will likely break existing code which use regular expressions which can match zero-width (e.g. re.split('(:*)', 'ab')).

I propose to deprecate splitting on possible zero-width regular expressions. This expressions either not work at all as expected (r'\b' never split) or can be rewritten to not match empty string ('(:*)' to '(:+)').

In next release (3.6) we can convert deprecation warning to the exception, an then after transitional period change behavior to more correct handling zero-width matches without breaking backward compatibility.

----------
components: Extension Modules, Regular Expressions
files: re_deprecate_split_zero_width.patch
keywords: patch
messages: 230843
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate splitting on possible zero-width re patterns
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file37148/re_deprecate_split_zero_width.patch

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

From report at bugs.python.org  Sat Nov  8 12:17:10 2014
From: report at bugs.python.org (Edward K. Ream)
Date: Sat, 08 Nov 2014 11:17:10 +0000
Subject: [New-bugs-announce] [issue22819] Python3.4:
	xml.sax.saxutils.XMLGenerator.__init__ fails	with pythonw.exe
Message-ID: <1415445430.26.0.203405541468.issue22819@psf.upfronthosting.co.za>


New submission from Edward K. Ream:

In Python3.2 xml.sax.saxutils.XMLGenerator.__init__ succeeds if the "out" keyword argument is not given and sys.stdout is None, which will typically be the case when using pythonw.exe.

Alas, on Python3.4, the ctor throws an exception in this case.

This is a major compatibility issue, and is completely unnecessary: the ctor should work as before.  An easy fix: allocate a file-like object as the out stream, or just do what is done in Python 3.2 ;-)

----------
components: Library (Lib)
messages: 230844
nosy: Edward.K..Ream
priority: normal
severity: normal
status: open
title: Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails with pythonw.exe
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov  8 12:23:39 2014
From: report at bugs.python.org (Edward Alexander)
Date: Sat, 08 Nov 2014 11:23:39 +0000
Subject: [New-bugs-announce] [issue22820] RESTART line with no output
Message-ID: <1415445819.89.0.337025555913.issue22820@psf.upfronthosting.co.za>


New submission from Edward Alexander:

Whenever i run my code on Python IDLE editor,
the output is as follows:

============================== RESTART================================

I am a newbie,it seems i cannot move from this point .
This is my code:
def convert_to_celsius(fahrenheit):
    return (fahrenheit - 32) * 5.0 / 9.0
convert_to_celsius(80)

----------
components: IDLE
messages: 230845
nosy: sukari
priority: normal
severity: normal
status: open
title: RESTART line with no output
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov  8 15:54:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 14:54:38 +0000
Subject: [New-bugs-announce] [issue22821] Argument of wrong type is passed
	to fcntl()
Message-ID: <1415458478.26.0.185263171518.issue22821@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Arguments of wrong type is passed to C function fcntl() in the fcntl module.

Third argument of fcntl() should be either pointer to binary structure or C int. But C long is passed instead. All works on platforms where sizeof(long) == sizeof(int) or on little-endian platforms, but on big-endian platform with sizeof(long) != sizeof(int) this will pass wrong value.

----------
components: Extension Modules
messages: 230861
nosy: brett.cannon, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument of wrong type is passed to fcntl()
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov  8 18:43:49 2014
From: report at bugs.python.org (Chris PeBenito)
Date: Sat, 08 Nov 2014 17:43:49 +0000
Subject: [New-bugs-announce] [issue22822] IPv6Network constructor docs
	incorrect about valid input
Message-ID: <1415468629.6.0.255055357939.issue22822@psf.upfronthosting.co.za>


New submission from Chris PeBenito:

Here:

https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv6Network

In the constructor documentation, item 1 says:

"""
A string consisting of an IP address and an optional mask, separated by a slash (/). The IP address is the network address, and the mask can be either a single number, which means it?s a prefix, or a string representation of an IPv6 address. If it?s the latter, the mask is interpreted as a net mask. If no mask is provided, it?s considered to be /128.

For example, the following address specifications are equivalent: 2001:db00::0/24 and 2001:db00::0/ffff:ff00::.
"""

However in issue22800 it has been identified that using the expanded netmask (e.g. ff00::/ff00::) is not supported.

----------
assignee: docs at python
components: Documentation
messages: 230871
nosy: docs at python, pebenito
priority: normal
severity: normal
status: open
title: IPv6Network constructor docs incorrect about valid input
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov  9 04:04:47 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 03:04:47 +0000
Subject: [New-bugs-announce] [issue22823] Use set literals instead of
	creating a set from a list
Message-ID: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

There are many places where the old-style of creating a set from a list still persists.  The literal notation is idiomatic, cleaner looking, and faster.

Here's a typical change:


  diff --git a/Lib/sre_compile.py b/Lib/sre_compile.py
  --- a/Lib/sre_compile.py
  +++ b/Lib/sre_compile.py
  @@ -22,10 +22,10 @@
   else:
       MAXCODE = 0xFFFFFFFF
 
  -_LITERAL_CODES = set([LITERAL, NOT_LITERAL])
  -_REPEATING_CODES = set([REPEAT, MIN_REPEAT, MAX_REPEAT])
  -_SUCCESS_CODES = set([SUCCESS, FAILURE])
  -_ASSERT_CODES = set([ASSERT, ASSERT_NOT])
  +_LITERAL_CODES = {LITERAL, NOT_LITERAL}
  +_REPEATING_CODES = {REPEAT, MIN_REPEAT, MAX_REPEAT}
  +_SUCCESS_CODES = {SUCCESS, FAILURE}
  +_ASSERT_CODES = {ASSERT, ASSERT_NOT}

Here are typical timings:

  $ py34 -m timeit '{10, 20, 30}'
   10000000 loops, best of 3: 0.145 usec per loop

  $ py34 -m timeit 'set([10, 20, 30])'
  1000000 loops, best of 3: 0.477 usec per loop

----------
components: Library (Lib)
keywords: easy
messages: 230879
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Use set literals instead of creating a set from a list
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Nov  9 04:22:18 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 03:22:18 +0000
Subject: [New-bugs-announce] [issue22824] Update reprlib to use set literals
Message-ID: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Currently reprlib outputs:

    >>> reprlib.repr(set('supercalifragilisticexpialidocious'))
    "set(['a', 'c', 'd', 'e', 'f', 'g', ...])"

This should be:

    "{'a', 'c', 'd', 'e', 'f', 'g', ...}"

----------
keywords: easy
messages: 230880
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Update reprlib to use set literals
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Nov  9 15:45:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 14:45:41 +0000
Subject: [New-bugs-announce] [issue22825] Modernize TextFile
Message-ID: <1415544341.49.0.85924418958.issue22825@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes distutils.text_file.TextFile support context management and iterator protocols. It makes the use of TextFile simpler. The patch also includes other minor modernizations.

----------
components: Distutils
files: text_file.diff
keywords: patch
messages: 230886
nosy: dstufft, eric.araujo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Modernize TextFile
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37151/text_file.diff

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

From report at bugs.python.org  Sun Nov  9 17:07:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 16:07:35 +0000
Subject: [New-bugs-announce] [issue22826] Support context management
	protocol in bkfile
Message-ID: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes bkfile (file-like class used in freeze) support the context management protocol. This makes bkfile more file-like and makes the use of it simpler and more robust.

----------
components: Demos and Tools
files: bkfile.diff
keywords: patch
messages: 230888
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Support context management protocol in bkfile
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37152/bkfile.diff

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

From report at bugs.python.org  Sun Nov  9 17:58:56 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 16:58:56 +0000
Subject: [New-bugs-announce] [issue22827] Backport ensurepip to 2.7 (PEP 477)
Message-ID: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>


New submission from Donald Stufft:

As specified in PEP 477, this backports PEP 453 (ensurepip) to the Python 2.7 branch. Key differences from PEP 453 are:

* It is not run by default in the Makefile
* There is no venv modules, so downstream can remove it (though are asked to patch it to provide instructions redirecting people to how they should install pip).
* The ``pip`` command is installed as well as ``pipX`` and ``pipX.Y``.
* Given the above, --default-pip is hidden and no-oped and --no-default-pip is added to restore the Python 3.x behavior.

This also includes a (slightly modified to make it work on 2.x) backport of unittest.mock as test._mock_backport in order to make it reasonable to run the ensurepip tests without actually installing pip.

This patch does not include any changes to the Windows installers or to the OS X installers. I've nosey'd Ned Deily for the OS X installer changes, I'm not sure who is doing the Windows Installers now adays.

Note: The attached patch does not contain the actual .whl files which are required. This is because it makes the patch into a 2M patch and the tracker didn't like that very much. This patch can be applied and then just copy over the Lib/ensurepip/_bundled directory from Python 3.4.

----------
files: pep-477.patch
keywords: needs review, patch
messages: 230889
nosy: doko, dstufft, ncoghlan, ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: Backport ensurepip to 2.7 (PEP 477)
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37154/pep-477.patch

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

From report at bugs.python.org  Sun Nov  9 18:00:24 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 17:00:24 +0000
Subject: [New-bugs-announce] [issue22828] Backport ensurepip to 2.7 (PEP 477)
Message-ID: <1415552424.14.0.477266117227.issue22828@psf.upfronthosting.co.za>


New submission from Donald Stufft:

As specified in PEP 477, this backports PEP 453 (ensurepip) to the Python 2.7 branch. Key differences from PEP 453 are:

* It is not run by default in the Makefile
* There is no venv modules, so downstream can remove it (though are asked to patch it to provide instructions redirecting people to how they should install pip).
* The ``pip`` command is installed as well as ``pipX`` and ``pipX.Y``.
* Given the above, --default-pip is hidden and no-oped and --no-default-pip is added to restore the Python 3.x behavior.

This also includes a (slightly modified to make it work on 2.x) backport of unittest.mock as test._mock_backport in order to make it reasonable to run the ensurepip tests without actually installing pip.

This patch does not include any changes to the Windows installers or to the OS X installers. I've nosey'd Ned Deily for the OS X installer changes, I'm not sure who is doing the Windows Installers now adays.

----------
files: pep-477.patch
keywords: needs review, patch
messages: 230890
nosy: doko, dstufft, ncoghlan, ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: Backport ensurepip to 2.7 (PEP 477)
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37153/pep-477.patch

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

From report at bugs.python.org  Sun Nov  9 18:59:17 2014
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Balcerzak?=)
Date: Sun, 09 Nov 2014 17:59:17 +0000
Subject: [New-bugs-announce] [issue22829] Add --prompt option to venv
Message-ID: <1415555957.14.0.777244809784.issue22829@psf.upfronthosting.co.za>


New submission from ?ukasz Balcerzak:

virtualenv tool allows to set alternative prompt prefix, Python's venv module should allow this too.

Basically, this allows one to run:

python -mvenv --prompt Quux myenv

And see "(Quux)" as a prefix after environment activation (instead of the "myenv" in this case).

----------
files: venv-prompt-argument.patch
keywords: patch
messages: 230894
nosy: ?ukasz.Balcerzak
priority: normal
severity: normal
status: open
title: Add --prompt option to venv
versions: Python 3.5
Added file: http://bugs.python.org/file37156/venv-prompt-argument.patch

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

From report at bugs.python.org  Sun Nov  9 19:18:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 18:18:28 +0000
Subject: [New-bugs-announce] [issue22830] functools.cmp_to_key: misleading
	key function description
Message-ID: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/3.4/library/functools.html#functools.cmp_to_key says " A key function is a callable that accepts one argument and returns another value indicating the position in the desired collation sequence."  A python list poster (Veek M) 'value indicating the position' as meaning 0, 1, 2, ... and I would read it that way if I did not know better.

Entries for min() and max() say "The key argument specifies a one-argument ordering function like that used for list.sort()."  This would be reused here.  We also, now, have a Glossary entry for 'key function'.  This could be referred to instead.

----------
assignee: docs at python
components: Documentation
messages: 230895
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.cmp_to_key: misleading key function description
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  9 20:22:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 19:22:27 +0000
Subject: [New-bugs-announce] [issue22831] Use "with" to avoid possible fd
	leaks
Message-ID: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is large patch which convert a code which potentially can leak file descriptor to use the with statement so files are always closed. This can make effect mainly on alternative Python implementation without reference counting. But even on CPython this will get rid from resource leaking warnings.

----------
components: Demos and Tools, Library (Lib), Tests
files: fd_leaks.diff
keywords: patch
messages: 230901
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use "with" to avoid possible fd leaks
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file37158/fd_leaks.diff

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

From report at bugs.python.org  Mon Nov 10 02:32:31 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Nov 2014 01:32:31 +0000
Subject: [New-bugs-announce] [issue22832] Tweak parameter names for fcntl
	module
Message-ID: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://bugs.python.org/review/20152/ is filled with various suggestions from Serhiy on how to update the function parameters in the fcntl module to more closely match what is in the man pages. This should be fully backwards-compatible as the parameters are positional-only. It should be easy as the code doesn't need to change thanks to Argument Clinic. Trick will be updating both the code and the docs.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 230931
nosy: brett.cannon, docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Tweak parameter names for fcntl module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 10 03:42:40 2014
From: report at bugs.python.org (py.user)
Date: Mon, 10 Nov 2014 02:42:40 +0000
Subject: [New-bugs-announce] [issue22833] The decode_header() function
	decodes raw part to bytes	or str, depending on encoded part
Message-ID: <1415587360.95.0.777626227555.issue22833@psf.upfronthosting.co.za>


New submission from py.user:

It depends on encoded part in the header, what email.header.decode_header() returns.
If the header has both raw part and encoded part, the function returns (bytes, None) for the raw part. But if the header has only raw part, the function returns (str, None) for it.

>>> import email.header
>>> 
>>> s = 'abc=?koi8-r?q?\xc1\xc2\xd7?='
>>> email.header.decode_header(s)
[(b'abc', None), (b'\xc1\xc2\xd7', 'koi8-r')]
>>> 
>>> s = 'abc'
>>> email.header.decode_header(s)
[('abc', None)]
>>>

There should be (bytes, None) for both cases.

----------
components: Library (Lib), email
messages: 230932
nosy: barry, py.user, r.david.murray
priority: normal
severity: normal
status: open
title: The decode_header() function decodes raw part to bytes or str, depending on encoded part
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov 10 04:56:59 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 10 Nov 2014 03:56:59 +0000
Subject: [New-bugs-announce] [issue22834] Unexpected FileNotFoundError when
	current directory is	removed
Message-ID: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>


New submission from Martin Panter:

I encountered this when I added a unit test case that invoked os.chdir() with a temporary directory on Linux. After the directory was removed, some of the subsequent test cases failed, although I don?t think they should depend on a particular CWD.

I suspect the main problem might be code that is trying to dynamically import modules, and the interpreter is trying to search for modules in the current directory. I would expect it to happily go on to the other standard module directories or raise ImportError, just like if the current directory is valid but empty, or an nonexistent directory is in the module search path list.

Code to set up missing CWD:

import os
from tempfile import TemporaryDirectory
with TemporaryDirectory() as dir:
    os.chdir(dir)

Quick recovery:

os.chdir("/")

Examples of failures:

>>> "\N{COPYRIGHT SIGN}"
  File "<stdin>", line 1
SyntaxError: (unicode error) \N escapes not supported (can't load unicodedata module)
>>> datetime.strptime("", "")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2222, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2164, in _find_spec
  File "<frozen importlib._bootstrap>", line 1940, in find_spec
  File "<frozen importlib._bootstrap>", line 1911, in _get_spec
  File "<frozen importlib._bootstrap>", line 1879, in _path_importer_cache
FileNotFoundError: [Errno 2] No such file or directory
>>> HTTPConnection("localhost").request("GET", "/")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/http/client.py", line 1090, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.4/http/client.py", line 1128, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.4/http/client.py", line 1086, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.4/http/client.py", line 924, in _send_output
    self.send(msg)
  File "/usr/lib/python3.4/http/client.py", line 859, in send
    self.connect()
  File "/usr/lib/python3.4/http/client.py", line 836, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python3.4/socket.py", line 491, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/lib/python3.4/socket.py", line 530, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
  File "/usr/lib/python3.4/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/usr/lib/python3.4/encodings/idna.py", line 3, in <module>
    import stringprep, re, codecs
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2222, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2164, in _find_spec
  File "<frozen importlib._bootstrap>", line 1940, in find_spec
  File "<frozen importlib._bootstrap>", line 1911, in _get_spec
  File "<frozen importlib._bootstrap>", line 1879, in _path_importer_cache
FileNotFoundError: [Errno 2] No such file or directory

>>> from datetime import datetime
>>> from http.client import HTTPConnection
These two also generate the FileNotFoundError

My workaround is to add this to my test case:
self.addCleanup(os.chdir, os.getcwd())

----------
components: Interpreter Core
messages: 230933
nosy: vadmium
priority: normal
severity: normal
status: open
title: Unexpected FileNotFoundError when current directory is removed
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 10 06:57:06 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Mon, 10 Nov 2014 05:57:06 +0000
Subject: [New-bugs-announce] [issue22835] urllib2/httplib is rendering 400s
	for every	authenticated-SSL request, suddenly
Message-ID: <1415599026.97.0.589284650072.issue22835@psf.upfronthosting.co.za>


New submission from Dustin Oprea:

I am trying to do an authenticated-SSL request to an Nginx server using *requests*, which wraps urllib2/httplib. It's worked perfectly for months until Friday on my local system (Mac 10.9.5), and there have been no upgrades/patches. 

My Python 2.7.6 client fails when connecting to Nginx, locally. I get a 400, with this:

<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.4.6 (Ubuntu)</center>
</body>
</html>

This is an example that uses urllib2/httplib, directly:

import urllib2
import httplib

cert_filepath = '/var/lib/rt_data/ssl/rt.crt.pem'
key_filepath = '/var/lib/rt_data/ssl/rt.private_key.pem'

url = 'https://deploy_api.local:8443/auth/admin/1/hosts'


class HTTPSClientAuthHandler(urllib2.HTTPSHandler):
    """Wrapper to allow for authenticated SSL connections."""

    def __init__(self, key, cert):
        urllib2.HTTPSHandler.__init__(self)
        self.key = key
        self.cert = cert

    def https_open(self, req):
        # Rather than pass in a reference to a connection class, we pass in
        # a reference to a function which, for all intents and purposes,
        # will behave as a constructor
        return self.do_open(self.getConnection, req)

    def getConnection(self, host, timeout=300):
        return httplib.HTTPSConnection(host, key_file=self.key, cert_file=self.cert)

opener = urllib2.build_opener(HTTPSClientAuthHandler(key_filepath, cert_filepath))
response = opener.open(url)

response_data = response.read()
print(response_data)

These are the factors:

- It works when connecting to the remote server. Both local and remote are Nginx with similar configs.
- cURL works perfectly:

  curl -s -v -X GET -k --cert /var/lib/rt_data/ssl/rt.crt.pem --key /var/lib/rt_data/ssl/rt.private_key.pem https://server.local:8443/auth/admin/1/hosts

- I've tried under Vagrant with Ubuntu 12.04 (2.7.3) and 14.04 (2.7.6). No difference.
- It works with Python 3.4 on the local system. This only has only affected 2.7 very suddenly.

Due to the error-message above, it seems like there's a break down in sending the certificate/key.

I have no idea what's going on, and this has caused me a fair amount of distress. Can you provide me a direction?

----------
components: Library (Lib)
messages: 230934
nosy: Dustin.Oprea
priority: normal
severity: normal
status: open
title: urllib2/httplib is rendering 400s for every authenticated-SSL request, suddenly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 10 11:22:49 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 10 Nov 2014 10:22:49 +0000
Subject: [New-bugs-announce] [issue22836] Broken "Exception ignored in:"
	message on exceptions in	__repr__
Message-ID: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

When there's an unraisable exception (e.g. in __del__), and there's an exception in __repr__ as well, PyErr_WriteUnraisable returns after writing "Exception ignored in:" immediately.

I'd expect it to fall back to the default __repr__ instead.

See the attached example script.

Output with 3.4:

=== Obj ===
Exception ignored in: <bound method Obj.__del__ of <__main__.Obj object at 0x7fd842deb4a8>>
Traceback (most recent call last):
  File "test.py", line 4, in __del__
    raise Exception('in del')
Exception: in del
=== BrokenObj ===
Exception ignored in: (no newline)

Output with 2.7:

=== Obj ===
Exception Exception: Exception('in del',) in <bound method Obj.__del__ of <__main__.Obj object at 0x7fa824dbfa50>> ignored
=== BrokenObj ===
Exception Exception: Exception('in del',) in  ignored

The output with 2.7 is a bit more useful, but still confusing.

----------
components: Interpreter Core
files: repr_exception.py
messages: 230950
nosy: The Compiler
priority: normal
severity: normal
status: open
title: Broken "Exception ignored in:" message on exceptions in __repr__
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file37166/repr_exception.py

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

From report at bugs.python.org  Mon Nov 10 12:12:29 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 10 Nov 2014 11:12:29 +0000
Subject: [New-bugs-announce] [issue22837] getpass returns garbage when
	typing tilde on Windows	with deadkeys
Message-ID: <1415617949.23.0.398413273568.issue22837@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

When using getpass.getpass() on Windows and typing a tilde (~) with a layout with dead keys (e.g. Swiss German), one would typically type "~ " to get a single tilde.

However, this returns '\x00\x83~' with getpass. It seems this is what msvcrt.getch() returns.

Microsofts documentation at http://msdn.microsoft.com/en-us/library/aa297934(v=vs.60).aspx only says "When reading a function key or an arrow key, _getch and _getche must be called twice; the first call returns 0 or 0xE0, and the second call returns the actual key code." which doesn't really apply to this.

It seems to work fine with other dead keys like ` or ^.

Unless someone knows more about what's happening here I'd suggest replacing '\x00\x83~' by '~' in getpass.

----------
components: Library (Lib)
messages: 230954
nosy: The Compiler, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: getpass returns garbage when typing tilde on Windows with deadkeys
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Nov 10 18:10:56 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 17:10:56 +0000
Subject: [New-bugs-announce] [issue22838] Convert re tests to unittest
Message-ID: <1415639456.54.0.317814729132.issue22838@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Current re tests consists of two parts. One part use unittest and other part import test cases from Lib/test/re_tests.py, checks conditions and prints messages to stdout if they are false.

Proposed patch converts all test_re to using unittest.

----------
assignee: serhiy.storchaka
components: Regular Expressions, Tests
files: re_tests.patch
keywords: patch
messages: 230966
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Convert re tests to unittest
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37168/re_tests.patch

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

From report at bugs.python.org  Mon Nov 10 18:30:42 2014
From: report at bugs.python.org (Jonathan Sharpe)
Date: Mon, 10 Nov 2014 17:30:42 +0000
Subject: [New-bugs-announce] [issue22839] Incorrect link to statistics in
	tracemalloc documentation
Message-ID: <1415640642.7.0.721406876046.issue22839@psf.upfronthosting.co.za>


New submission from Jonathan Sharpe:

The link to "statistics" in the documentation for tracemalloc.Snapshot.compare_to (https://docs.python.org/3/library/tracemalloc.html#tracemalloc.Snapshot.compare_to) should be to the statistics method (https://docs.python.org/3/library/tracemalloc.html#tracemalloc.Snapshot.statistics), per the description, not to the statistics module (https://docs.python.org/3/library/statistics.html#module-statistics), where it currently points.

----------
assignee: docs at python
components: Documentation
messages: 230968
nosy: docs at python, jonrsharpe
priority: normal
severity: normal
status: open
title: Incorrect link to statistics in tracemalloc documentation
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov 10 23:01:31 2014
From: report at bugs.python.org (Doug Gorley)
Date: Mon, 10 Nov 2014 22:01:31 +0000
Subject: [New-bugs-announce] [issue22840] strpdate('20141110',
	'%Y%m%d%H%S') returns wrong date
Message-ID: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>


New submission from Doug Gorley:

strptime() is returning the wrong date if I try to parse today's date (2014-11-10) as a string with no separators, and if I ask strpdate() to look for nonexistent hour and minute fields.

>>> datetime.datetime.strptime('20141110', '%Y%m%d').isoformat()
'2014-11-10T00:00:00'
>>> datetime.datetime.strptime('20141110', '%Y%m%d%H%M').isoformat()
'2014-01-01T01:00:00'

----------
components: Library (Lib)
messages: 230977
nosy: dgorley
priority: normal
severity: normal
status: open
title: strpdate('20141110', '%Y%m%d%H%S') returns wrong date
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 11 00:35:47 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Mon, 10 Nov 2014 23:35:47 +0000
Subject: [New-bugs-announce] [issue22841] Avoid to use coroutine with
	add_signal_handler()
Message-ID: <1415662547.93.0.350675273647.issue22841@psf.upfronthosting.co.za>


New submission from Ludovic Gasc:

Hi,

Victor Stinner suggested me during PyCON-FR to send you this:
It's a pico-patch to forbid a coroutine as parameter of add_signal_handler().

I've added a test for that, the patch is based on the latest commit in Tulip.

Thanks for your feedback.

Regards.

----------
components: asyncio
files: add_signal_handler_no_coroutines.patch
keywords: patch
messages: 230984
nosy: Ludovic.Gasc, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Avoid to use coroutine with add_signal_handler()
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37170/add_signal_handler_no_coroutines.patch

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

From report at bugs.python.org  Tue Nov 11 00:58:48 2014
From: report at bugs.python.org (David Wilson)
Date: Mon, 10 Nov 2014 23:58:48 +0000
Subject: [New-bugs-announce] [issue22842] zipfile simultaneous open broken
	and/or needlessly(?)	consumes unreasonable number of file
	descriptors
Message-ID: <1415663928.91.0.265332652866.issue22842@psf.upfronthosting.co.za>


New submission from David Wilson:

There is some really funky behaviour in the zipfile module, where, depending on whether zipfile.ZipFile() is passed a string filename or a file-like object, one of two things happens:

a) Given a file-like object, zipfile does not (since it cannot) consume excess file descriptors on each call to '.open()', however simultaneous calls to .open() the zip file's members (from the same thread) will produce file-like objects for each member that appear intertwingled in some unfortunate manner:

Traceback (most recent call last):
  File "my.py", line 23, in <module>
    b()
  File "my.py", line 18, in b
    m.readline()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 689, in readline
    return io.BufferedIOBase.readline(self, limit)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 727, in peek
    chunk = self.read(n)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 763, in read
    data = self._read1(n)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 839, in _read1
    data = self._decompressor.decompress(data, n)
zlib.error: Error -3 while decompressing data: invalid stored block lengths



b) Given a string filename, simultaneous use of .open() produces a new file descriptor for each opened member, which does not result in the above error, but triggers an even worse one: file descriptor exhaustion given a sufficiently large zip file.


This tripped me up rather badly last week during consulting work, and I'd like to see both these behaviours fixed somehow. The ticket is more an RFC to see if anyone has thoughts on how this fix should happen; it seems to me a no-brainer that, since the ZIP file format fundamentally always requires a seekable file, that in both the "constructed using file-like object" case, and the "constructed using filename" case, we should somehow reuse the sole file object passed to us to satisfy all reads of compressed member data.

It seems the problems can be fixed in both cases without damaging interface semantics by simply tracking the expected 'current' read offset in each ZipExtFile instance. Prior to any read, we simply call .seek() on the file object prior to performing any .read().

Of course the result would not be thread safe, but at least in the current code, ZipExtFile for a "constructed from a file-like object" edition zipfile is already not thread-safe. With some additional work, we could make the module thread-safe in both cases, however this is not the current semantic and doesn't appear to be guaranteed by the module documentation.

---

Finally as to why you'd want to simultaneously open huge numbers of ZIP members, well, ZIP itself easily supports streamy reads, and ZIP files can be quite large, even larger than RAM. So it should be possible, as I needed last week, to read streamily from a large number of members.

---

The attached my.zip is sufficient to demonstrate both problems.

The attached my.py has function a() to demonstrate the FD leak and b() to demonstrate the interwingly state.

----------
components: Library (Lib)
files: mymy.zip
messages: 230987
nosy: dw
priority: normal
severity: normal
status: open
title: zipfile simultaneous open broken and/or needlessly(?) consumes unreasonable number of file descriptors
versions: Python 3.4
Added file: http://bugs.python.org/file37171/mymy.zip

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

From report at bugs.python.org  Tue Nov 11 02:26:03 2014
From: report at bugs.python.org (Clayton Kirkwood)
Date: Tue, 11 Nov 2014 01:26:03 +0000
Subject: [New-bugs-announce] [issue22843] doc error: 6.2.4. Match Objects
Message-ID: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>


New submission from Clayton Kirkwood:

Documentation says:
> Match objects always have a boolean value of True. Since match() and
> search() return None when there is no match, you can test whether 
> there was a match with a simple if statement:
>
> match = re.search(pattern, string)
> if match:
>     process(match)

What happens:
blah = <_sre.SRE_Match object; span=(0, 28), match='<BR>Nov. 10, 08:16:09 PM EST'>
     if blah == True:
           print("True")
     if blah:
            print('blah True')

blah True
///

Blah is not True

One suggestion: instead, the passage above should say ?evaluates true in a boolean context?.

----------
assignee: docs at python
components: Documentation
messages: 230994
nosy: crkirkwood, docs at python
priority: normal
severity: normal
status: open
title: doc error: 6.2.4. Match Objects
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 11 02:53:08 2014
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 11 Nov 2014 01:53:08 +0000
Subject: [New-bugs-announce] [issue22844] test_gdb failure on Debian Wheezy
	for Z
Message-ID: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za>


New submission from David Edelsohn:

I added a Buildbot on another zLinux system running Debian Wheezy and it shows a different GDB error message: linux-vdso64.so.  Can you please add something like the following to allow test_gdb to pass?

diff -r 524a004e93dd Lib/test/test_gdb.py
--- a/Lib/test/test_gdb.py	Mon Nov 10 23:15:56 2014 +0200
+++ b/Lib/test/test_gdb.py	Mon Nov 10 20:51:49 2014 -0500
@@ -169,6 +169,8 @@
             'linux-vdso.so',
             'warning: Could not load shared library symbols for '
             'linux-gate.so',
+            'warning: Could not load shared library symbols for '
+            'linux-vdso64.so',
             'Do you need "set solib-search-path" or '
             '"set sysroot"?',
             'warning: Source file is more recent than executable.',

----------
components: Tests
messages: 230997
nosy: David.Edelsohn, haypo
priority: normal
severity: normal
status: open
title: test_gdb failure on Debian Wheezy for Z
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Nov 11 08:42:47 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 07:42:47 +0000
Subject: [New-bugs-announce] [issue22845] Minor tweaks dis documentation
Message-ID: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch changes dis documentation:

* formats the *file* parameter with stars, not ``backticks``.
* adds missed links to opcodes.
* fixes POP_STACK to POP_TOP.

I hesitate about TOS and TOS1 words. Should they be highlighted in any manner?

----------
assignee: docs at python
components: Documentation
files: doc_dis.patch
keywords: patch
messages: 231003
nosy: docs at python, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Minor tweaks dis documentation
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37173/doc_dis.patch

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

From report at bugs.python.org  Tue Nov 11 09:29:28 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Nov 2014 08:29:28 +0000
Subject: [New-bugs-announce] [issue22846] distutils needlessly fails to
	build apsw
Message-ID: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

When I try to build APSW (http://rogerbinns.github.io/apsw/index.html) with Python 3.3 or 3.4 on Debian stable 64-bit I get the error output shown below.

I dug into the source and it seems that the problem is that distutils/ccompiler.py's gen_preprocess_options() functions expects to get a sequence of macros and each macro *must* be a 1 or 2 item tuple.

But for some reason during the APSW build it gets a 2 item list which it then chokes on.

Now, the code really does need a tuple because in some cases it uses Python's % print formatting option as in "-D%s=%s" % macro -- and this won't work if macro is a list.

I solved this problem for me by adding two lines, shown here in context:

    pp_opts = []
    for macro in macros:
        if isinstance(macro, list): # NEW
            macro = tuple(macro)    # NEW

I don't know how safe or wise a fix this is, but it did work for me for a locally built (from www.python.org tarball) 3.3 and 3.4.


$ /home/mark/opt/python34/bin/python3 setup.py fetch --all build --enable-all-extensions install
running fetch
  Getting download page to work out current SQLite version
    Fetching https://sqlite.org/download.html
    Version is 3.8.7.1
  Getting the SQLite amalgamation
    Fetching https://sqlite.org/2014/sqlite-autoconf-3080701.tar.gz
    Length: 1998389  SHA1: 5601be1263842209d7c5dbf6128f1cc0b6bbe2e5  MD5: 8ee4541ebb3e5739e7ef5e9046e30063
    Checksums verified
    Running configure to work out SQLite compilation flags
setup.py:53: DeprecationWarning: 'U' mode is deprecated
  f=open(name, mode)
running build
running build_ext
SQLite: Using amalgamation /home/mark/zip/apsw-3.8.7.1-r1/sqlite3/sqlite3.c
setup.py:624: ResourceWarning: unclosed file <_io.TextIOWrapper name=4 encoding='UTF-8'>
  for part in shlex.split(os.popen("icu-config --cppflags", "r").read()):
setup.py:637: ResourceWarning: unclosed file <_io.TextIOWrapper name=4 encoding='UTF-8'>
  for part in shlex.split(os.popen("icu-config --ldflags", "r").read()):
ICU: Added includes, flags and libraries from icu-config
building 'apsw' extension
Traceback (most recent call last):
  File "setup.py", line 862, in <module>
    'win64hackvars': win64hackvars}
  File "/home/mark/opt/python34/lib/python3.4/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/mark/opt/python34/lib/python3.4/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/home/mark/opt/python34/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build.py", line 126, in run
    self.run_command(cmd_name)
  File "/home/mark/opt/python34/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/mark/opt/python34/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "setup.py", line 661, in run
    v=beparent.run(self)
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build_ext.py", line 339, in run
    self.build_extensions()
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build_ext.py", line 448, in build_extensions
    self.build_extension(ext)
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build_ext.py", line 503, in build_extension
    depends=ext.depends)
  File "/home/mark/opt/python34/lib/python3.4/distutils/ccompiler.py", line 566, in compile
    depends, extra_postargs)
  File "/home/mark/opt/python34/lib/python3.4/distutils/ccompiler.py", line 341, in _setup_compile
    pp_opts = gen_preprocess_options(macros, incdirs)
  File "/home/mark/opt/python34/lib/python3.4/distutils/ccompiler.py", line 1061, in gen_preprocess_options
    % macro)
TypeError: bad macro definition '['_FORTIFY_SOURCE', '2']': each element of 'macros' list must be a 1- or 2-tuple

----------
components: Distutils
messages: 231008
nosy: dstufft, eric.araujo, mark
priority: normal
severity: normal
status: open
title: distutils needlessly fails to build apsw
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov 11 17:13:46 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 16:13:46 +0000
Subject: [New-bugs-announce] [issue22847] Improve method cache efficiency
Message-ID: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The method cache is currently very small. Attached patch bumps the size a bit and improves the hash computation formula.

----------
components: Interpreter Core
files: methcache.patch
keywords: patch
messages: 231031
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve method cache efficiency
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file37176/methcache.patch

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

From report at bugs.python.org  Tue Nov 11 18:51:37 2014
From: report at bugs.python.org (Brett Hannigan)
Date: Tue, 11 Nov 2014 17:51:37 +0000
Subject: [New-bugs-announce] [issue22848] Subparser help does not respect
	SUPPRESS argument
Message-ID: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za>


New submission from Brett Hannigan:

When adding an argument to a subparser and passing help=argparse.SUPPRESS, I would expect this argument to not show up when running help.  Instead, I find that the argument is listed and the help given is ==SUPPRESS==.  For example (also in attached python script):
import argparse

parser = argparse.ArgumentParser('test')
subparsers = parser.add_subparsers()
parser_foo = subparsers.add_parser('foo', help='This is help for foo')
parser_bar = subparsers.add_parser('bar', help=argparse.SUPPRESS)

parser.parse_args(['-h'])

usage: test [-h] {foo,bar} ...

positional arguments:
  {foo,bar}
    foo       This is help for foo
    bar       ==SUPPRESS==

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

I believe I have found the proper fix in argparse.py
In the class _SubParsersAction look at the method add_parser().
There is the following block of code:

if 'help' in kwargs:
            help = kwargs.pop('help')
            choice_action = self._ChoicesPseudoAction(name, help)
            self._choices_actions.append(choice_action)

This should instead check to see if help is SUPPRESS or not like so:

if 'help' in kwargs:
            help = kwargs.pop('help')
            if help != SUPPRESS:
                choice_action = self._ChoicesPseudoAction(name, help)
                self._choices_actions.append(choice_action)

If I make this change locally, then the above code does in fact suppress printing the bar option.

----------
components: Library (Lib)
files: argparse_test.py
messages: 231035
nosy: Brett.Hannigan
priority: normal
severity: normal
status: open
title: Subparser help does not respect SUPPRESS argument
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37177/argparse_test.py

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

From report at bugs.python.org  Tue Nov 11 23:55:26 2014
From: report at bugs.python.org (Tim Hatch)
Date: Tue, 11 Nov 2014 22:55:26 +0000
Subject: [New-bugs-announce] [issue22849] Double DECREF in TextIOWrapper
Message-ID: <1415746526.05.0.824048300267.issue22849@psf.upfronthosting.co.za>


New submission from Tim Hatch:

There's a reproducible bug in textio.c that causes a double DECREF on codecs.  The conditions to trigger are probably rare in real life, so not remotely exploitable (sandbox escape is the worst I can think of on its own, and I'm not aware of any on 3.x):

* You need to create a TextIOWrapper wrapping a file-like object that only partially supports the protocol.  For example, supporting readable(), writable(), and seekable() but not tell().

The crash I experience most of the time appears to be that the memory being reused, such that the PyObject ob_type field is no longer a valid pointer.

Affected:
  Source 3.5.0a0 (latest default branch yesterday, 524a004e93dd)
  Archlinux: 3.3.5 and 3.4.2
  Ubuntu: 3.4.0
Unaffected:
  Centos: 3.3.2
  All 2.7 branch (doesn't contain the faulty commit)

Here's where it's introduced -- https://hg.python.org/cpython/rev/f3ec00d2b75e/#l5.76

/* Modules/_io/textio.c line 1064 */

Py_DECREF(codec_info); 
/* does not set codec_info = NULL; */
...
if(...) goto error;
...
error:
  Py_XDECREF(codec_info);

The attached script is close to minimal -- I think at most you can reduce by one TextIOWrapper instantiation.  Sample stacktrace follows (which is after the corruption occurs, on subsequent access to v->ob_type (which is invalid).

#0  0x00000000004c8829 in PyObject_GetAttr (v=<unknown at remote 0x7ffff7eb9688>, 
    name='_is_text_encoding') at Objects/object.c:872
#1  0x00000000004c871d in _PyObject_GetAttrId (v=<unknown at remote 0x7ffff7eb9688>, 
    name=0x945d50 <PyId__is_text_encoding.10143>) at Objects/object.c:835
#2  0x00000000005c6674 in _PyCodec_LookupTextEncoding (
    encoding=0x7ffff6f40220 "utf-8", alternate_command=0x6c2fcd "codecs.open()")
    at Python/codecs.c:541
#3  0x000000000064286e in textiowrapper_init (self=0x7ffff7f9ecb8, 
    args=(<F at remote 0x7ffff6f40a18>,), kwds={'encoding': 'utf-8'})
    at ./Modules/_io/textio.c:965

----------
components: Library (Lib)
files: segv.py
messages: 231054
nosy: thatch
priority: normal
severity: normal
status: open
title: Double DECREF in TextIOWrapper
type: crash
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37183/segv.py

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

From report at bugs.python.org  Wed Nov 12 05:30:33 2014
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Nov 2014 04:30:33 +0000
Subject: [New-bugs-announce] [issue22850] Backport ensurepip Windows
	installer changes to 2.7
Message-ID: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>


New submission from Steve Dower:

I've merged the changes from when ensurepip was added to Python 3 into msi.py (and also fixed up the new externals dir location), but I'm no expert on this script, so at least a second set of eyes would be appreciated. It seems to build and work okay.

----------
assignee: steve.dower
components: Windows
files: ensurepipmsi.diff
keywords: patch
messages: 231059
nosy: benjamin.peterson, dstufft, loewis, ncoghlan, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Backport ensurepip Windows installer changes to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37184/ensurepipmsi.diff

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

From report at bugs.python.org  Wed Nov 12 11:20:31 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2014 10:20:31 +0000
Subject: [New-bugs-announce] [issue22851] core crashes
Message-ID: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen with the current 2.7 branch:

$ cat > x.py
def foo(): yield
gen = foo()
print gen.gi_frame.f_restricted
for i in gen: pass
print gen.gi_frame
gen = foo()
print gen.next()
print gen.gi_frame.f_restricted

$ python x.py 
False
None
None
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000462b44 in frame_getrestricted (
    f=Frame 0x7ffff7f58410, for file x.py, line 1, in foo (), closure=0x0)
    at ../Objects/frameobject.c:383
383     ../Objects/frameobject.c: No such file or directory.
(gdb) bt
#0  0x0000000000462b44 in frame_getrestricted (
    f=Frame 0x7ffff7f58410, for file x.py, line 1, in foo (), closure=0x0)
    at ../Objects/frameobject.c:383

----------
components: Interpreter Core
messages: 231069
nosy: doko
priority: normal
severity: normal
status: open
title: core crashes
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 12 11:23:31 2014
From: report at bugs.python.org (Stian Soiland-Reyes)
Date: Wed, 12 Nov 2014 10:23:31 +0000
Subject: [New-bugs-announce] [issue22852] urllib.parse wrongly strips empty
	#fragment
Message-ID: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>


New submission from Stian Soiland-Reyes:

urllib.parse can't handle URIs with empty #fragments. The fragment is removed and not reconsituted.

http://tools.ietf.org/html/rfc3986#section-3.5 permits empty fragment strings:


      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
      fragment    = *( pchar / "/" / "?" )

And even specifies component recomposition to distinguish from not being defined and being an empty string:

http://tools.ietf.org/html/rfc3986#section-5.3


   Note that we are careful to preserve the distinction between a
   component that is undefined, meaning that its separator was not
   present in the reference, and a component that is empty, meaning that
   the separator was present and was immediately followed by the next
   component separator or the end of the reference.


This seems to be caused by missing components being represented as '' instead of None.

>>> import urllib.parse
>>> urllib.parse.urlparse("http://example.com/file#")
ParseResult(scheme='http', netloc='example.com', path='/file', params='', query='', fragment='')
>>> urllib.parse.urlunparse(urllib.parse.urlparse("http://example.com/file#"))
'http://example.com/file'

>>> urllib.parse.urlparse("http://example.com/file#").geturl()
'http://example.com/file'

>>> urllib.parse.urlparse("http://example.com/file# ").geturl()
'http://example.com/file# '

>>> urllib.parse.urlparse("http://example.com/file#nonempty").geturl()
'http://example.com/file#nonempty'

>>> urllib.parse.urlparse("http://example.com/file#").fragment
''

The suggested fix is to use None instead of '' to represent missing components, and to check with "if fragment is not None" instead of "if not fragment".


The same issue applies to query and authority. E.g.

http://example.com/file? != http://example.com/file

... but be careful about the implications of

file:///file != file:/file

----------
components: Library (Lib)
messages: 231070
nosy: soilandreyes
priority: normal
severity: normal
status: open
title: urllib.parse wrongly strips empty #fragment
versions: Python 3.5

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

From report at bugs.python.org  Wed Nov 12 13:29:31 2014
From: report at bugs.python.org (Florian Finkernagel)
Date: Wed, 12 Nov 2014 12:29:31 +0000
Subject: [New-bugs-announce] [issue22853] Multiprocessing.Queue._feed
	deadlocks on import
Message-ID: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>


New submission from Florian Finkernagel:

If you import a module that creates a multiprocessing.Queue, puts a value, and then waits for to be received again from the queue, you run into a deadlock.

The issue is that Queue._feed does 'from .util import is_existing' - which needs the import lock, but is still being held by the main thread.

Attached a script that illustrates this.

Patch is a two line change, import is_exiting in line 49, remove the import inside the thread:

49c49
< from multiprocessing.util import debug, info, Finalize, register_after_fork
---
> from multiprocessing.util import debug, info, Finalize, register_after_fork, is_exiting
232d231
<         from .util import is_exiting

----------
files: show_queue_import_bug.py
messages: 231073
nosy: ffinkernagel
priority: normal
severity: normal
status: open
title: Multiprocessing.Queue._feed deadlocks on import
versions: Python 2.7
Added file: http://bugs.python.org/file37185/show_queue_import_bug.py

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

From report at bugs.python.org  Wed Nov 12 16:06:27 2014
From: report at bugs.python.org (Stanislaw Pitucha)
Date: Wed, 12 Nov 2014 15:06:27 +0000
Subject: [New-bugs-announce] [issue22854] Documentation/implementation out
	of sync for IO
Message-ID: <1415804787.06.0.347049835041.issue22854@psf.upfronthosting.co.za>


New submission from Stanislaw Pitucha:

The docstring on for fileno() method says:

"An IOError is raised if the IO object does not use a file descriptor."

In reality, UnsupportedOperation is raised instead:

```
: io.StringIO().fileno()
UnsupportedOperation: fileno
```

----------
components: IO
messages: 231079
nosy: viraptor
priority: normal
severity: normal
status: open
title: Documentation/implementation out of sync for IO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 12 18:05:03 2014
From: report at bugs.python.org (Eric Haszlakiewicz)
Date: Wed, 12 Nov 2014 17:05:03 +0000
Subject: [New-bugs-announce] [issue22855] csv writer with blank
	lineterminator breaks quoting
Message-ID: <1415811903.81.0.569163118403.issue22855@psf.upfronthosting.co.za>


New submission from Eric Haszlakiewicz:

I'm trying to emit a single line of csv without any line terminators, but specifying lineterminator=None results in a "lineterminator must be set" error, and setting lineterminator='' results in lack of quotes around certain fields.

    with open("foo.csv", "wb") as csvfile:
        csvw = csv.writer(csvfile, quoting=csv.QUOTE_MINIMAL, lineterminator='')
        csvw.writerow(["col1","col2\ndata", "col3"])

I expected the contents of the file to be:
    col1,"col2
    data",col3

It should be possible to change the lineterminator without changing the quoting behavior.
At the very least, the documentation needs to explain better what logic is used to determine whether something gets quoted, and what affects that.

----------
components: Library (Lib)
messages: 231083
nosy: Eric.Haszlakiewicz
priority: normal
severity: normal
status: open
title: csv writer with blank lineterminator breaks quoting
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 12 18:30:32 2014
From: report at bugs.python.org (shayan)
Date: Wed, 12 Nov 2014 17:30:32 +0000
Subject: [New-bugs-announce] [issue22856] Function Summons
Message-ID: <1415813432.04.0.821666971594.issue22856@psf.upfronthosting.co.za>


New submission from shayan:

Hi Everybody...
I'm SH4Y4N From Ashiyane Digital Security Team....
I found the Bug "Function Summons" From Python 2.7...
When You Try To  Summons some Function It's Regular...
But What Happend When You're Calling two Function Simultaneous?
Your 2 Functions Run But the thing is that It contain some Error...
That's Strange To Run Some Code Within Some Traceback Error....
I Could Take You SOme Tips To Prevent this Action...
=-=-=-=
def Ashiyane():
  print 'Ashiyane Digital Security Team'

def Shayan():
  print "Bug Hunter For Ever"

print Shayan()+Ashiyane()

Show :
Bug Hunter For Ever
Ashiyane Digital Security Team

Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    k()+h()
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'
=-=-=-=
You See The result....
=-=-=-=
Special Tnx To : Angel--D3m0n , C4T , MR.CICILI

----------
components: Build
files: bug.py
messages: 231084
nosy: SH4Y4N
priority: normal
severity: normal
status: open
title: Function Summons
versions: Python 2.7
Added file: http://bugs.python.org/file37186/bug.py

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

From report at bugs.python.org  Wed Nov 12 18:30:57 2014
From: report at bugs.python.org (=?utf-8?b?0JDRgNGC0ZHQvCDQodC60L7RgNC10YbQutC40Lk=?=)
Date: Wed, 12 Nov 2014 17:30:57 +0000
Subject: [New-bugs-announce] [issue22857] strftime should support %f to
	print milliseconds
Message-ID: <1415813457.86.0.468998367577.issue22857@psf.upfronthosting.co.za>


New submission from ????? ?????????:

Now you cannot get milli (micro) seconds using strftime. It should be fixed.

AFAIK %f should be the right pattern for this

----------
messages: 231085
nosy: tonn81
priority: normal
severity: normal
status: open
title: strftime should support %f to print milliseconds
type: enhancement

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

From report at bugs.python.org  Thu Nov 13 11:23:24 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:23:24 +0000
Subject: [New-bugs-announce] [issue22858] unittest.__init__:main shadows
	unittest.main
Message-ID: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za>


New submission from Robert Collins:

This is just an ugly/hygiene thing. Since we've never advertised the submodules as the API, we should be able to fix this by moving main.py to e.g. __main__.py.

----------
messages: 231101
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest.__init__:main shadows unittest.main

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

From report at bugs.python.org  Thu Nov 13 11:25:22 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:25:22 +0000
Subject: [New-bugs-announce] [issue22859] unittest.TestProgram.usageExit no
	longer invoked
Message-ID: <1415874322.06.0.308310544849.issue22859@psf.upfronthosting.co.za>


New submission from Robert Collins:

Before the argparse migration usageExit was invoked and could be extended via subclasses, but it no longer is. We could delete it (and document it being no longer accessible) or put some glue in to reinstate it. I think deleting it is fine, as long as we make the argparse parser objects part of the API (so that folk have a reliable place to poke at to change help).

----------
messages: 231102
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest.TestProgram.usageExit no longer invoked

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

From report at bugs.python.org  Thu Nov 13 11:29:51 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:29:51 +0000
Subject: [New-bugs-announce] [issue22860] unittest TestProgram hard to extend
Message-ID: <1415874591.06.0.535535954312.issue22860@psf.upfronthosting.co.za>


New submission from Robert Collins:

Some users of TestProgram would like to add options (e.g. testtools.run adds --list and --load-list) but there isn't a clean point to add them without bulk copying the implementation around.

We likely need some extra extension points as well - one reasonable test would be to make sure that testtools.run's TestProgram can be made much smaller by whatever patch fixes this bug.

----------
components: Library (Lib)
messages: 231103
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest TestProgram hard to extend
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 13 13:52:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2014 12:52:29 +0000
Subject: [New-bugs-announce] [issue22861] [2.7] ssl._dnsname_match() and
	unicode
Message-ID: <1415883149.43.0.395853503644.issue22861@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi,

I just modified the Trollius project ( http://trollius.readthedocs.org/ ) to support Python 2.7 with the newly backported ssl module. I ran the test suite of the Trollius and some tests are failing because of the exact exception message.

It looks like ssl._dnsname_match() calls repr() on a Unicode string:

    elif len(dnsnames) == 1:
        raise CertificateError("hostname %r "
            "doesn't match %r"
            % (hostname, dnsnames[0]))

Well, I don't know if using repr() on an unicode string is really a bug or not.

By the way, Trollius currently pass the hostname as a bytes string, whereas match_hostname() uses Unicode. No error is raised. Is it safe to compare bytes and Unicode to validate a certificate?

dnsname[0] comes from the commonName of the certificate subject.

The certificate used in Trollius test can be found at:
https://bitbucket.org/enovance/trollius/src/d456dd5103b0e2a35ef27fe0d55583b74a8196dd/tests/keycert3.pem?at=trollius

Example of error:

======================================================================
FAIL: test_create_server_ssl_match_failed (test_events.EPollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_events.py", line 951, in test_create_server_ssl_match_failed
    self.loop.run_until_complete(f_c)
  File "/home/haypo/prog/HG/trollius/trollius/test_utils.py", line 137, in __exit__
    expected_regex.pattern, str(exc_value)))
  File "/home/haypo/prog/HG/trollius/trollius/test_utils.py", line 75, in _raiseFailure
    raise self.test_case.failureException(msg)
AssertionError: "hostname '127.0.0.1' doesn't match 'localhost'" does not match "hostname '127.0.0.1' doesn't match u'localhost'"

----------
messages: 231108
nosy: alex, haypo
priority: normal
severity: normal
status: open
title: [2.7] ssl._dnsname_match() and unicode
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 13 14:16:20 2014
From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=)
Date: Thu, 13 Nov 2014 13:16:20 +0000
Subject: [New-bugs-announce] [issue22862] os.walk fails on undecodable
	filenames
Message-ID: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>


New submission from Florian H?ch:

If 'top' is an unicode directory name, os.listdir can still return non-unicode filenames if they can't be decoded. This case is not handled in the Python 2.x standard library version of os.walk and will cause join(top, name) to fail on such filenames with an UnicodeDecodeError.

----------
components: Library (Lib)
messages: 231110
nosy: fhoech
priority: normal
severity: normal
status: open
title: os.walk fails on undecodable filenames
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 13 15:28:38 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2014 14:28:38 +0000
Subject: [New-bugs-announce] [issue22863] https://docs.python.org/ should
	make a true 2.7.8	version available
Message-ID: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The documentation shown for Python 2.7.8 currently includes 2.7.9 parts, e.g. for the ssl modules (https://docs.python.org/2.7/library/ssl.html).

Since there were so many changes to the ssl module for 2.7.9 which are not available in 2.7.8, I think it would be good to be able to not only select "2.7.8" from the doc version drop-down, but to also really get that particular version of the documentation, and provide a separate "2.7.9" snapshop as well.

I tried https://docs.python.org/2.7.8/library/ssl.html, but that doesn't seem to exist.

PS: I'm not sure whether this is the right tracker to report this. Feel free to move it elsewhere.

----------
assignee: docs at python
components: Documentation
messages: 231113
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: https://docs.python.org/ should make a true 2.7.8 version available
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 13 18:35:27 2014
From: report at bugs.python.org (Mike Drob)
Date: Thu, 13 Nov 2014 17:35:27 +0000
Subject: [New-bugs-announce] [issue22864] Add filter to multiprocessing.Pool
Message-ID: <1415900127.9.0.960876191139.issue22864@psf.upfronthosting.co.za>


New submission from Mike Drob:

Being able to use a pool to easily run 'map' over an iterable is very powerful, but it would also be nice to run 'filter' (or potentially 'ifilter' or 'filter_async', in keeping with the patterns already present).

----------
components: Library (Lib)
messages: 231124
nosy: Mike.Drob
priority: normal
severity: normal
status: open
title: Add filter to multiprocessing.Pool
type: enhancement
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Thu Nov 13 19:01:26 2014
From: report at bugs.python.org (Geoff Shannon)
Date: Thu, 13 Nov 2014 18:01:26 +0000
Subject: [New-bugs-announce] [issue22865] Allow pty.spawn to ignore data to
	copy
Message-ID: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>


New submission from Geoff Shannon:

While using the pty.py module I had cause to want to be able to silently eat characters from the input stream.  I discovered that because of the check for end of file being "if not data" that there was no way to do this.

Since the default function used by spawn and _copy is a thin wrapper on os.read, I figured that it would be useful to interpret None as a sentinel value meaning "this is not EOF, but there's nothing I actually want to copy over."

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: pty.patch
keywords: patch
messages: 231126
nosy: RadicalZephyr, docs at python
priority: normal
severity: normal
status: open
title: Allow pty.spawn to ignore data to copy
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37189/pty.patch

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

From report at bugs.python.org  Thu Nov 13 19:59:19 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2014 18:59:19 +0000
Subject: [New-bugs-announce] [issue22866] ssl module in 2.7.9 should provide
	a way to configure	default context options
Message-ID: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

With the backport of the Python 3 ssl module, the default context options of the ssl module were changed.

While this provides better security in many cases, it also causes breakage with servers or clients which do not support TLSv1 and later.

The ssl module should provide a way to globally set the default context options to work around this to allow e.g. removing the OP_NO_SSLv3 option in order to get things to work again without having to change the application using the ssl module.

----------
components: Library (Lib)
messages: 231133
nosy: lemburg
priority: normal
severity: normal
status: open
title: ssl module in 2.7.9 should provide a way to configure default context options
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 13 21:52:37 2014
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Nov 2014 20:52:37 +0000
Subject: [New-bugs-announce] [issue22867] document behavior of calling
	atexit.register() while	atexit._run_exitfuncs is running
Message-ID: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

A discussion on comp.lang.python about prettying up the "if __name__ == 'main__'" idiom led to a suggestion that a decorator could simple register the main function using atexit.register. That looks like it will work, but leaves open the possibility that while main() is running via atexit._run_exitfuncs, other exit functions might be registered.

As currently defined (at least in the Python version with 2.7), I think everything will work fine. Still, the behavior of adding new exit functions during exit is not defined. Would be kind of nice if this behavior was blessed, and then mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 231135
nosy: docs at python, skip.montanaro
priority: low
severity: normal
status: open
title: document behavior of calling atexit.register() while atexit._run_exitfuncs is running

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

From report at bugs.python.org  Fri Nov 14 07:34:23 2014
From: report at bugs.python.org (Yi Bai)
Date: Fri, 14 Nov 2014 06:34:23 +0000
Subject: [New-bugs-announce] [issue22868] Minor error in the example of
	filter()
Message-ID: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>


New submission from Yi Bai:

Hi, I suppose there is a minor error in the example of the filter() function in 5.1.3 part of the document.

------------------------------------------------------------------
filter(function, sequence) returns a sequence consisting of those items from the sequence for which function(item) is true. If sequence is a string or tuple, the result will be of the same type; otherwise, it is always a list. For example, to compute a sequence of numbers not divisible by 2 or 3:

>>>
>>> def f(x): return x % 2 != 0 and x % 3 != 0
...
>>> filter(f, range(2, 25))
[5, 7, 11, 13, 17, 19, 23]
------------------------------------------------------------------

I think what the example does is "to compute a sequence of numbers not divisible by 2 and 3", not "2 or 3".

----------
assignee: docs at python
components: Documentation
messages: 231149
nosy: docs at python, enchyisle
priority: normal
severity: normal
status: open
title: Minor error in the example of filter()
type: resource usage

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

From report at bugs.python.org  Fri Nov 14 12:18:41 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Nov 2014 11:18:41 +0000
Subject: [New-bugs-announce] [issue22869] Split pylifecycle.c out from
	pythonrun.c
Message-ID: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

When working on the original reference implementation for PEP 432, I found it useful to split the startup & shutdown code out from the main entry points into the eval loop (see issue 22257 for more details).

However, that split made the draft implementation rather hard to maintain - any CPython commit that touched pythonrun.c was almost certain to cause a merge conflict.

The attached patch is a preliminary split into two separate modules, with pythonrun continuing to hold the main eval loop entry points, while the startup and shutdown code moves into pylifecycle.

This is an initial WIP patch (that nonetheless passes the test suite). I started work on it a few months ago, so I need to make sure that I've retained Victor's recent pythonrun changes.

----------
assignee: ncoghlan
files: split_pythonrun.diff
keywords: patch
messages: 231155
nosy: ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Split pylifecycle.c out from pythonrun.c
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37194/split_pythonrun.diff

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

From report at bugs.python.org  Fri Nov 14 15:11:02 2014
From: report at bugs.python.org (Dave Tian)
Date: Fri, 14 Nov 2014 14:11:02 +0000
Subject: [New-bugs-announce] [issue22870] urlopen timeout failed with SSL
	socket
Message-ID: <1415974262.24.0.550554752923.issue22870@psf.upfronthosting.co.za>


New submission from Dave Tian:

Hi there,

Recent urlopen with timeout did not work. Below is the back trace. After digging into the Python lib, the root cause is found - within the socket.py, self._sock.recv(), under a 'while True' loop, tried to retrieve sth from the under-layer SSL socket. However, the under-layer PySSL_SSLread() neither returned anything useful nor reported an exception, such as timeout. Because of this 'while True' loop, urlopen got stuck. My temp fix is to add timeout within this issued loop of the socket.py. However, there are other similar loops ranging from urllib2, httplib to socket...and I do not think anything wrong with these loops considering the system socket programming practice. Instead, I am thinking if we could add a new timeout value into the socket object. This new timeout starts with the same value as the user-defined timeout but decrease for the same socket operation. For the case I have encountered:

while True:
    some_sock_recv() # decrease the timeout value within the function call

This should guarantee the timeout timely even within the 'while True' loop.


Thanks,
Dave

http://davejingtian.org




>>> obj=urllib2.urlopen(url, timeout=20)
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 410, in open
    response = meth(req, response)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 523, in http_response
    'http', request, response, code, msg, hdrs)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 442, in error
    result = self._call_chain(*args)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 629, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 422, in _open
    '_open', req)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1222, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1187, in do_open
    r = h.getresponse(buffering=True)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1045, in getresponse
    response.begin()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 441, in begin
    self.msg = HTTPMessage(self.fp, 0)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 25, in __init__
    rfc822.Message.__init__(self, fp, seekable)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/rfc822.py", line 108, in __init__
    self.readheaders()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 280, in readheaders
    line = self.fp.readline(_MAXLINE + 1)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 476, in readline
    data = self._sock.recv(self._rbufsize)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 241, in recv
    return self.read(buflen)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 160, in read
    return self._sslobj.read(len)
KeyboardInterrupt
>>>

----------
components: Library (Lib)
messages: 231160
nosy: daveti
priority: normal
severity: normal
status: open
title: urlopen timeout failed with SSL socket
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 14 16:56:01 2014
From: report at bugs.python.org (=?utf-8?q?Santiago_Palacio_G=C3=B3mez?=)
Date: Fri, 14 Nov 2014 15:56:01 +0000
Subject: [New-bugs-announce] [issue22871] datetime documentation incomplete
Message-ID: <1415980561.47.0.0764312378681.issue22871@psf.upfronthosting.co.za>


New submission from Santiago Palacio G?mez:

In the datetime documentation page https://docs.python.org/2/library/datetime.html
In the directive sections, there are a few things that are not documented there. I really don't know all the possible directives, but the few examples I'm aware of, and how they seem to work for me:
%D seems to behave as the default %x (None locale)
%h seems to behave as %b

----------
assignee: docs at python
components: Documentation
messages: 231162
nosy: docs at python, spalac24
priority: normal
severity: normal
status: open
title: datetime documentation incomplete
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 14 18:34:48 2014
From: report at bugs.python.org (Joseph Siddall)
Date: Fri, 14 Nov 2014 17:34:48 +0000
Subject: [New-bugs-announce] [issue22872] multiprocessing.Queue raises
	AssertionError
Message-ID: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>


New submission from Joseph Siddall:

putting something in Queue(multiprocessing.Queue) after closing it raises an AssertionError.
Getting something out of a Queue after closing it raises an OSError.
I expected both scenarios to raise the same exception.


To Reproduce:


>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.close()
>>> q.put("ok")
Traceback (most recent call last):
...
AssertionError


>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.close()
>>> q.get()
Traceback (most recent call last):
...
OSError: handle is closed

----------
components: Library (Lib)
messages: 231164
nosy: Joseph.Siddall
priority: normal
severity: normal
status: open
title: multiprocessing.Queue raises AssertionError
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 14 19:03:26 2014
From: report at bugs.python.org (John Nagle)
Date: Fri, 14 Nov 2014 18:03:26 +0000
Subject: [New-bugs-announce] [issue22873] Re: SSLsocket.getpeercert - return
	ALL the fields of the	certificate.
Message-ID: <1415988206.94.0.332443874226.issue22873@psf.upfronthosting.co.za>


New submission from John Nagle:

In each revision of "getpeercert", a few more fields are returned. Python 3.2 added "issuer" and "notBefore".  Python 3.4 added "crlDistributionPoints", "caIssuers", and OCSP URLS. But some fields
still aren't returned.  I happen to need CertificatePolicies, which is how you distinguish DV, OV, and EV certs.

   Here's what you get now from "getpeercert()" for "bankofamerica.com":

{'OCSP': ('http://EVSecure-ocsp.verisign.com',),
 'caIssuers': ('http://EVSecure-aia.verisign.com/EVSecure2006.cer',),
 'crlDistributionPoints':
('http://EVSecure-crl.verisign.com/EVSecure2006.crl',),
 'issuer': ((('countryName', 'US'),),
            (('organizationName', 'VeriSign, Inc.'),),
            (('organizationalUnitName', 'VeriSign Trust Network'),),
            (('organizationalUnitName',
              'Terms of use at https://www.verisign.com/rpa (c)06'),),
            (('commonName', 'VeriSign Class 3 Extended Validation SSL
CA'),)),
 'notAfter': 'Mar 22 23:59:59 2015 GMT',
 'notBefore': 'Feb 20 00:00:00 2014 GMT',
 'serialNumber': '69A7BC85C106DDE1CF4FA47D5ED813DC',
 'subject': ((('1.3.6.1.4.1.311.60.2.1.3', 'US'),),
             (('1.3.6.1.4.1.311.60.2.1.2', 'Delaware'),),
             (('businessCategory', 'Private Organization'),),
             (('serialNumber', '2927442'),),
             (('countryName', 'US'),),
             (('postalCode', '60603'),),
             (('stateOrProvinceName', 'Illinois'),),
             (('localityName', 'Chicago'),),
             (('streetAddress', '135 S La Salle St'),),
             (('organizationName', 'Bank of America Corporation'),),
             (('organizationalUnitName', 'Network Infrastructure'),),
             (('commonName', 'www.bankofamerica.com'),)),
 'subjectAltName': (('DNS', 'mobile.bankofamerica.com'),
                    ('DNS', 'www.bankofamerica.com')),
 'version': 3}

Missing fields (from Firefox's view of the cert) include:

 Certificate Policies:
    2.16.840.1.113733.1.7.23.6:
    Extended Validation (EV) SSL Server Certificate
    Certification Practice Statement pointer: https://www.verisign.com/cps
    (This tells you it's a valid EV cert).

 Certificate Basic Constraints:
    Is not a Certificate Authority
    (which means they can't issue more certs below this one)

 Extended Key Usage:
    TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
    (which means this cert is for web use, not email or code signing)

   How about just returning ALL the remaining fields and finishing the job, so this doesn't have to be fixed again?  Thanks.

----------
components: Library (Lib)
messages: 231166
nosy: nagle
priority: normal
severity: normal
status: open
title: Re: SSLsocket.getpeercert - return ALL the fields of the certificate.
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 14 19:52:51 2014
From: report at bugs.python.org (Jens Bonerz)
Date: Fri, 14 Nov 2014 18:52:51 +0000
Subject: [New-bugs-announce] [issue22874] gzip bug in python 2.7.3?
Message-ID: <1415991171.51.0.828444620697.issue22874@psf.upfronthosting.co.za>


New submission from Jens Bonerz:

I am getting the "Not a gzipped file" exception while retrieving a gzipped sitemap xml (tested on amazon.de) using scrapy-

I am using Python 2.7.3 and Scrapy 0.24.4

Can anyone confirm gzip being broken in 2.7.3 or am I overseeing something?

----------
messages: 231167
nosy: jbonerz
priority: normal
severity: normal
status: open
title: gzip bug in python 2.7.3?

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

From report at bugs.python.org  Fri Nov 14 21:01:44 2014
From: report at bugs.python.org (Corbin Simpson)
Date: Fri, 14 Nov 2014 20:01:44 +0000
Subject: [New-bugs-announce] [issue22875] asyncio: call_soon() documentation
	unclear on timing
Message-ID: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za>


New submission from Corbin Simpson:

Hi there!

While assisting somebody on #python (where manners go to die), I was consulting asyncio's documentation. Given my unfamiliarity with asyncio, I was surprised to read BaseEventLoop.call_soon()'s documented behavior: "Arrange for a callback to be called as soon as possible." [1]

The question in mind is whether call_soon() waits for control to return to the event loop before calling the first callback in the queue. After all, given the documented behavior, it would not be unreasonable for call_soon() to always call callbacks immediately if no other callbacks were enqueued. I can imagine scenarios where a previous queued callback from e.g. call_soon_threadsafe() creates a callback that causes queueing behavior, but otherwise I would expect "as soon as possible" to mean "immediately".

It's true that in other event loops, this kind of callback registration waits for control to return to the event loop before running callbacks. However, many event loops that I've worked with indicate that call_later() is the correct API for adding callbacks that respect the event loop. In fact, call_later(0, callback, args) looks quite a bit like the familiar Twisted callLater(0, callback, args) pattern!

Additionally, there is no indication as to whether call_later() and call_soon() use the same queue.

I'd like clarification on these points in the Python 3 documentation, please. I'd like to know whether call_soon() can be immediate, and whether call_soon() preempts or interleaves with call_later().

(Yes, I know that Twisted's documentation is missing this too [2] [3]. I'll get to that soon enough.)

Thanks!
~ C.

[1]: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.BaseEventLoop.call_soon
[2]: http://twistedmatrix.com/documents/current/core/howto/time.html
[3]: http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorTime.html#callLater

----------
assignee: docs at python
components: Documentation, asyncio
messages: 231180
nosy: Corbin.Simpson, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: call_soon() documentation unclear on timing

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

From report at bugs.python.org  Sat Nov 15 00:04:39 2014
From: report at bugs.python.org (=?utf-8?b?0JLRj9GH0LXRgdC70LDQsg==?=)
Date: Fri, 14 Nov 2014 23:04:39 +0000
Subject: [New-bugs-announce] [issue22876] ip_interface can't be broadcast or
	number net
Message-ID: <1416006279.81.0.519383072112.issue22876@psf.upfronthosting.co.za>


New submission from ????????:

ip_interface can't be network or broadcast address. Probably should throw an exception in such cases

>>> ip_interface(u'192.168.1.0/25')
IPv4Interface(u'192.168.1.0/25')

>>> ip_interface(u'192.168.1.127/25')
IPv4Interface(u'192.168.1.127/25')

----------
components: Library (Lib)
messages: 231194
nosy: m01, ncoghlan, pmoody, python-dev, ????????
priority: normal
severity: normal
status: open
title: ip_interface can't be broadcast or number net
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 15 01:37:53 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Nov 2014 00:37:53 +0000
Subject: [New-bugs-announce] [issue22877] Backport ensurepip OS X installer
	changes to 2.7
Message-ID: <1416011873.01.0.449505301974.issue22877@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee: ned.deily
components: Installation, Macintosh
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Backport ensurepip OS X installer changes to 2.7
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 15 09:15:11 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Nov 2014 08:15:11 +0000
Subject: [New-bugs-announce] [issue22878] PEP 477 (ensurepip backport to
	2.7.9): "make install"	and "make altinstall" integration
Message-ID: <1416039311.77.0.37210420462.issue22878@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee: ned.deily
components: Build
nosy: ned.deily
priority: normal
severity: normal
status: open
title: PEP 477 (ensurepip backport to 2.7.9): "make install" and "make altinstall" integration
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 15 23:47:49 2014
From: report at bugs.python.org (Brecht Machiels)
Date: Sat, 15 Nov 2014 22:47:49 +0000
Subject: [New-bugs-announce] [issue22879] Make set's add and discard methods
	return useful	information
Message-ID: <1416091669.05.0.557383072226.issue22879@psf.upfronthosting.co.za>


New submission from Brecht Machiels:

set's add() method would be a little bit more useful if it would return True if the added value was already present in the set, and False if it wasn't (or the other way around). Similarly, discard() could report whether the discarded value was present in the set or not.

I suppose this could cost a couple of extra cycles and I'm not sure this is acceptable. For discard() there's always remove() that offers similar behavior. add() does not have an alternative that offers check-and-add behavior.

----------
components: Library (Lib)
messages: 231226
nosy: brechtm
priority: normal
severity: normal
status: open
title: Make set's add and discard methods return useful information
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Nov 16 04:25:58 2014
From: report at bugs.python.org (Roy Smith)
Date: Sun, 16 Nov 2014 03:25:58 +0000
Subject: [New-bugs-announce] [issue22880] hmac.new docs show optional args
	incorrectly
Message-ID: <1416108358.14.0.735594371986.issue22880@psf.upfronthosting.co.za>


New submission from Roy Smith:

At https://docs.python.org/2/library/hmac.html, hmac.new() is shown as

hmac.new(key[, msg[, digestmod]])

This implies that digestmod can only be given if msg is given.  This is incorrect.  Either can be given without the other.

----------
assignee: docs at python
components: Documentation
messages: 231231
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: hmac.new docs show optional args incorrectly
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 16 10:50:17 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 16 Nov 2014 09:50:17 +0000
Subject: [New-bugs-announce] [issue22881] show median in benchmark results
Message-ID: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The median tends to give a better idea about benchmark results than an average as it inherently ignores outliers.

----------
components: Benchmarks
files: show_median.patch
keywords: patch
messages: 231239
nosy: pitrou, scoder
priority: normal
severity: normal
status: open
title: show median in benchmark results
type: enhancement
Added file: http://bugs.python.org/file37206/show_median.patch

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

From report at bugs.python.org  Sun Nov 16 14:07:50 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Sun, 16 Nov 2014 13:07:50 +0000
Subject: [New-bugs-announce] [issue22882] [patch] Linux packages you need to
	compile Python with	all dependencies
Message-ID: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>


New submission from Ludovic Gasc:

Hi,

To install easily Python 3.4.2 on Linux, I use Pythonz: http://saghul.github.io/pythonz/

I've discovered that, depends on the packages already installed on Linux, I don't have the same Python each time after compilation on servers.
Some features could missing, like pip, if you don't install some packages.

I've made a pull request in Pythonz with the list of packages you need to avoid that: https://github.com/saghul/pythonz#before-installing-pythons-via-pythonz

But, for me, this packages list should be in official Python documentation directly.

I've tested this packages list on Debian (Squeeze, Wheezy, Jessie, Sid), Ubuntu (12.04, 14.04) and CentOS 6.

Thanks for the merge.

Regards.

----------
assignee: docs at python
components: Documentation
files: build_dep_python.patch
keywords: patch
messages: 231245
nosy: Ludovic.Gasc, docs at python
priority: normal
severity: normal
status: open
title: [patch] Linux packages you need to compile Python with all dependencies
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37208/build_dep_python.patch

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

From report at bugs.python.org  Sun Nov 16 15:12:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 14:12:26 +0000
Subject: [New-bugs-announce] [issue22883] Get rid of references to PyInt in
	Py3 sources
Message-ID: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are several references to PyInt in outdated comments in .c and .h files:

$ find * -name '*.[ch]' -exec egrep -n --color -- 'PyInt\b' '{}' +
Include/longobject.h:34:/* It may be useful in the future. I've added it in the PyInt -> PyLong
Modules/fcntlmodule.c:157:       into either a large positive number (PyLong or PyInt on 64-bit
Modules/fcntlmodule.c:158:       platforms) or a negative number on others (32-bit PyInt)
Modules/_json.c:813:        PyInt, PyLong, or PyFloat.
Modules/itertoolsmodule.c:3869:    assert(cnt != PY_SSIZE_T_MAX && long_cnt == NULL && long_step==PyInt(1));
Python/ceval.c:4606:/* Extract a slice index from a PyInt or PyLong or an object with the

----------
components: Extension Modules, Interpreter Core
messages: 231246
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Get rid of references to PyInt in Py3 sources
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov 16 15:58:06 2014
From: report at bugs.python.org (Kevin Orr)
Date: Sun, 16 Nov 2014 14:58:06 +0000
Subject: [New-bugs-announce] [issue22884] argparse.FileType.__call__ returns
	unwrapped sys.stdin	and stdout
Message-ID: <1416149886.65.0.378402881729.issue22884@psf.upfronthosting.co.za>


New submission from Kevin Orr:

When one uses a file object returned by `FileType.__call__` as a context manager, `sys.stdin`'s or `sys.stdout`'s `__exit__` will be triggered upon exit of the context, in turn calling their `close` method.

Perhaps the issue is that `sys.stdin` and `sys.stdout` have poor `__exit__` methods, but my proposal (and it's not a particularly clean one) is to override the file object's `__exit__` if it happens to be either `sys.stdin` or `sys.stdout` to simply return True when called.

----------
components: Library (Lib)
messages: 231249
nosy: keviv
priority: normal
severity: normal
status: open
title: argparse.FileType.__call__ returns unwrapped sys.stdin and stdout
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Sun Nov 16 19:39:01 2014
From: report at bugs.python.org (Stephen Farris)
Date: Sun, 16 Nov 2014 18:39:01 +0000
Subject: [New-bugs-announce] [issue22885] Arbitrary code execution
	vulnerability due to unchecked	eval() call in dumbdbm module
Message-ID: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za>


New submission from Stephen Farris:

The dumbdbm module uses an unchecked call to eval() in the _update method, which is called in response to a call to dumbdbm.open(), and is used to load the index from the directory file.? This poses a security vulnerability because it allows an attacker to execute arbitrary code on the victim's machine by inserting python code into the DBM directory file.? This vulnerability could allow an attacker to execute arbitrary commands on the victim machine, potentially allowing them to deploy malware, gain system access, destroy files and data, expose sensitive information, etc.

----------
components: Library (Lib)
messages: 231255
nosy: Guido.van.Rossum, lemburg, stephen.farris
priority: normal
severity: normal
status: open
title: Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
type: security
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 17 01:34:33 2014
From: report at bugs.python.org (Robert Collins)
Date: Mon, 17 Nov 2014 00:34:33 +0000
Subject: [New-bugs-announce] [issue22886] TestProgram leaves
	defaultTestLoader.errors dirty
Message-ID: <1416184473.93.0.181686669268.issue22886@psf.upfronthosting.co.za>


New submission from Robert Collins:

TestProgram leaves defaultTestLoader.errors dirty. This primarily affects tests but it would be good hygiene to clear it at the end of TestProgram.

----------
components: Library (Lib)
messages: 231261
nosy: rbcollins
priority: normal
severity: normal
status: open
title: TestProgram leaves defaultTestLoader.errors dirty
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 17 03:03:24 2014
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Alberto_Goncalves?=)
Date: Mon, 17 Nov 2014 02:03:24 +0000
Subject: [New-bugs-announce] [issue22887] ensurepip and distutils'
	build_scripts fails on Windows	when path to Python contains
	accented characters
Message-ID: <1416189804.36.0.639606237849.issue22887@psf.upfronthosting.co.za>


New submission from Jos? Alberto Goncalves:

Summary:

Python 3.4's venv works fine in Windows, and pip works fine when installing both pure Python libraries and extension modules. However, when the virtual environment is under a path with non-ASCII characters, attempting to install a package that specifies console_scripts or scripts (like pip or mutagen, respectivelly), it fails with encoding errors.

I looked around the Internet for a solution but the best I could find was Issue #10419, which is over 3 years old and is marked as resolved, and couldn't find any other open issue about this.

Details of my case:

I created a Python 3.4 (32-bit) virtualenv via Python Tools for Visual Studio, on windows 8.1 (64-bit), in a folder that is under my home directory (C:\Users\Jos? Alberto\), which happens to contain an accented character, using the latest Python you can download from the homepage.

Via Powershell I activated the virtualenv and tried to execute pip install mutagen (https://pypi.python.org/pypi/mutagen, it is relevant because it specifies scripts in its setup.py). The installation failed with the following error:

Downloading/unpacking mutagen
  Running setup.py (path:C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py) egg_info for
package mutagen

Installing collected packages: mutagen
  Running setup.py install for mutagen
    Traceback (most recent call last):
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 114, in copy_scripts
        shebang.decode('utf-8')
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 14: invalid continuation byte

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py", line 277, in <module>
        """
      File "C:\Python34\lib\distutils\core.py", line 148, in setup
        dist.run_commands()
      File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands
        self.run_command(cmd)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\lib\site-packages\setuptools-6.0.2-py3.4.egg\setuptools\command\install.py", line 61, in run
      File "C:\Python34\lib\distutils\command\install.py", line 539, in run
        self.run_command('build')
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build.py", line 126, in run
        self.run_command(cmd_name)
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 50, in run
        self.copy_scripts()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 118, in copy_scripts
        "from utf-8".format(shebang))
    ValueError: The shebang (b'#!C:\\Users\\Jos\xe9 Alberto\\Documents\\podtimizer\\env_podtimizer\\Scripts\\python.exe\n') is not decodable from utf-8

I looked around the Internet for a solution, but the best I could find was the Issue #10419, which is over 3 years old and is marked as closed and resolved. The last comment mentions a fix that was commited to Distribute around that time, with the caveat that entry points script creation would fail if the path contained unencodeable characters (which sounds exactly like the problem I'm having). I Couldn't find an open issue to follow up on this.

I went to the source of the error, around Lib/distutils/command/build_scripts.py:106. Since this is Windows, the result of os.fsencode() uses the encoding 'mbcs' (as reported by Python), then it tries to decode it back using utf-8, and it blows up:

>>> import os
>>> os.fsencode('C:\\Users\\Jos? Alberto\\')
b'C:\\Users\\Jos\xe9 Alberto\\'
>>> 'C:\\Users\\Jos? Alberto\\'.encode('utf-8')
b'C:\\Users\\Jos\xc3\xa9 Alberto\\'

I commented both try..except after the os.fsencode and it worked, but commenting random code whose purpose I don't fully understand doesn't seem like a good strategy.

While testing for the above, I found I couldn't finish installing pip successfully on a virtualenv using just the Python installed from python.org.

On Powershell I created several virtualenvs using C:\Python34\python.exe -m venv. The envs were created successfully, but the pip's console_scripts installation failed silently. I could still run python -m pip and install packages, but the pip.exe files were not created.

I removed pip from the environment's site-packages directory and tried to reinstall it via python -m ensurepip, but instead got the following error:

Installing collected packages: pip
Cleaning up...
  Removing temporary dir C:\Users\Jos? Alberto\test_env3\build...
Exception:
Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 124, in _get_shebang
    shebang.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 15: invalid continuation byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\commands\install.py", line 283, in run
    requirement_set.install(install_options, global_options, root=options.root_path)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 1435, in install
    requirement.install(install_options, global_options, *args, **kwargs)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 671, in install
    self.move_wheel_files(self.source_dir, root=root)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 901, in move_wheel_files
    pycompile=self.pycompile,
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\wheel.py", line 325, in move_wheel_files
    generated.extend(maker.make(spec))
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 311, in make
    self._make_script(entry, filenames, options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 201, in _make_script
    shebang = self._get_shebang('utf-8', options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 127, in _get_shebang
    'The shebang (%r) is not decodable from utf-8' % shebang)
ValueError: The shebang (b'#!"C:\\Users\\Jos\xe9 Alberto\\test_env3\\Scripts\\python.exe"\n') is not decodable from utf-8

Which is exactly the same issue I was running into with build_scripts, but this time in a similar code within ensurepip's pip wheel. This time I tried again to comment the utf-8 encoding checks, and although ensurepip now finished successfully, the executables failed with "Couldn't create process". This is as far as I could go within my very limited understanding of encoding issues and pip, so I decided to write this issue.

Is it possible to fix this? Is there something I can do to help?

----------
components: Distutils, Library (Lib)
messages: 231262
nosy: dstufft, eric.araujo, gmljosea
priority: normal
severity: normal
status: open
title: ensurepip and distutils' build_scripts fails on Windows when path to Python contains accented characters
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 17 03:03:25 2014
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Alberto_Goncalves?=)
Date: Mon, 17 Nov 2014 02:03:25 +0000
Subject: [New-bugs-announce] [issue22888] ensurepip and distutils'
	build_scripts fails on Windows	when path to Python contains
	accented characters
Message-ID: <1416189805.26.0.501870497437.issue22888@psf.upfronthosting.co.za>


New submission from Jos? Alberto Goncalves:

Summary:

Python 3.4's venv works fine in Windows, and pip works fine when installing both pure Python libraries and extension modules. However, when the virtual environment is under a path with non-ASCII characters, attempting to install a package that specifies console_scripts or scripts (like pip or mutagen, respectivelly), it fails with encoding errors.

I looked around the Internet for a solution but the best I could find was Issue #10419, which is over 3 years old and is marked as resolved, and couldn't find any other open issue about this.

Details of my case:

I created a Python 3.4 (32-bit) virtualenv via Python Tools for Visual Studio, on windows 8.1 (64-bit), in a folder that is under my home directory (C:\Users\Jos? Alberto\), which happens to contain an accented character, using the latest Python you can download from the homepage.

Via Powershell I activated the virtualenv and tried to execute pip install mutagen (https://pypi.python.org/pypi/mutagen, it is relevant because it specifies scripts in its setup.py). The installation failed with the following error:

Downloading/unpacking mutagen
  Running setup.py (path:C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py) egg_info for
package mutagen

Installing collected packages: mutagen
  Running setup.py install for mutagen
    Traceback (most recent call last):
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 114, in copy_scripts
        shebang.decode('utf-8')
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 14: invalid continuation byte

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py", line 277, in <module>
        """
      File "C:\Python34\lib\distutils\core.py", line 148, in setup
        dist.run_commands()
      File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands
        self.run_command(cmd)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\lib\site-packages\setuptools-6.0.2-py3.4.egg\setuptools\command\install.py", line 61, in run
      File "C:\Python34\lib\distutils\command\install.py", line 539, in run
        self.run_command('build')
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build.py", line 126, in run
        self.run_command(cmd_name)
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 50, in run
        self.copy_scripts()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 118, in copy_scripts
        "from utf-8".format(shebang))
    ValueError: The shebang (b'#!C:\\Users\\Jos\xe9 Alberto\\Documents\\podtimizer\\env_podtimizer\\Scripts\\python.exe\n') is not decodable from utf-8

I looked around the Internet for a solution, but the best I could find was the Issue #10419, which is over 3 years old and is marked as closed and resolved. The last comment mentions a fix that was commited to Distribute around that time, with the caveat that entry points script creation would fail if the path contained unencodeable characters (which sounds exactly like the problem I'm having). I Couldn't find an open issue to follow up on this.

I went to the source of the error, around Lib/distutils/command/build_scripts.py:106. Since this is Windows, the result of os.fsencode() uses the encoding 'mbcs' (as reported by Python), then it tries to decode it back using utf-8, and it blows up:

>>> import os
>>> os.fsencode('C:\\Users\\Jos? Alberto\\')
b'C:\\Users\\Jos\xe9 Alberto\\'
>>> 'C:\\Users\\Jos? Alberto\\'.encode('utf-8')
b'C:\\Users\\Jos\xc3\xa9 Alberto\\'

I commented both try..except after the os.fsencode and it worked, but commenting random code whose purpose I don't fully understand doesn't seem like a good strategy.

While testing for the above, I found I couldn't finish installing pip successfully on a virtualenv using just the Python installed from python.org.

On Powershell I created several virtualenvs using C:\Python34\python.exe -m venv. The envs were created successfully, but the pip's console_scripts installation failed silently. I could still run python -m pip and install packages, but the pip.exe files were not created.

I removed pip from the environment's site-packages directory and tried to reinstall it via python -m ensurepip, but instead got the following error:

Installing collected packages: pip
Cleaning up...
  Removing temporary dir C:\Users\Jos? Alberto\test_env3\build...
Exception:
Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 124, in _get_shebang
    shebang.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 15: invalid continuation byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\commands\install.py", line 283, in run
    requirement_set.install(install_options, global_options, root=options.root_path)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 1435, in install
    requirement.install(install_options, global_options, *args, **kwargs)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 671, in install
    self.move_wheel_files(self.source_dir, root=root)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 901, in move_wheel_files
    pycompile=self.pycompile,
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\wheel.py", line 325, in move_wheel_files
    generated.extend(maker.make(spec))
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 311, in make
    self._make_script(entry, filenames, options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 201, in _make_script
    shebang = self._get_shebang('utf-8', options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 127, in _get_shebang
    'The shebang (%r) is not decodable from utf-8' % shebang)
ValueError: The shebang (b'#!"C:\\Users\\Jos\xe9 Alberto\\test_env3\\Scripts\\python.exe"\n') is not decodable from utf-8

Which is exactly the same issue I was running into with build_scripts, but this time in a similar code within ensurepip's pip wheel. This time I tried again to comment the utf-8 encoding checks, and although ensurepip now finished successfully, the executables failed with "Couldn't create process". This is as far as I could go within my very limited understanding of encoding issues and pip, so I decided to write this issue.

Is it possible to fix this? Is there something I can do to help?

----------
components: Distutils, Library (Lib)
messages: 231263
nosy: dstufft, eric.araujo, gmljosea
priority: normal
severity: normal
status: open
title: ensurepip and distutils' build_scripts fails on Windows when path to Python contains accented characters
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 17 06:38:20 2014
From: report at bugs.python.org (Kevin Burke)
Date: Mon, 17 Nov 2014 05:38:20 +0000
Subject: [New-bugs-announce] [issue22889] set a timeout for DNS lookups
Message-ID: <1416202700.62.0.764636248133.issue22889@psf.upfronthosting.co.za>


New submission from Kevin Burke:

It would be nice to be able to set a timeout for DNS lookups in the event of a DNS server failure.

1. Set your DNS to something like 123.123.123.123 or any other host that is not listening for DNS queries on port 53.

2. Run requests.get('http://jsonip.com', timeout=3), or similar using urllib/http.client/httplib

3. Observe that the wall clock time is 2 minutes or higher.

It's known that a timeout value does not correspond to wall clock time, but this can be an unexpected cause of latency in http client requests, and is completely uncontrollable from client code (unless the user resolves DNS themselves). 

For a comparison, Go provides this functionality, see for example https://code.google.com/p/go/source/browse/src/pkg/net/lookup.go?name=release#55

----------
components: Library (Lib)
messages: 231266
nosy: kevinburke
priority: normal
severity: normal
status: open
title: set a timeout for DNS lookups
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 17 08:41:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 07:41:25 +0000
Subject: [New-bugs-announce] [issue22890] StringIO.StringIO pickled in 2.7
	is not unpickleable on	3.x
Message-ID: <1416210085.6.0.932097721403.issue22890@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

StringIO.StringIO is pickleable and unpickleable on 2.7 but is not unpickleable on 3.x.

Python 2.7:
>>> import pickle, StringIO
>>> pickle.dumps(StringIO.StringIO('abc'), 2)
'\x80\x02(cStringIO\nStringIO\nq\x00oq\x01}q\x02(U\tsoftspaceq\x03K\x00U\x07buflistq\x04]q\x05U\x03posq\x06K\x00U\x03lenq\x07K\x03U\x06closedq\x08\x89U\x03bufq\tU\x03abcq\nub.'
>>> pickle.loads(b'\x80\x02(cStringIO\nStringIO\nq\x00oq\x01}q\x02(U\tsoftspaceq\x03K\x00U\x07buflistq\x04]q\x05U\x03posq\x06K\x00U\x03lenq\x07K\x03U\x06closedq\x08\x89U\x03bufq\tU\x03abcq\nub.')
<StringIO.StringIO instance at 0xb70c122c>

On 3.x I got an error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: _io.StringIO.__setstate__ argument should be 4-tuple, got dict

----------
components: Library (Lib)
messages: 231268
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov 17 11:42:24 2014
From: report at bugs.python.org (Alexander Todorov)
Date: Mon, 17 Nov 2014 10:42:24 +0000
Subject: [New-bugs-announce] [issue22891] [patch]: code removal from
	urllib.parse.urlsplit()
Message-ID: <1416220944.83.0.361625539874.issue22891@psf.upfronthosting.co.za>


New submission from Alexander Todorov:

In the urllib.parse (or urlparse on Python 2.X) module there is this function:

    157 def urlsplit(url, scheme='', allow_fragments=True):
    158     """Parse a URL into 5 components:
    159     <scheme>://<netloc>/<path>?<query>#<fragment>
    160     Return a 5-tuple: (scheme, netloc, path, query, fragment).
    161     Note that we don't break the components up in smaller bits
    162     (e.g. netloc is a single string) and we don't expand % escapes."""
    163     allow_fragments = bool(allow_fragments)
    164     key = url, scheme, allow_fragments, type(url), type(scheme)
    165     cached = _parse_cache.get(key, None)
    166     if cached:
    167         return cached
    168     if len(_parse_cache) >= MAX_CACHE_SIZE: # avoid runaway growth
    169         clear_cache()
    170     netloc = query = fragment = ''
    171     i = url.find(':')
    172     if i > 0:
    173         if url[:i] == 'http': # optimize the common case
    174             scheme = url[:i].lower()
    175             url = url[i+1:]
    176             if url[:2] == '//':
    177                 netloc, url = _splitnetloc(url, 2)
    178             if allow_fragments and '#' in url:
    179                 url, fragment = url.split('#', 1)
    180             if '?' in url:
    181                 url, query = url.split('?', 1)
    182             v = SplitResult(scheme, netloc, url, query, fragment)
    183             _parse_cache[key] = v
    184             return v
    185         for c in url[:i]:
    186             if c not in scheme_chars:
    187                 break
    188         else:
    189             scheme, url = url[:i].lower(), url[i+1:]
    190 
    191     if url[:2] == '//':
    192         netloc, url = _splitnetloc(url, 2)
    193     if allow_fragments and '#' in url:
    194         url, fragment = url.split('#', 1)
    195     if '?' in url:
    196         url, query = url.split('?', 1)
    197     v = SplitResult(scheme, netloc, url, query, fragment)
    198     _parse_cache[key] = v
    199     return v



There is an issue here (or a few of them) as follows:

* if url[:1] is already lowercase (equals "http") (line 173) then .lower() on  line 174 is reduntant:
174    scheme = url[:i].lower() # <--- no need for .lower() b/c value is "http"


* OTOH line 173 could refactor the condition and match URLs where the scheme is uppercase. For example
    173         if url[:i].lower() == 'http': # optimize the common case

* The code as is returns the same results (as far as I've tested it) for both:
urlsplit("http://github.com/atodorov/repo.git?param=value#myfragment")
urlsplit("HTTP://github.com/atodorov/repo.git?param=value#myfragment")
urlsplit("HTtP://github.com/atodorov/repo.git?param=value#myfragment")

but the last 2 invocations also go through lines 185-199


* Lines 174-184 are essentially the same as lines 189-199. The only optimization I can see is avoiding the for loop around lines 185-187 which checks for valid characters in the URL scheme and executes only a few loops b/c scheme names are quite short usually.


My personal vote goes for removal of lines 173-184. 


Version-Release number of selected component (if applicable):

This is present in both Python 3 and Python 2 on all versions I have access to:

python3-libs-3.4.1-16.fc21.x86_64.rpm
python-libs-2.7.8-5.fc21.x86_64.rpm
python-libs-2.7.5-16.el7.x86_64.rpm
python-libs-2.6.6-52.el6.x86_64

Versions are from Fedora Rawhide and RHEL. Also the same code is present in the Mercurial repository.

Bug first reported as
https://bugzilla.redhat.com/show_bug.cgi?id=1160603

and now filing here for upstream consideration.

----------
components: Library (Lib)
files: urlparse_refactor.patch
keywords: patch
messages: 231278
nosy: Alexander.Todorov
priority: normal
severity: normal
status: open
title: [patch]: code removal from urllib.parse.urlsplit()
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37212/urlparse_refactor.patch

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

From report at bugs.python.org  Mon Nov 17 16:37:18 2014
From: report at bugs.python.org (Martin Gignac)
Date: Mon, 17 Nov 2014 15:37:18 +0000
Subject: [New-bugs-announce] [issue22892] Typo in Library's 'threading'
	module section
Message-ID: <1416238638.39.0.769056339447.issue22892@psf.upfronthosting.co.za>


New submission from Martin Gignac:

There is an extraenous asterisk in the constructor description for class 'threading.Thread' in section 17.1.2. "Thread Objects" of the 'threading' module in the Python Standard Library documenation.

(patch attached)

----------
assignee: docs at python
components: Documentation
files: threading.rst.patch
keywords: patch
messages: 231284
nosy: docs at python, techstone
priority: normal
severity: normal
status: open
title: Typo in Library's 'threading' module section
versions: Python 3.4
Added file: http://bugs.python.org/file37214/threading.rst.patch

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

From report at bugs.python.org  Mon Nov 17 23:02:57 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Nov 2014 22:02:57 +0000
Subject: [New-bugs-announce] [issue22893] Idle: __future__ does not work in
	startup code.
Message-ID: <1416261777.24.0.465929106454.issue22893@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://stackoverflow.com/questions/26977236/how-can-i-use-future-division-in-the-idle-startup-file report what seems like possibly fixable perhaps buggy behavior with respect to __future__ imports.  More investigation is needed.

Any change here might interact with #5233 IDLE: exec IDLESTARTUP/PYTHONSTARTUP on restart

----------
messages: 231304
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: __future__ does not work in startup code.
type: behavior

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

From report at bugs.python.org  Mon Nov 17 23:18:09 2014
From: report at bugs.python.org (Trey Cucco)
Date: Mon, 17 Nov 2014 22:18:09 +0000
Subject: [New-bugs-announce] [issue22894] unittest.TestCase.subTest causes
	all subsequent tests to	be skipped in failfast mode
Message-ID: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>


New submission from Trey Cucco:

When running a test suite with the -f flag (--failfast), unittest seems to stop running tests once it exits a with self.subTest block.

In the attached script, run it without -f and test_b will run and fail. Run it with the -f flag and only the test_a test will run. test_b will not run and no errors will be reported.

I noticed this bug in 3.4.1 on OS X

----------
components: Macintosh, Tests
files: utbug.py
messages: 231305
nosy: Trey.Cucco, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: unittest.TestCase.subTest causes all subsequent tests to be skipped in failfast mode
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37218/utbug.py

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

From report at bugs.python.org  Tue Nov 18 13:03:32 2014
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 18 Nov 2014 12:03:32 +0000
Subject: [New-bugs-announce] [issue22895] regression introduced by the fix
	for issue #22462
Message-ID: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the fix for issue #22462 introduces a regression in the test_pyexpat test cases. I'm not yet sure why. This is only seen when running the testsuite from the installed location, which shouldn't matter.  Tried to run the tests with a stripped executable in the build tree worked too, so I'm lost why this now fails.  Confirmed that reverting the fix resolves running the testcase in the same environment.

----------
components: Library (Lib)
messages: 231312
nosy: doko, pitrou
priority: high
severity: normal
status: open
title: regression introduced by the fix for issue #22462
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Nov 18 15:02:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 14:02:55 +0000
Subject: [New-bugs-announce] [issue22896] Don't use PyObject_As*Buffer()
	functions
Message-ID: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyObject_AsCharBuffer(), PyObject_AsReadBuffer() and PyObject_AsWriteBuffer() release the buffer right after acquiring and return a pointer to released buffer. This is not safe and could cause issues sooner or later. These functions shouldn't be used in the stdlib at all.

----------
assignee: serhiy.storchaka
components: Extension Modules, Interpreter Core
messages: 231323
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't use PyObject_As*Buffer() functions
type: resource usage
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Nov 18 20:09:04 2014
From: report at bugs.python.org (Boris)
Date: Tue, 18 Nov 2014 19:09:04 +0000
Subject: [New-bugs-announce] [issue22897] IDLE - MacOS: freeze on non-ASCII
	save with open debugger
Message-ID: <1416337744.39.0.177828041669.issue22897@psf.upfronthosting.co.za>


New submission from Boris:

When attempting to save a file containing an &Aring; character with the debugger open, IDLE freezes with/or without partially opening the warning window. (Mac OS X 10.9.5, IDLE running python 2.7.5). Reproducible steps:

- Create and save file with one line:
1+1  # A
- Open IDLE
- Open the debugger
- Open the file
- Delete the "A", type <shift><alt>A
- type <command>s to save. This triggers the problem.

Application hangs ("not responding") and needs to force quit. Sometimes the graphics memory of other applications gets corrupted.

----------
components: IDLE
messages: 231338
nosy: steipe
priority: normal
severity: normal
status: open
title: IDLE - MacOS: freeze on non-ASCII save with open debugger
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov 18 22:26:16 2014
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 18 Nov 2014 21:26:16 +0000
Subject: [New-bugs-announce] [issue22898] segfault during shutdown
	attempting to log	ResourceWarning
Message-ID: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>


New submission from A. Jesse Jiryu Davis:

Running a unittest suite for Motor, my MongoDB driver which uses PyMongo, greenlet, and Tornado. The suite commonly segfaults during interpreter shutdown. I've reproduced this crash with Python 3.3.5, 3.4.1, and 3.4.2. Python 2.6 and 2.7 do *not* crash. The Python interpreters are all built like:

./configure --prefix=/mnt/jenkins/languages/python/rX.Y.Z --enable-shared && make && make install

This is Amazon Linux AMI release 2014.09.

The unittest suite's final output is:

----------------------------------------------------------------------
Ran 15 tests in 265.947s

OK
Segmentation fault (core dumped)

Backtrace from a Python 3.4.2 coredump attached.

----------
components: Interpreter Core
files: dump.txt
messages: 231345
nosy: emptysquare
priority: normal
severity: normal
status: open
title: segfault during shutdown attempting to log ResourceWarning
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file37224/dump.txt

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

From report at bugs.python.org  Wed Nov 19 00:16:37 2014
From: report at bugs.python.org (Ryan Chartier)
Date: Tue, 18 Nov 2014 23:16:37 +0000
Subject: [New-bugs-announce] [issue22899]
	http.server.BaseHTTPRequestHandler.parse_request	(TypeError:
	decoding str is not supported)
Message-ID: <1416352597.9.0.2072492328.issue22899@psf.upfronthosting.co.za>


New submission from Ryan Chartier:

While the parse_request is handling the requestline, it tries to force the string into iso-8859-1 using an unsupported syntax.

Line #274 in server.py

requestline = str(self.raw_requestline, 'iso-8859-1')

Obviously, python complains.

TypeError: decoding str is not supported

I'm running python 3.4.2 and the line is present in the 3.4.2 source I downloaded from the python.org today.

That is all.

----------
messages: 231350
nosy: recharti
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler.parse_request (TypeError: decoding str is not supported)
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 19 12:51:39 2014
From: report at bugs.python.org (=?utf-8?q?Jure_Erzno=C5=BEnik?=)
Date: Wed, 19 Nov 2014 11:51:39 +0000
Subject: [New-bugs-announce] [issue22900] decimal.Context Emin,
	Emax limits restrict functionality without adding benefits
Message-ID: <1416397899.98.0.98334629396.issue22900@psf.upfronthosting.co.za>


New submission from Jure Erzno?nik:

At some point since Python 2.7, the EMin, Emax members got more restrictive bounds. Emin cannot go above 0 and Emax cannot go below 0.

I would argue against this logic:
.prec specifies total precision
.Emin and .Emax effectively limit possible locations of decimal point within the given precision. Since they don't specify / enforce EXACT position of the decimal point, what's the point of limiting them?

Without restrictions, setting Emin = Emax = some positive number effectively restricts number of decimal places to exactly that positive number without a need for separate (and expensive) .quantize() calls.

Removing this restriction provides an option to use decimal as true fixed-point arithmetic.

----------
components: Extension Modules
messages: 231374
nosy: Jure.Erzno?nik
priority: normal
severity: normal
status: open
title: decimal.Context Emin, Emax limits restrict functionality without adding benefits
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 19 16:00:25 2014
From: report at bugs.python.org (bru)
Date: Wed, 19 Nov 2014 15:00:25 +0000
Subject: [New-bugs-announce] [issue22901] test.test_uuid.test_find_mac fails
	because of `ifconfig`	deprecation
Message-ID: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>


New submission from bru:

`test.test_uuid.test_find_mac` relies on `ifconfig` binary presence, which is on its way out. This makes the test fail on more and more Linux installations.
Using `env` (for example) is more reliable. `ip` could also be used since it's the replacement to `ifconfig`, but an always-present binary such as `env` makes it work in all cases.
This is what the (trivial) patch does.

The same reasoning applies to `uuid.getnode`: if 'Unix dll' source is not available it will try to get a MAC address 'ifconfig' which will fail, and the fallback will be `_random_getnode` (but that's another issue).

----------
components: Tests
files: fix_uuid_find_mac_test.patch
keywords: patch
messages: 231380
nosy: bru
priority: normal
severity: normal
status: open
title: test.test_uuid.test_find_mac fails because of `ifconfig` deprecation
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37227/fix_uuid_find_mac_test.patch

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

From report at bugs.python.org  Wed Nov 19 16:16:34 2014
From: report at bugs.python.org (bru)
Date: Wed, 19 Nov 2014 15:16:34 +0000
Subject: [New-bugs-announce] [issue22902] Use 'ip' for uuid.getnode()
Message-ID: <1416410194.76.0.0246920486937.issue22902@psf.upfronthosting.co.za>


New submission from bru:

Only linux, `uuid.getnode()` will use the Unix ddl, then ifconfig, then random. `ifconfig` is disappearing in favour of `ip` (from iproute2), which should be used.
This patch ads `_ip_getnode` getter to `uuid.getnode()`

----------
components: Library (Lib)
files: uuid_find_mac_with_ip.patch
keywords: patch
messages: 231382
nosy: bru
priority: normal
severity: normal
status: open
title: Use 'ip' for uuid.getnode()
versions: Python 3.4
Added file: http://bugs.python.org/file37228/uuid_find_mac_with_ip.patch

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

From report at bugs.python.org  Wed Nov 19 20:49:12 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Nov 2014 19:49:12 +0000
Subject: [New-bugs-announce] [issue22903] unittest creates non-picklable
	errors
Message-ID: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Just got this:

_pickle.PicklingError: Can't pickle <class 'unittest.loader.ModuleImportFailure'>: attribute lookup ModuleImportFailure on unittest.loader failed

unittest should use regular exception classes instead.

----------
messages: 231398
nosy: ezio.melotti, michael.foord, pitrou, rbcollins
priority: normal
severity: normal
status: open
title: unittest creates non-picklable errors
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 19 23:55:34 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Nov 2014 22:55:34 +0000
Subject: [New-bugs-announce] [issue22904] make profile-opt fails to update
	_sysconfigdata.py	during the rebuild
Message-ID: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

1) Checkout a 3.4 tree.  Mine was at revision d244e1770f1b.
2) ./configure
3) make -j14 profile-opt
4) ./python -m test.regrtest -v test_distutils

FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/.../oss/cpython/3.4/Lib/distutils/tests/test_sysconfig.py", line 131, in test_sysconfig_module
    sysconfig.get_config_var('CFLAGS'))
AssertionError: '-Wno[38 chars] -Wall -Wstrict-prototypes  -fprofile-use -fprofile-correction' != '-Wno[38 chars] -Wall -Wstrict-prototypes'

This can be traced to the built _sysconfigdata.py file which contains the command line passed CFLAGS from the build_all_use_profile target's sub-make vs the distutils.sysconfig module's Makefile parsing which finds the PY_CFLAGS value from the Makefile itself.

One of either stripping the profile-opt related flags out when generating _sysconfigdata.py or explicitly generating a good _sysconfigdata.py file outside of the sub-make's with the profiling generate or use flags seems like a good idea.  The latter is likely easier; just regenerate _sysconfigdata.py after the sub-make.

----------
assignee: gregory.p.smith
messages: 231401
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: make profile-opt fails to update _sysconfigdata.py during the rebuild
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 20 11:43:23 2014
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 20 Nov 2014 10:43:23 +0000
Subject: [New-bugs-announce] [issue22906] PEP 479: Change StopIteration
	handling inside generators
Message-ID: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>


New submission from Chris Angelico:

See PEP for full details. Attached is POC patch: behaviour is altered globally (rather than respecting a __future__ directive), and minimal changes are made elsewhere to make the test suite mostly pass (test_generators does not - it'll need more comprehensive edits). Note that PEP 8 is deliberately not followed here; some of the edits ought to involve indenting slabs of code, but instead, "half-level" indentation is used, to keep the patch visibly minimal.

----------
components: Interpreter Core, Library (Lib)
files: pep0479.patch
keywords: patch
messages: 231422
nosy: Rosuav
priority: normal
severity: normal
status: open
title: PEP 479: Change StopIteration handling inside generators
versions: Python 3.5
Added file: http://bugs.python.org/file37233/pep0479.patch

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

From report at bugs.python.org  Thu Nov 20 14:00:52 2014
From: report at bugs.python.org (Peter Korsgaard)
Date: Thu, 20 Nov 2014 13:00:52 +0000
Subject: [New-bugs-announce] [issue22907] Misc/python-config.sh.in: ensure
	sed invocations only	match beginning of strings
Message-ID: <1416488452.97.0.575494016591.issue22907@psf.upfronthosting.co.za>


New submission from Peter Korsgaard:

The build/real prefix handling using sed breaks if build != real and the
standard include / lib directories are used ($prefix/include and $prefix/lib).

E.G.

prefix_build="/usr", libdir="$prefix/lib", includedir="$prefix/include".

If this gets installed with make DESTDIR="/foo" install, then we end up with prefix_real = prefix = "/foo/usr" as expected, but
includedir="/foo/foo/usr/include" and libdir="/foo/foo/usr/lib" because of the double sed invocation (prefix is already expanded).  Work around it by ensuring we only match the beginning of the string.

----------
components: Cross-Build
files: 0001-Misc-python-config.sh.in-ensure-sed-invocations-only.patch
keywords: patch
messages: 231427
nosy: peko
priority: normal
severity: normal
status: open
title: Misc/python-config.sh.in: ensure sed invocations only match beginning of strings
versions: Python 3.4
Added file: http://bugs.python.org/file37234/0001-Misc-python-config.sh.in-ensure-sed-invocations-only.patch

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

From report at bugs.python.org  Thu Nov 20 16:20:43 2014
From: report at bugs.python.org (Iridium Yang)
Date: Thu, 20 Nov 2014 15:20:43 +0000
Subject: [New-bugs-announce] [issue22908] ZipExtFile in zipfile can be
	seekable
Message-ID: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za>


New submission from Iridium Yang:

The ZipExtFile class in zipfile module does not provide a seek method like GzipFile. As a result, it is hard to manipulate files without extract all the content.
For example, a very large tar file compressed with zip. The TarFile module can operate on file object, but need seek method. So the ZipExtFile instance return from ZipFile can not passed into TarFile.
This may seem strange but I encounter this on Samsung firmware.

In fact, the seek method in GzipFile or someother compressed format can be implemented in zipfile very easily. Here is my naive modification (nearly same as in GzipFile)

----------
components: Library (Lib)
files: zipfile.diff
keywords: patch
messages: 231438
nosy: Iridium.Yang
priority: normal
severity: normal
status: open
title: ZipExtFile in zipfile can be seekable
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37237/zipfile.diff

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

From report at bugs.python.org  Thu Nov 20 22:28:58 2014
From: report at bugs.python.org (Tab Atkins Jr.)
Date: Thu, 20 Nov 2014 21:28:58 +0000
Subject: [New-bugs-announce] [issue22909] [argparse] Using parse_known_args,
	unknown arg with space in value is interpreted as first positional
	arg
Message-ID: <1416518938.92.0.605418746252.issue22909@psf.upfronthosting.co.za>


New submission from Tab Atkins Jr.:

If using parse_known_args() to get argument pass-through, and one of the "unknown" arguments has a value with a space in it (even if quoted!), the entire unknown argument (key=value) will be interpreted as the value of the first positional argument instead.

Example:

```
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("pos", nargs="?", default=None)

parser.parse_known_args(["--foo='bar'"])
# (Namespace(pos=None), ['--foo=bar'])
# As expected.

parse.parse_known_args(["--foo='bar baz'"])
# (Namespace(pos="--foo='bar baz'"), [])
# What?!?
```

Since *known* arguments with spaces in them are parsed fine, this looks to be regression in a lesser-used feature.

----------
components: Library (Lib)
messages: 231448
nosy: TabAtkins
priority: normal
severity: normal
status: open
title: [argparse] Using parse_known_args, unknown arg with space in value is interpreted as first positional arg
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 21 08:03:41 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 21 Nov 2014 07:03:41 +0000
Subject: [New-bugs-announce] [issue22910] test_pydoc
	test_synopsis_sourceless is a flaky test
Message-ID: <1416553421.91.0.74824945431.issue22910@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

When running a parallel make -j12 test, test_pydoc fails reasonably often with:

test test_pydoc failed -- Traceback (most recent call last):
  File "/.../Lib/test/test_pydoc.py", line 556, in test_synopsis_sourceless   
    synopsis = pydoc.synopsis(filename)
  File "/.../Lib/pydoc.py", line 240, in synopsis
    mtime = os.stat(filename).st_mtime
FileNotFoundError: [Errno 2] No such file or directory: '/.../Lib/__pycache__/os.cpython-34.pyc'

Two other issues mention this failure as being introduced recently in comments:
  http://bugs.python.org/issue20123 & http://bugs.python.org/issue20128

----------
assignee: gregory.p.smith
components: Tests
messages: 231465
nosy: eric.snow, gregory.p.smith, koobs
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pydoc test_synopsis_sourceless is a flaky test
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 21 19:42:52 2014
From: report at bugs.python.org (Ian Kelly)
Date: Fri, 21 Nov 2014 18:42:52 +0000
Subject: [New-bugs-announce] [issue22911] Segfault on recursive
	itertools.chain.from_iterable
Message-ID: <1416595372.6.0.247378552877.issue22911@psf.upfronthosting.co.za>


New submission from Ian Kelly:

I expect this should result in a recursion depth exceeded error, not a segmentation fault.

$ cat test.py
import itertools

l = []
it = itertools.chain.from_iterable(l)
l.append(it)
next(it)
$ python3 test.py
Segmentation fault (core dumped)

----------
components: Library (Lib)
messages: 231489
nosy: ikelly
priority: normal
severity: normal
status: open
title: Segfault on recursive itertools.chain.from_iterable
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 21 20:55:58 2014
From: report at bugs.python.org (Taylor Marks)
Date: Fri, 21 Nov 2014 19:55:58 +0000
Subject: [New-bugs-announce] [issue22912] urlretreive locks up in 2.7.8
Message-ID: <1416599758.35.0.866747041142.issue22912@psf.upfronthosting.co.za>


New submission from Taylor Marks:

The following code causes Python 2.7.8 to lockup for ten minutes, then crash, in both Windows 7 and OS X:

from urllib import urlretrieve
urlretrieve('http://chromedriver.storage.googleapis.com/2.12/chromedriver_win32.zip', 'chromedriver_win32.zip')

Here's a thread on StackOverflow where I originally posted about this bug, assuming it was an issue in my code, before other people let me know that the problem wasn't my code, but with Python 2.7.8, on both Windows 7 and OS X, and that in older versions of Python, such as 2.7.6, the code works fine.

http://stackoverflow.com/questions/27025998/urllib-urlretreive-completely-locks-up-python

----------
components: Library (Lib)
messages: 231492
nosy: TaylorSMarks
priority: normal
severity: normal
status: open
title: urlretreive locks up in 2.7.8
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 21 21:03:12 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 20:03:12 +0000
Subject: [New-bugs-announce] [issue22913] Rewrite of Python 2/3 porting HOWTO
Message-ID: <1416600192.1.0.141771846079.issue22913@psf.upfronthosting.co.za>


New submission from Brett Cannon:

This is a rewrite of the Python 2/3 porting HOWTO to describe how to make code be compatible with both Python 2 & 3. To see it rendered for easier reading, see https://gist.github.com/brettcannon/91ff264ae549315706f6

----------
assignee: brett.cannon
components: Documentation
files: pyporting.diff
keywords: patch
messages: 231495
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rewrite of Python 2/3 porting HOWTO
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37243/pyporting.diff

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

From report at bugs.python.org  Fri Nov 21 21:03:19 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 20:03:19 +0000
Subject: [New-bugs-announce] [issue22914] Rewrite of Python 2/3 porting HOWTO
Message-ID: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za>


New submission from Brett Cannon:

This is a rewrite of the Python 2/3 porting HOWTO to describe how to make code be compatible with both Python 2 & 3. To see it rendered for easier reading, see https://gist.github.com/brettcannon/91ff264ae549315706f6

----------
assignee: brett.cannon
components: Documentation
files: pyporting.diff
keywords: patch
messages: 231496
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rewrite of Python 2/3 porting HOWTO
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37244/pyporting.diff

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

From report at bugs.python.org  Sat Nov 22 00:54:11 2014
From: report at bugs.python.org (Jocelyn)
Date: Fri, 21 Nov 2014 23:54:11 +0000
Subject: [New-bugs-announce] [issue22915] sax.parser cannot get xml data
	from a subprocess pipe
Message-ID: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>


New submission from Jocelyn:

With the attached code, and an xml file, I got the following error with python 3.4.2:

$ cat toto.xml
<?xml version='1.0' encoding='UTF-8'?>
<test></test>


$ python3.4 toto.py 
Traceback (most recent call last):
  File "toto.py", line 10, in <module>
    parse(proc.stdout, ContentHandler())
  File "/usr/lib/python3.4/xml/sax/__init__.py", line 33, in parse
    parser.parse(source)
  File "/usr/lib/python3.4/xml/sax/expatreader.py", line 107, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/lib/python3.4/xml/sax/xmlreader.py", line 119, in parse
    self.prepareParser(source)
  File "/usr/lib/python3.4/xml/sax/expatreader.py", line 111, in prepareParser
    self._parser.SetBase(source.getSystemId())
TypeError: must be str, not int


The same test works with python2, and I would expect the code to work with python 3 too.


Thanks,
Jocelyn

----------
components: XML
messages: 231504
nosy: JocelynJ
priority: normal
severity: normal
status: open
title: sax.parser cannot get xml data from a subprocess pipe
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 22 17:36:18 2014
From: report at bugs.python.org (Kevin Smith)
Date: Sat, 22 Nov 2014 16:36:18 +0000
Subject: [New-bugs-announce] [issue22916] Interpreter segfault on attempted
	tab complete
Message-ID: <1416674178.09.0.829992164977.issue22916@psf.upfronthosting.co.za>


New submission from Kevin Smith:

I am getting a segmentation fault in the interpreter when trying to tab complete options for a module.  I am running python 3.4.2 on Arch Linux.

Python 3.4.2 (default, Oct  8 2014, 13:44:52) 
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sfml as sf
>>> t = sf.Texture.from_file ("sprites.png")
>>> s = sf.Sprite (t)
>>> s.Segmentation fault

When I type "s." then push tab to complete available options the interpreter segfaults.  This is with python-sfml-1.3-4 from the Arch repositories.  Tab completion for built-in types seems to work fine.

----------
messages: 231520
nosy: FazJaxton
priority: normal
severity: normal
status: open
title: Interpreter segfault on attempted tab complete
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 22 21:19:30 2014
From: report at bugs.python.org (heme)
Date: Sat, 22 Nov 2014 20:19:30 +0000
Subject: [New-bugs-announce] [issue22917] Calculating problem
In-Reply-To: <20141122200049.5CFDB56363@psf.upfronthosting.co.za>
Message-ID: <a028839fc31febb219cd72f70ef4967a@jubii.dk>


New submission from heme:

Hi guys 

I am very new to this, (just started my first lines today) so I am using
a book to learn Python. BUT there is something wrong: 

This is my program (from the book): 

# This is not quite true outside of USA
# and is based on my dim memories of my younger years
print("Firstish Grade")
print("1 + 1 =", 1 + 1)
print("2 + 4 =", 2 + 4)
print("5 - 2 =", 5 - 2)
print()
print("Thirdish Grade")
print("243 - 23 =", 243 - 23)
print("12 * 4 =", 12 * 4)
print("12 / 3 =", 12 / 3)
print("13 / 3 =", 13 // 3, "R", 13 % 3)
print()
print("Junior High")
print("123.56 - 62.12 =", 123.56 - 62.12)
print("(4 + 3) * 2 =", (4 + 3) * 2)
print("4 + 3 * 2 =", 4 + 3 * 2)
print("3 ** 2 =", 3 ** 2) 

and this is the programs answer: 

Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32
bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
Firstish Grade
1 + 1 = 2
2 + 4 = 6
5 - 2 = 3

Thirdish Grade
243 - 23 = 220
12 * 4 = 48
12 / 3 = 4.0
13 / 3 = 4 R 1

Junior High
123.56 - 62.12 = 61.440000000000005
(4 + 3) * 2 = 14
4 + 3 * 2 = 10
3 ** 2 = 9
>>> 

As you can see, 

print("123.56 - 62.12 =", 123.56 - 62.12) is not = 61.440000000000005 

so my guess is that the interpreter has a malfunction. 

My pc is a compaq mini 110 running (walking;-)) windows xp srv pack 3 

in a std. config. 

brg 

Henning Mentz - Denmark

----------
messages: 231527
nosy: heme
priority: normal
severity: normal
status: open
title: Calculating problem

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

From report at bugs.python.org  Sat Nov 22 21:49:39 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Nov 2014 20:49:39 +0000
Subject: [New-bugs-announce] [issue22918] Doc for __iter__ makes inexact
	comment about	dict.__iter__
Message-ID: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

https://docs.python.org/3/reference/datamodel#object.__iter__

> This method should return a new iterator object that can iterate over all the objects
> in the container. For mappings, it should iterate over the keys of the container, and
> should also be made available as the method keys().

In 3.x, d.__iter__() is not equivalent to d.keys() but to iter(d.keys()).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 231529
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc for __iter__ makes inexact comment about dict.__iter__
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov 22 22:40:07 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Nov 2014 21:40:07 +0000
Subject: [New-bugs-announce] [issue22919] Update PCBuild for VS 2015
Message-ID: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>


New submission from Steve Dower:

I've basically finished the core of the work to refresh the PCBuild project files and support building with VS 2015, and I believe it's ready to merge in.

Though the title says VS 2015, builds will work fine with VS 2010 and VS 2013 (and probably VS 2012, but I didn't try it). Even so, I've copied the old project files into PC/VS10.0, though I'd be happy to just forget them.

I suspect Tools/msi/msi.py will stop working with this change. My replacement installer is not ready yet. If anyone's particularly concerned about msi.py then I can try and restore it before checking this in, but I'm 99.9% certain it won't be used for 3.5, so I don't see the point.


I've attached two patches, one with all the changes and the other with the "highlights" - the diff between the diffs are most of the project files and the added/deleted files. I imagine practically everyone will have a better time viewing the changes in their own hg tools, so the changes can be pulled from my sandbox with "hg pull https://hg.python.org/sandbox/steve.dower -b Projects" or viewed at https://hg.python.org/sandbox/steve.dower/shortlog/d08b456124e5. (I'll rebase these as a single commit in default when it goes in.)

A few changes that may deserve some more discussion:

* Builds for 32-bit now go to PCBuild\win32 instead of PCBuild (the batch file updates should make this transparent)

* The project that used to trigger the OpenSSL build is now two projects (libeay, ssleay) that do the build directly, so they may need updating whenever we update the OpenSSL version or change _ssl/_hashlib. I'm obviously happy to track these. (The advantages are proper incremental builds, better debugging, better optimisation - definitely PGO if we turn that back on.)

* The posixmodule.c update for Py_Verify_fd may become redundant - the VC14 CRT will include a per-thread function to change the invalid parameter handling, so when that's available we should be able to switch away from this trickery completely.

* I changed some GetVersion calls (which no longer behave properly as of Windows 8.1) to use functions from VersionHelpers.h in VS 2013 and later.

* build.bat now builds in parallel by default, with '-M' to disable.

* PCBuild/readme.txt has been updated as if VS 2015 has already been released. This is not yet true, but I doubt anyone who notices will be particularly confused or upset.

----------
assignee: steve.dower
components: Build, Windows
files: projects_highlights.diff
keywords: needs review, patch
messages: 231531
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Update PCBuild for VS 2015
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37246/projects_highlights.diff

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

From report at bugs.python.org  Sat Nov 22 22:56:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2014 21:56:28 +0000
Subject: [New-bugs-announce] [issue22920] Crash with itertools
Message-ID: <1416693388.96.0.0990071080113.issue22920@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

import itertools

l = []
it = itertools.chain.from_iterable(l)
l.append(it)
next(it)

Ian Kelly (python-list, version unspecified) got "Segmentation fault (core dumped)".  With 2.7, 3.4.2, 3.5, I get same in interactive interpreter, the Windows "python has stopped working" box from console, or subprocess hang with Idle.

----------
messages: 231534
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Crash with itertools
type: crash
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov 23 06:27:45 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 23 Nov 2014 05:27:45 +0000
Subject: [New-bugs-announce] [issue22921] SSLContext's check_hostname
	needlessly intertwined with	SNI
Message-ID: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>


New submission from Donald Stufft:

The SSLContext().wrap_socket() method allows you to pass in a server_hostname option which will be used for two purposes, it will be used as the server name for SNI and it will be used to verify the server name of the certificate. However currently if the OpenSSL you're using does not have SNI then sending the server_hostname option to wrap_socket() will raise a ValueError.

I think that instead server_hostname should always be accepted by SSLContext().wrap_socket() regardless of if SNI is available or if check_hostname is available. It's just going to be stored and used later so we can conditonally use it for SNI or for checking the hostname depending on if SNI is available or checking if a hostname is available. The way it works right now is that unless you're happy not working when SNI is not available you have to check the hostname yourself.

If we can fix this, I think it would be smart to do it ASAP and get it into Python 2.7.9 and backported to the various Python 3.x's so that in the near future it works with all recent versions of the various Pythons (though older micro releases it may not).

This shouldn't break any code since it's changing what used to be an error into a saner working case.

----------
messages: 231544
nosy: alex, benjamin.peterson, christian.heimes, dstufft
priority: normal
severity: normal
status: open
title: SSLContext's check_hostname needlessly intertwined with SNI
type: enhancement

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

From report at bugs.python.org  Sun Nov 23 10:32:03 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2014 09:32:03 +0000
Subject: [New-bugs-announce] [issue22922] asyncio: call_soon() should raise
	an exception if the	event loop is closed
Message-ID: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za>


New submission from STINNER Victor:

call_soon() call be called before the event loop starts and after run_forever(), the call will be executed by the next call to run_forever() (or run_until_complete).

But calling call_soon() after close() does not make sense and the user may be surprised to not see its function called. It can be obvious in a simple program, but not in a large application.

----------
components: asyncio
keywords: easy
messages: 231549
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: call_soon() should raise an exception if the event loop is closed
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov 23 10:45:42 2014
From: report at bugs.python.org (Yoha)
Date: Sun, 23 Nov 2014 09:45:42 +0000
Subject: [New-bugs-announce] [issue22923] No prompt for "display all X
	possibilities" on	completion-enabled input()
Message-ID: <1416735942.39.0.542265470543.issue22923@psf.upfronthosting.co.za>


New submission from Yoha:

When running input() (or raw_input() for Python 2) while tab-completion has been enabled using `readline.parse_and_bind('tab: complete')`, pressing the tab key twice display the message `Display all X possibilities? (y or n)` when there are more than 100 remaining possibilities (default value). However, I am not asked any input to answer the question, and readline then proceeds to display all possibilities.

Steps to reproduce:

* run the following code: `__import__('readline').parse_and_bind('tab:complete');input()"`
* press tab twice

If your current directory has more than 100 files, the message `Display all X possibilities? (y or n)` should show, following by a list of the files.

The bug still shows up with:
* rlcompleter or custom completer
* versions 2.7.3, 2.7.8, 3.2.3 and 3.4.2
* bash or zsh
* tty, screen, ssh+screen, xterm, urxvt, gnome-terminal
* command-line flags -S (no `site` module), -u (unbuffered) or -Su
* being run as script, as `-c` command-line argument, or in the interactive interpreter
* `import readline;readline.` or `from readline import *` in stead of `__import__('readline').`


On the other hand, the C program "#include <readline/readline.h>", "main(){readline(0);}" behaves as expected: after the message is displayed, user input is waited for and typing "y" lists the possibilities, "n" resumes the line editing, and anything else is ignored.

----------
components: IO, Library (Lib)
messages: 231550
nosy: yoha
priority: normal
severity: normal
status: open
title: No prompt for "display all X possibilities" on completion-enabled input()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Sun Nov 23 11:06:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Nov 2014 10:06:15 +0000
Subject: [New-bugs-announce] [issue22924] Use of deprecated cgi.escape
Message-ID: <1416737175.16.0.367831967609.issue22924@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Deprecated cgi.escape() is used in Tools/scripts/gprof2html.py and Tools/scripts/highlight.py. It should be replaced by html.escape(). Unfortunately the html module clashes with the html parameter in highlight.py so I left this issue for Reymond.

----------
assignee: rhettinger
components: Demos and Tools
keywords: easy
messages: 231552
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Use of deprecated cgi.escape
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov 23 16:50:17 2014
From: report at bugs.python.org (=?utf-8?b?QmFyacWhYSBPYnJhZG92acSH?=)
Date: Sun, 23 Nov 2014 15:50:17 +0000
Subject: [New-bugs-announce] [issue22925] Backporting suppress context
	manager to 2.7
Message-ID: <1416757817.56.0.153442346053.issue22925@psf.upfronthosting.co.za>


New submission from Bari?a Obradovi?:

Backport one of the context manager in 3.4, to 2.7:
supressed

The patch was created by copy pasting code from 3.4 branch to 2.7 branch, and removing a single 3.4 feature:
- at support.requires_docstrings

----------
components: Build
files: suppress.patch
hgrepos: 280
keywords: patch
messages: 231565
nosy: Bari?a.Obradovi?
priority: normal
severity: normal
status: open
title: Backporting suppress context manager to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37253/suppress.patch

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

From report at bugs.python.org  Sun Nov 23 17:38:14 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2014 16:38:14 +0000
Subject: [New-bugs-announce] [issue22926] asyncio:
Message-ID: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The call_soon(), call_later() and call_at() methods of asyncio event loops should raise an exception in debug code when they are not called from the right thread.

Currently, BaseEventLoop._assert_is_current_event_loop() does nothing if the event loop policy has no event loop for the current thread, when get_event_loop() raises an AssertionError.

----------
components: asyncio
messages: 231569
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio:
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov 24 03:26:56 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 24 Nov 2014 02:26:56 +0000
Subject: [New-bugs-announce] [issue22927] Expose an SSLContext parameter on
	urllib APIs
Message-ID: <1416796016.4.0.331627129896.issue22927@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

With the pep476 backport, we need a way to pass a context argument to urrlib

----------
components: Library (Lib)
messages: 231588
nosy: alex, benjamin.peterson, dstufft
priority: normal
severity: normal
status: open
title: Expose an SSLContext parameter on urllib APIs
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 24 03:50:25 2014
From: report at bugs.python.org (Guido Vranken)
Date: Mon, 24 Nov 2014 02:50:25 +0000
Subject: [New-bugs-announce] [issue22928] HTTP header injection
	in	urrlib2/urllib/httplib/http.client
Message-ID: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>


New submission from Guido Vranken:

Proof of concept:

# Script for Python 2
import urllib2
opener = urllib2.build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0' + chr(0x0A) + "Location: header injection")]
response = opener.open("http://localhost:9999")

# Data sent is:
"""
GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost:9999
Connection: close
User-Agent: Mozilla/5.0
Location: header injection

"""

# End of script

# Python 3
from urllib.request import urlopen, build_opener
opener = build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0' + chr(0x0A) + "Location: header injection")]
opener.open("http://localhost:9999")

# Data sent is:
"""
GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost:9999
Connection: close
User-Agent: Mozilla/5.0
Location: header injection

"""

# End of script

It is the responsibility of the developer leveraging Python and its HTTP client libraries to ensure that their (web) application acts in accordance to official HTTP specifications and that no threats to security will arise from their code.
However, newlines inside headers are arguably a special case of breaking the conformity with RFC's in regard to the allowed character set. No illegal character used inside a HTTP header is likely to have a compromising side effect on back-end clients and servers and the integrity of their communication, as a result of the leniency of most web servers. However, a newline character (0x0A) embedded in a HTTP header invariably has the semantic consequence of denoting the start of an additional header line. To put it differently, not sanitizing headers in complete accordance to RFC's could be seen as as virtue in that it gives the programmer a maximum amount of freedom, without having to trade it for any likely or severe security ramifications, so that they may use illegal characters in testing environments and environments that are outlined by an expliticly less strict interpretation of the HTTP protocol. Newlines are special in that they enable anyone who is able to influence the header content, to, in effect, perform additional invocations to add_header().

In issue 17322 ( http://bugs.python.org/issue17322 ) there is some discussion as to the general compliance to RFC's by the HTTP client libraries. I'd like to opt to begin with prohibiting newline characters to be present in HTTP headers. Although this issue is not a "hard vulnerability" such as a buffer overflow, it does translate to a potentially equal level of severity when considered from the perspective of a web-enabled application, for which purpose the HTTP libraries are typically used for. Lack of input validation on the application developer's end will faciliate header injections, for example if user-supplied data will end up as cookie content verbatim.
Adding this proposed additional layer of validation inside Python minimizes the likelihood of a successful header injection while functionality is not notably affected.

I'm inclined to add this validation to putheader() in the 'http' module rather than in urllib, as this will secure all invocations to 'http' regardless of intermediate libraries such as urllib.

Included is a patch for the latest checkout of the default branch that will cause CannotSendHeader() to be raised if a newline character is detected in either a header name or its value. Aside from detecting "\n", it also breaks on "\r" as their respective implications can be similar. Feel free to adjust, rewrite and transpose this to other branches where you feel this is appropriate.


Guido Vranken
Intelworks

----------
components: Library (Lib)
files: disable_http_header_injection.patch
keywords: patch
messages: 231590
nosy: Guido
priority: normal
severity: normal
status: open
title: HTTP header injection in urrlib2/urllib/httplib/http.client
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37264/disable_http_header_injection.patch

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

From report at bugs.python.org  Mon Nov 24 11:39:37 2014
From: report at bugs.python.org (era)
Date: Mon, 24 Nov 2014 10:39:37 +0000
Subject: [New-bugs-announce] [issue22929] cp874 encoding almost empty
Message-ID: <1416825577.9.0.423392091227.issue22929@psf.upfronthosting.co.za>


New submission from era:

I created a simple script to map character codes in the 8bit range to Unicode for simple lookup:

https://github.com/tripleee/8bit

In the generated output, on Python 2.6.6 (but corroborated on Python 2.7.6), almost all character codes come up as "undefined" in CP874.

According to http://en.wikipedia.org/wiki/ISO/IEC_8859-11, CP874 should be a superset of ISO-8859-11, with a few character codes *added* in the ISO control range.

----------
components: Unicode
messages: 231596
nosy: era, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: cp874 encoding almost empty
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 24 11:49:19 2014
From: report at bugs.python.org (Dmitry Shachnev)
Date: Mon, 24 Nov 2014 10:49:19 +0000
Subject: [New-bugs-announce] [issue22930] Value of time.timezone is
	sometimes wrong
Message-ID: <1416826159.48.0.941875897993.issue22930@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

Here, on Linux, I get:

$ python3 -c "import time; print(time.timezone)"
-14400

? which means I am in UTC+4. However, Russia recently (in October) switched time, and moved from UTC+4 to UTC+3 timezone (my tzdata is up-to-date), so this reported value is wrong.

The relevant code in timemodule.c looks like (simplified):

  #define YEAR ((time_t)((365 * 24 + 6) * 3600))
  time_t t = (time((time_t *)0) / YEAR) * YEAR;
  struct tm *p = localtime(&t);
  janzone = -p->tm_gmtoff;
  PyModule_AddIntConstant(m, "timezone", janzone);

The value of t is the *January 1st* of current year, i.e. 2014-01-01 currently. But the timezone of a country in the year beginning may be different from its timezone in the year end, which is the case for me.

This bug will be relevant for Russia until the end of 2014, but may be still relevant for other countries that wish to change their timezone.

----------
components: Extension Modules
messages: 231597
nosy: mitya57
priority: normal
severity: normal
status: open
title: Value of time.timezone is sometimes wrong
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 24 16:43:24 2014
From: report at bugs.python.org (Waldemar Parzonka)
Date: Mon, 24 Nov 2014 15:43:24 +0000
Subject: [New-bugs-announce] [issue22931] cookies with square brackets in
	value
Message-ID: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>


New submission from Waldemar Parzonka:

There seems to be weird behaviour in BaseCookie.load() when cookie that has '[' in one of the values is being loaded.

There is no exception being thrown as the key is still legal but the cookie is not getting loaded properly and everything that was after the '[' valued cookie is being silently ignored.

>>> dd = SimpleCookie()
>>> dd
<SimpleCookie: >
>>> s = 'a=b; c=[; d=r; f=h'
>>> dd.load(s)
>>> dd
<SimpleCookie: a='b'>
>>>

----------
components: Library (Lib)
messages: 231605
nosy: Waldemar.Parzonka
priority: normal
severity: normal
status: open
title: cookies with square brackets in value
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 24 17:17:20 2014
From: report at bugs.python.org (Dmitry Shachnev)
Date: Mon, 24 Nov 2014 16:17:20 +0000
Subject: [New-bugs-announce] [issue22932] email.utils.formatdate uses
	unreliable time.timezone	constant
Message-ID: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

The value of time.timezone may be wrong sometimes (see http://bugs.python.org/issue22752), so I think the email library should not use it:

$ python3 -c "from email.utils import formatdate; print(formatdate(localtime=True))"
Mon, 24 Nov 2014 19:16:32 +0400
$ date -R
Mon, 24 Nov 2014 19:16:32 +0300

Using something from datetime module may be a better solution.

----------
components: Library (Lib)
messages: 231608
nosy: belopolsky, mitya57
priority: normal
severity: normal
status: open
title: email.utils.formatdate uses unreliable time.timezone constant
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 24 18:10:36 2014
From: report at bugs.python.org (newbie)
Date: Mon, 24 Nov 2014 17:10:36 +0000
Subject: [New-bugs-announce] [issue22933] Misleading sentence in doc for
	shutil.move
Message-ID: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>


New submission from newbie:

First sentence of 3rd paragraph of 10.10. "shutil" documentation for shutil.move command, "The destination directory must not already exist", is misleading and contradicts other information in the entry.  I took it to mean that if dst did not exist, python would create it as a directory.  What actually happens is that python renames src to dst. In my test, I was moving several files to a new directory, and the result was a file with the pathname dst and contents matching the last move command, consistent with the behavior described in the rest of the paragraph and the following one. When I changed the code to create the directory with os.mkdirs before calling shutil.move, it worked as I wanted, so obviously there's nothing wrong with the destination directory already existing. The preceding paragraph implies this with its description of behavior when dst refers to a directory.  I suggest removing this sentence, and maybe adding some text indicating what to do if you want to move a file to a new directory.
I was using Python 2.7.5 on Windows, and branch 2.7.8 of the documentation (there does not appear to be a branch 2.7.5 available.)

----------
assignee: docs at python
components: Documentation
messages: 231612
nosy: docs at python, newbie
priority: normal
severity: normal
status: open
title: Misleading sentence in doc for shutil.move
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 24 20:48:32 2014
From: report at bugs.python.org (joseph)
Date: Mon, 24 Nov 2014 19:48:32 +0000
Subject: [New-bugs-announce] [issue22934] Python/importlib.h is now
	generated by	Programs/_freeze_importlib.c, change comment
Message-ID: <1416858512.31.0.184261411621.issue22934@psf.upfronthosting.co.za>


New submission from joseph:

Since the changeset 91853:88a532a31eb3 _freeze_importlib.c resides in the Programs dir. The header comment of Python/importlib.h should be changed to reflect this.

----------
components: Build
files: freeze_importlib_comment.patch
keywords: patch
messages: 231617
nosy: crozzy
priority: normal
severity: normal
status: open
title: Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment
versions: Python 3.5
Added file: http://bugs.python.org/file37267/freeze_importlib_comment.patch

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

From report at bugs.python.org  Mon Nov 24 23:14:20 2014
From: report at bugs.python.org (Kurt Roeckx)
Date: Mon, 24 Nov 2014 22:14:20 +0000
Subject: [New-bugs-announce] [issue22935] Disabling SSLv3 support
Message-ID: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>


New submission from Kurt Roeckx:

Hi,

The attached patch makes python work when openssl doesn't have SSLv3 support.  It also updates the documentation, which has already improved a lot since my original patch.

The current upstream openssl when compiled with no-ssl2 it defines OPENSSL_NO_SSL2, drops the SSLv2_* method and drops support for SSLv2 in the SSLv23_* methods.  When build with no-ssl3 it defines OPENSSL_NO_SSL3 and currently just drops supports for SSLv3 in the SSLv23_method, it does not yet drop the SSLv3_* methods.  It's still being argued whether no-ssl3 should drop those symbols or that a new option will be used instead.

So that means that with OPENSSL_NO_SSL3 defined it could be that the SSLv3_* methods still exist and that you can create a socket that only support SSLv3.

I made the SSLv3 methods go away in python if OPENSSL_NO_SSL3 is defined.  This at least makes things easier for the test suite so that you know you can test a combination like v3 with v23 or not.

This patch is for 2.7.  Please let me know if you need a patch for a different version.

----------
files: python2.7-nossl3.patch
keywords: patch
messages: 231624
nosy: kroeckx
priority: normal
severity: normal
status: open
title: Disabling SSLv3 support
Added file: http://bugs.python.org/file37268/python2.7-nossl3.patch

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

From report at bugs.python.org  Tue Nov 25 03:05:27 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Nov 2014 02:05:27 +0000
Subject: [New-bugs-announce] [issue22936] traceback module has no way to
	show locals
Message-ID: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>


New submission from Robert Collins:

>From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals.

To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib).

----------
components: Library (Lib)
messages: 231628
nosy: rbcollins
priority: normal
severity: normal
status: open
title: traceback module has no way to show locals
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 25 03:06:22 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Nov 2014 02:06:22 +0000
Subject: [New-bugs-announce] [issue22937] unittest errors can't show locals
Message-ID: <1416881182.95.0.816242293699.issue22937@psf.upfronthosting.co.za>


New submission from Robert Collins:

>From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals.

To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib). This issue is for the unittest part of it. For the traceback dependency see http://bugs.python.org/issue22936 .

----------
components: Library (Lib)
messages: 231629
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest errors can't show locals
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 25 06:46:26 2014
From: report at bugs.python.org (Archana Pandey)
Date: Tue, 25 Nov 2014 05:46:26 +0000
Subject: [New-bugs-announce] [issue22938] assignment operator += does not
	behave same as a = a + b	for List
Message-ID: <1416894386.29.0.913544398942.issue22938@psf.upfronthosting.co.za>


New submission from Archana Pandey:

List is mutable with += operator. But the same cannot be achieved when we use arithmatic + and assignment = operator used

Please Find the attached python module

----------
components: Windows
files: Operator_bug_python.py
messages: 231633
nosy: archi-pandey, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: assignment operator += does not behave same as a = a + b for List
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file37269/Operator_bug_python.py

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

From report at bugs.python.org  Tue Nov 25 11:56:33 2014
From: report at bugs.python.org (Clement Rouault)
Date: Tue, 25 Nov 2014 10:56:33 +0000
Subject: [New-bugs-announce] [issue22939] integer overflow in iterator object
Message-ID: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za>


New submission from Clement Rouault:

I found an interger overflow in the standard iterator object (Objects/iterobject.c)

The `it_index` attribute used by the iterator is a `Py_ssize_t` but overflow is never checked. So after the index `PY_SSIZE_T_MAX`, the iterator object will ask for the index `PY_SSIZE_T_MIN`.

Here is an example:

    import sys

    class Seq:
        def __getitem__(self, item):
            print("[-] Asked for item at <{0}>".format(item))
            return 0

    s = Seq()
    i = iter(s)
    # Manually set `it_index` to PY_SSIZE_T_MAX without a loop
    i.__setstate__(sys.maxsize)

    next(i)
    [-] Asked for item at <9223372036854775807>
    next(i)
    [-] Asked for item at <-9223372036854775808>


I would be really interested in writing a patch but first I wanted to discuss the expected behaviour and fix.

The iterator could stop after `PY_SSIZE_T_MAX` but it seems strange as other iterator (like `enumobject`) handle values bigger than `PY_SSIZE_T_MAX`.

Or the same technique used in `enumobject` could be used: adding a field `PyObject* en_longindex` (a python long) which would be used for values bigger than `PY_SSIZE_T_MAX`

----------
components: Interpreter Core
messages: 231651
nosy: hakril
priority: normal
severity: normal
status: open
title: integer overflow in iterator object
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov 25 15:30:57 2014
From: report at bugs.python.org (bru)
Date: Tue, 25 Nov 2014 14:30:57 +0000
Subject: [New-bugs-announce] [issue22940] readline does not offer partial
	saves
Message-ID: <1416925857.17.0.992509064643.issue22940@psf.upfronthosting.co.za>


New submission from bru:

The "readline" module offers "write_history_file" from readline/history.h "write_history", but there's no "append_history_file" that would invoke "append_history" from the C header.

This causes inconveniences when saving history to a file (like shown there: https://docs.python.org/3.5/library/readline.html?highlight=readline#example). Indeed, say you have 2 interpreters (A) and (B) open.
- (A) and (B) load the history, composed of (z) lines
- you work on both, writing (a) lines in (A) and (b) lines in (b)
- you close (A), the history file now has (z)+(a)
- you close (B), the history file now has (z)+(b)
Therefore (A) history (the (a) lines) is lost. Offering "append_history_file" would be a nice way to fix this problem: having (z)+(a)+(b) in the end would be easy.

This is exactly what the attached patch does. With it are tests, doc and an example. I've not updated Misc/NEWS yet though (no issue #).

----------
components: Library (Lib)
files: 0001-Add-readline.append_history_file-function.patch
keywords: patch
messages: 231661
nosy: bru
priority: normal
severity: normal
status: open
title: readline does not offer partial saves
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37275/0001-Add-readline.append_history_file-function.patch

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

From report at bugs.python.org  Tue Nov 25 17:41:57 2014
From: report at bugs.python.org (=?utf-8?b?U8O4cmVuIEzDuHZib3Jn?=)
Date: Tue, 25 Nov 2014 16:41:57 +0000
Subject: [New-bugs-announce] [issue22941] IPv4Interface arithmetic changes
	subnet mask
Message-ID: <1416933717.58.0.234544639586.issue22941@psf.upfronthosting.co.za>


New submission from S?ren L?vborg:

Addition and subtraction of integers are documented for ipaddress.IPv4Address and ipaddress.IPv6Address, but also work for IPv4Interface and IPv6Interface (though the only documentation of this is a brief mention that the Interface classes inherit from the respective Address classes). That's good.

The problem is that adding/subtracting an integer to an Interface object changes the subnet mask (to max_prefixlen), something which is 1) not documented and 2) not the least surprising result.

>>> import ipaddress
>>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
IPv4Interface('10.0.0.2/32')
>>> ipaddress.IPv6Interface('fd00::1/64') + 1
IPv6Interface('fd00::2/128')

Changing this breaks backwards compatibility; though since the ipaddress module was provisional until recently and the behavior is undocumented, I hope it's not too late to change.

----------
components: Library (Lib)
messages: 231670
nosy: kwi.dk
priority: normal
severity: normal
status: open
title: IPv4Interface arithmetic changes subnet mask
type: behavior

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

From report at bugs.python.org  Tue Nov 25 20:52:38 2014
From: report at bugs.python.org (Jordan)
Date: Tue, 25 Nov 2014 19:52:38 +0000
Subject: [New-bugs-announce] [issue22942] Language Reference - optional comma
Message-ID: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>


New submission from Jordan:

# I would like to report three bugs in the
# Language Reference Python 3.4.2

#################################
# bug 1: Typo in parameter_list #
#################################

# In 8.6 the rule for parameter_list should be corrected: The first "|" should be "("

# parameter_list ::=  (defparameter ",")*
#                     | "*" [parameter] ("," defparameter)* ["," "**" parameter]
#                     | "**" parameter
#                     | defparameter [","] )

# This rule was correct in 3.3 but has been changed with issue #21439, I guess.

                    
###############################################################################
# bug 2: print(*(1,2),) is allowed according to the syntax - but not accepted #
###############################################################################

# In 6.3.4:
# call                 ::=  primary "(" [argument_list [","] | comprehension] ")"
# argument_list        ::=  positional_arguments ["," keyword_arguments]
#                             ["," "*" expression] ["," keyword_arguments]
#                             ["," "**" expression]
#                           | keyword_arguments ["," "*" expression]
#                             ["," keyword_arguments] ["," "**" expression]
#                           | "*" expression ["," keyword_arguments] ["," "**" expression]
#                           | "**" expression

# Why is this wrong?
print(1,2,)     # is allowed
print(*(1,2))   # is allowed
#print(*(1,2),) # is allowed according to the syntax - but not accepted

# I guess the trailing comma is only allowed when there is no *-argument
# as it is in the rule for parameter_list

###########################################################
# bug 3: decorator rule allows (aditional) trailing comma #
###########################################################

# In 8.6:
# decorator      ::=  "@" dotted_name ["(" [parameter_list [","]] ")"] NEWLINE
# parameter_list ::=  (defparameter ",")*
#                     ( "*" [parameter] ("," defparameter)* ["," "**" parameter]
#                     | "**" parameter
#                     | defparameter [","] )

# Why is this wrong?
def klammer(klammer_left,klammer_right):
    def klammer_decorator(func):
        def func_wrapper(name):
            return klammer_left + func(name) + klammer_right
        return func_wrapper
    return klammer_decorator

@klammer("<",">",)   # is allowed
#@klammer("<",">",,) # is allowed according to the syntax - but is not accepted
def get_text(name):
    return "Hallo " + name
print(get_text("Uli")) 

@klammer(*("<",">"))   # is allowed
#@klammer(*("<",">"),) # is allowed according to the syntax - but is not accepted
def get_text(name):
    return "Hallo " + name
print(get_text("Uli"))

# I guess the decorator rule might be changed to: 
# decorator      ::=  "@" dotted_name ["(" [parameter_list      ] ")"] NEWLINE
# The other appearences of parameter_list have no optional comma.

----------
assignee: docs at python
components: Documentation
messages: 231680
nosy: docs at python, jordan
priority: normal
severity: normal
status: open
title: Language Reference - optional comma
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 26 00:36:39 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2014 23:36:39 +0000
Subject: [New-bugs-announce] [issue22943] bsddb: test_queue fails on Windows
Message-ID: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

One gets this on the Windows bots:

======================================================================
FAIL: test01_basic (bsddb.test.test_queue.SimpleQueueTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\bsddb\test\test_queue.py", line 49, in test01_basic
    self.assertEqual(len(d), len(string.letters)+3)
AssertionError: 125 != 128

======================================================================
FAIL: test02_basicPost32 (bsddb.test.test_queue.SimpleQueueTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\bsddb\test\test_queue.py", line 120, in test02_basicPost32
    self.assertEqual(len(d), len(string.letters)+3)
AssertionError: 125 != 128

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

(See http://buildbot.python.org/all/builders/x86%20Windows7%202.7/builds/2925/steps/test/logs/stdio)

This has been going on for a long time. I doubt anyone cares. I'm just going to disable the test.

----------
components: Extension Modules
messages: 231687
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: bsddb: test_queue fails on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 26 05:02:11 2014
From: report at bugs.python.org (Simon Zack)
Date: Wed, 26 Nov 2014 04:02:11 +0000
Subject: [New-bugs-announce] [issue22944] Python argument tuple unpacking
Message-ID: <1416974531.76.0.408873524447.issue22944@psf.upfronthosting.co.za>


New submission from Simon Zack:

Python already has tuple unpacking in many places, I wonder if this has been considered for arguments yet, it seems rather convenient and a natural extension to me.

Here's what I mean:

def func((a, b, c)):
    print(a, b, c)

func((1, 2, 3))

should print "1 2 3"

----------
components: Interpreter Core
messages: 231689
nosy: simonzack
priority: normal
severity: normal
status: open
title: Python argument tuple unpacking

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

From report at bugs.python.org  Wed Nov 26 05:46:50 2014
From: report at bugs.python.org (Daniel Standage)
Date: Wed, 26 Nov 2014 04:46:50 +0000
Subject: [New-bugs-announce] [issue22945] Ctypes inconsistent between Linux
	and OS X
Message-ID: <1416977210.81.0.587848085748.issue22945@psf.upfronthosting.co.za>


New submission from Daniel Standage:

The ctypes documentation describes the '._as_parameter_' attribute, which simplifies using Python objects to encapsulate C objects. If a ctypes object with the '._as_parameter_' attribute defined is passed as a parameter to a C function, the value of '._as_parameter_' is supplied to the C function instead of a pointer to the Python project.

At least that's how it's advertised to work. And it does indeed work as advertised on Linux, but on Mac OS X the mechanism doesn't appear to work correctly. I have created a small dummy example demonstrating this at https://github.com/standage/ctypes-demo.

----------
components: ctypes
hgrepos: 281
messages: 231692
nosy: Daniel.Standage
priority: normal
severity: normal
status: open
title: Ctypes inconsistent between Linux and OS X
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 26 11:37:27 2014
From: report at bugs.python.org (John McKay)
Date: Wed, 26 Nov 2014 10:37:27 +0000
Subject: [New-bugs-announce] [issue22946] urllib gives incorrect url after
	open when using HTTPS
Message-ID: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za>


New submission from John McKay:

After getting a sucessfull response, _open_generic_http will overwrite the the start of the url to be http: regardless of if it was called from open_http() or open_https(). This causes it to appear as if you were redirected to a non-secure site if you check the url properly after an open request. This is especially problematic after being redirected; it appears you were redirected to an insecure version of the site.

Attached is a patch to resolve this. It uses the type, which should be correctly set to http or https based on the calling context.

----------
components: Library (Lib)
files: urllib.patch
keywords: patch
messages: 231702
nosy: John.McKay
priority: normal
severity: normal
status: open
title: urllib gives incorrect url after open when using HTTPS
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37283/urllib.patch

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

From report at bugs.python.org  Wed Nov 26 13:18:31 2014
From: report at bugs.python.org (pankaj.s01)
Date: Wed, 26 Nov 2014 12:18:31 +0000
Subject: [New-bugs-announce] [issue22947] Enable 'imageop' - "Multimedia
	Srvices Feature module"	for 64-bit platform
Message-ID: <1417004311.93.0.975050094816.issue22947@psf.upfronthosting.co.za>


New submission from pankaj.s01:

Hi,
'imageop' is default disable in Python-2.7.8 for 64-bit platform.
i have enable and test on x_86 64-bit architecture. it's working fine.and it's unit test is also ok.

The respective patch has been attached and test log as shown 
below . 

output: for test_imageop.py
****************************
$]./python2.7  ../lib/python2.7/test/test_imageop.py
test_input_validation (__main__.InputValidationTests) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.047s

OK

--
Thanks & Regards,

 Pankaj Sharma
(pankaj.s01 at samsung.com)

----------
components: Library (Lib)
files: Python-2.7.8-imageop.patch
keywords: patch
messages: 231707
nosy: pankaj.s01
priority: normal
severity: normal
status: open
title: Enable 'imageop' - "Multimedia Srvices Feature module" for 64-bit platform
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37287/Python-2.7.8-imageop.patch

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

From report at bugs.python.org  Wed Nov 26 15:32:25 2014
From: report at bugs.python.org (Sascha Falk)
Date: Wed, 26 Nov 2014 14:32:25 +0000
Subject: [New-bugs-announce] [issue22948] Integer type and __add__
Message-ID: <1417012345.4.0.50245289459.issue22948@psf.upfronthosting.co.za>


New submission from Sascha Falk:

The following statement makes python report a syntactic error:
1.__add__(2)

The following works:
(1).__add__(2)

----------
components: Interpreter Core
messages: 231711
nosy: sfalk
priority: normal
severity: normal
status: open
title: Integer type and __add__
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 26 15:34:48 2014
From: report at bugs.python.org (mstol)
Date: Wed, 26 Nov 2014 14:34:48 +0000
Subject: [New-bugs-announce] [issue22949] fnmatch.translate doesn't add ^ at
	the beginning
Message-ID: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>


New submission from mstol:

I'm not sure if this is real bug, but the documentation of fnmatch.translate states:

fnmatch.translate(pattern)

    Return the shell-style pattern converted to a regular expression.



My intuition about shell-style pattern is that for example, pattern:t3
should match only t3, and not ost3 or xxxxxt3, but what I receive from fnmatch is:
In [2]: fnmatch.translate("t3")
Out[2]: 't3\\Z(?ms)'

so using for example re.search will match not only on t3, but also on xxxt3 (in shell-like pattern is *t3). So... I  believe it should be changed or at least the documentation should be more specific about what "shell-style pattern" mean.

----------
components: Regular Expressions
messages: 231712
nosy: ezio.melotti, mrabarnett, mstol
priority: normal
severity: normal
status: open
title: fnmatch.translate doesn't add ^ at the beginning
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 26 19:48:03 2014
From: report at bugs.python.org (Friedrich Spee von Langenfeld)
Date: Wed, 26 Nov 2014 18:48:03 +0000
Subject: [New-bugs-announce] [issue22950] ASLR and DEP protection
Message-ID: <1417027683.15.0.168800959084.issue22950@psf.upfronthosting.co.za>


New submission from Friedrich Spee von Langenfeld:

Are all binary files of a Python installation protected with techniques like Adress Space Layout Randomization and Data Execution Prevention? How can someone check this with an PE Editor or something similar? I know that this seems not to be a matter of great interest, but it would set an example to other programmers: Security is not an optional feature, but a necessity. Many thanks in advance.

----------
components: Build
messages: 231723
nosy: Friedrich.Spee.von.Langenfeld
priority: normal
severity: normal
status: open
title: ASLR and DEP protection
type: security

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

From report at bugs.python.org  Wed Nov 26 20:47:16 2014
From: report at bugs.python.org (jaebae17)
Date: Wed, 26 Nov 2014 19:47:16 +0000
Subject: [New-bugs-announce] [issue22951] unexpected return from
	float.__repr__() for inf, -inf, nan
Message-ID: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>


New submission from jaebae17:

The help page for the built-in repr() states ''' For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval()...'''

This holds true for non-inf/nan values of float():
>>> eval(repr(float('0.0')))
0.0

But for inf, -inf, and nan it does not:
>>> eval(repr(float('inf')))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'inf' is not defined

Expected return from repr(float('inf')) was "float('inf')", but perhaps 'inf' response has too much history at this point to be changed.

----------
messages: 231724
nosy: jaebae17
priority: normal
severity: normal
status: open
title: unexpected return from float.__repr__() for inf, -inf, nan
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 26 22:35:09 2014
From: report at bugs.python.org (Davin Potts)
Date: Wed, 26 Nov 2014 21:35:09 +0000
Subject: [New-bugs-announce] [issue22952] multiprocessing doc introduction
	not in affirmative tone
Message-ID: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>


New submission from Davin Potts:

The introduction section of the multiprocessing module's documentation does not adhere to the python dev guidelines for keeping things in the affirmative tone.

Problem description:
Specifically, the intro section contains a warning block that, while conveying something important, both 1) potentially creates worry/concern in the mind of the reader new to this module, and 2) ideally belongs somewhere more relevant/appropriate than the intro section.  Also, the intro section contains an example code block that does not attempt to provide a simple example to advance understanding and boost the reader's confidence through trying this example -- instead it demonstrates what not to do and the consequences of doing so in an attempt to drive home one key point with the reader.

Suggested changes:
* The warning text block can be moved to a section discussing synchronization without losing the important information being shared or sharing it too late to be useful.
* To make the key point to the reader in the intro about the availability/importability of functions, etc. to child processes, the affirmative tone can be used in describing the good pattern/practice being employed in a usable/valid/working example.


Further comment:  Similar issues could be raised with other parts of the multiprocessing docs but this issue is concerned only with the intro section.

----------
assignee: docs at python
components: Documentation
messages: 231731
nosy: davin, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing doc introduction not in affirmative tone
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 27 00:52:14 2014
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 26 Nov 2014 23:52:14 +0000
Subject: [New-bugs-announce] [issue22953] Windows installer configures
	system PATH also when	installing only for current user
Message-ID: <1417045934.78.0.497938457178.issue22953@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck:

To reproduce:
1) Download and run Python 2.7.9rc1 Windows installer.
2) Select "Install just for me."
3) Enable "Add python.exe to Path."
=>
Expected: Current user PATH edited.
Actual: System PATH edited.

----------
components: Installation
messages: 231734
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Windows installer configures system PATH also when installing only for current user
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 27 05:59:46 2014
From: report at bugs.python.org (pankaj.s01)
Date: Thu, 27 Nov 2014 04:59:46 +0000
Subject: [New-bugs-announce] [issue22954] Logically Dead Code
Message-ID: <1417064386.3.0.793786383436.issue22954@psf.upfronthosting.co.za>


New submission from pankaj.s01:

Hi,
In Python-3.4.2 (latest version), there is logically dead code in function static tp_new_wrapper().

The respective patch has been attached for 
"Python-3.4.2/Objects/typeobject.c"

Thanks $ Regards,
 Pankaj Sharma
(Pankaj.s01 at samsung.com)

----------
files: Python-3.4.2-typeobject.patch
keywords: patch
messages: 231746
nosy: pankaj.s01
priority: normal
severity: normal
status: open
title: Logically Dead Code
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37293/Python-3.4.2-typeobject.patch

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

From report at bugs.python.org  Thu Nov 27 07:33:03 2014
From: report at bugs.python.org (Antony Lee)
Date: Thu, 27 Nov 2014 06:33:03 +0000
Subject: [New-bugs-announce] [issue22955] Pickling of methodcaller and
	attrgetter
Message-ID: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>


New submission from Antony Lee:

methodcaller and attrgetter objects seem to be picklable, but in fact the pickling is erroneous:

>>> import operator, pickle
>>> pickle.loads(pickle.dumps(operator.methodcaller("foo")))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: methodcaller needs at least one argument, the method name
>>> pickle.loads(pickle.dumps(operator.attrgetter("foo")))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: attrgetter expected 1 arguments, got 0

When looking at the pickle disassembly, it seems that the argument to the constructor is indeed not pickled.

>>> import pickletools; pickletools.dis(pickle.dumps(operator.methodcaller("foo")))
    0: \x80 PROTO      3
    2: c    GLOBAL     'operator methodcaller'
   25: q    BINPUT     0
   27: )    EMPTY_TUPLE
   28: \x81 NEWOBJ
   29: q    BINPUT     1
   31: .    STOP
highest protocol among opcodes = 2

----------
components: Library (Lib)
messages: 231752
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Pickling of methodcaller and attrgetter
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 27 14:38:39 2014
From: report at bugs.python.org (Markus Elfring)
Date: Thu, 27 Nov 2014 13:38:39 +0000
Subject: [New-bugs-announce] [issue22956] Improved support for prepared SQL
	statements
Message-ID: <1417095519.92.0.197896622793.issue22956@psf.upfronthosting.co.za>


New submission from Markus Elfring:

An interface for parameterised SQL statements (working with placeholders) is provided by the execute() method from the Cursor class at the moment.
https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor.execute

I assume that the "SQL Statement Object" from the SQLite C interface is reused there already.
http://sqlite.org/c3ref/stmt.html

I imagine that it will be more efficient occasionally to offer also a base class like "prepared_statement" so that the parameter specification does not need to be parsed for every passed command.
I suggest to improve corresponding preparation and compilation possibilities.

----------
components: Extension Modules
messages: 231759
nosy: elfring
priority: normal
severity: normal
status: open
title: Improved support for prepared SQL statements

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

From report at bugs.python.org  Thu Nov 27 14:50:39 2014
From: report at bugs.python.org (Markus Elfring)
Date: Thu, 27 Nov 2014 13:50:39 +0000
Subject: [New-bugs-announce] [issue22957] Multi-index Containers Library
Message-ID: <1417096239.96.0.247692729349.issue22957@psf.upfronthosting.co.za>


New submission from Markus Elfring:

I find a data structure like it is provided by the "Boost Multi-index Containers Library" interesting for efficient data processing.
http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/index.html

How are the chances to integrate a class library with similar functionality into the Python software infrastructure?

----------
components: Extension Modules
messages: 231761
nosy: elfring
priority: normal
severity: normal
status: open
title: Multi-index Containers Library
type: enhancement

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

From report at bugs.python.org  Thu Nov 27 17:13:23 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 16:13:23 +0000
Subject: [New-bugs-announce] [issue22958] Constructors of weakref mapping
	classes don't accept	"self" and "dict" keyword arguments
Message-ID: <1417104803.61.0.896440563309.issue22958@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Dict-like types in the weakref module (WeakValueDictionary and WeakKeyDictionary) don't allow to specify key-value pair as keyword arguments if key is "self" or "dict".

>>> import weakref
>>> class A: pass
... 
>>> a = A()
>>> d = weakref.WeakValueDictionary(spam=a)
>>> list(d.items())
[('spam', <__main__.A object at 0xb6f3f88c>)]
>>> weakref.WeakValueDictionary(self=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got multiple values for argument 'self'
>>> weakref.WeakValueDictionary(dict=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/weakref.py", line 114, in __init__
    self.update(*args, **kw)
  File "/home/serhiy/py/cpython/Lib/weakref.py", line 261, in update
    dict = type({})(dict)
TypeError: 'A' object is not iterable
>>> d = weakref.WeakValueDictionary()
>>> d.update(spam=a)
>>> list(d.items())
[('spam', <__main__.A object at 0xb6f3f88c>)]
>>> d.update(self=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: update() got multiple values for argument 'self'
>>> d.update(dict=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/weakref.py", line 261, in update
    dict = type({})(dict)
TypeError: 'A' object is not iterable

Related issue for the collections module is issue22609. I think weakref mapping classes should be fixed in the same manner.

----------
components: Library (Lib)
messages: 231767
nosy: fdrake, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Constructors of weakref mapping classes don't accept "self" and "dict" keyword arguments
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Nov 27 20:42:39 2014
From: report at bugs.python.org (zodalahtathi)
Date: Thu, 27 Nov 2014 19:42:39 +0000
Subject: [New-bugs-announce] [issue22959] http.client.HTTPSConnection checks
	hostname when SSL	context has check_hostname==False
Message-ID: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>


New submission from zodalahtathi:

http.client.HTTPSConnection has both a check_hostname parameter, and a context parameter to pass an already setup SSL context.
When check_hostname is not set and thus is None, and when passing a SSL context set to NOT check hostnames, ie:

import http.client
import ssl

ssl_context = ssl.create_default_context() 
ssl_context.check_hostname = False
https = http.client.HTTPSConnection(..., context=ssl_context)

The https object WILL check hostname.

In my opinion the line :
https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1207
            will_verify = context.verify_mode != ssl.CERT_NONE

Should be changed to:
            will_verify = (context.verify_mode != ssl.CERT_NONE) and (context.check_hostname)

----------
components: Library (Lib)
messages: 231775
nosy: zodalahtathi
priority: normal
severity: normal
status: open
title: http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 27 21:23:06 2014
From: report at bugs.python.org (zodalahtathi)
Date: Thu, 27 Nov 2014 20:23:06 +0000
Subject: [New-bugs-announce] [issue22960] xmlrpc.client.ServerProxy() should
	accept a custom SSL	context parameter
Message-ID: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>


New submission from zodalahtathi:

When using xmlrpc.server it is possible (despite being intrusive) to use a custom SSL context, ie:

import ssl
import xmlrpc.server

rpc_server = xmlrpc.server.SimpleXMLRPCServer(...)
ssl_context = ssl.SSLContext()
# setup the context ...
rpc_server.socket = ssl_context.wrap_socket(rpc_server.socket, ...)

However it is not possible (unless using some ugly monkey patching, which I am ashamed of writing) to do the same for xmlrpc.client.

xmlrpc.client.ServerProxy() could accept a context constructor, and pass it to the SafeTransport instance, and then to the http.client.HTTPSConnection instance (https://hg.python.org/cpython/file/3.4/Lib/xmlrpc/client.py#l1338).

I would allow passing a SSL context more secure than the default one, and thus improve security.

----------
components: Library (Lib)
messages: 231778
nosy: zodalahtathi
priority: normal
severity: normal
status: open
title: xmlrpc.client.ServerProxy() should accept a custom SSL context parameter
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 28 07:37:34 2014
From: report at bugs.python.org (Simon Zack)
Date: Fri, 28 Nov 2014 06:37:34 +0000
Subject: [New-bugs-announce] [issue22961] ctypes.WinError & OSError
Message-ID: <1417156654.51.0.229780672791.issue22961@psf.upfronthosting.co.za>


New submission from Simon Zack:

The ctypes.WinError function returns:

    OSError(None, descr, None, code)

However OSError does not appear to allow None as a first argument, and converts it to 22 which is the EINVAL "Invalid Argument" error. This is rather confusing as there was no invalid argument errors in the code.

I think the behaviour for one of WinError and OSError should be modified so that the handling of errno is more compatible.

----------
messages: 231796
nosy: simonzack
priority: normal
severity: normal
status: open
title: ctypes.WinError & OSError

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

From report at bugs.python.org  Fri Nov 28 09:54:06 2014
From: report at bugs.python.org (Gary van der Merwe)
Date: Fri, 28 Nov 2014 08:54:06 +0000
Subject: [New-bugs-announce] [issue22962] ipaddress: Add optional prefixlen
	argument to	ip_interface and ip_network
Message-ID: <1417164846.5.0.804919214198.issue22962@psf.upfronthosting.co.za>


New submission from Gary van der Merwe:

Currently if one has an ip address in int or IPv4Address/IPv6Address form, it is not possilbe to create a ip_interface or ip_network from that with specific prefix length, without first converting the address into string form, and then appending the prefixlen 

Please could an optional prefixlen argument to ip_interface and ip_network (and the __init__ functions for their backing classes) so that one can do this.

e.g: it should work like this:

>>> ipaddress.ip_interface(167772161, prefixlen=24)
IPv4Interface('10.0.0.1/24')

I would like to do a patch for this. I would just first like some feedback as to whether a patch for this would accepted.

----------
components: Library (Lib)
messages: 231800
nosy: Gary.van.der.Merwe
priority: normal
severity: normal
status: open
title: ipaddress: Add optional prefixlen argument to ip_interface and ip_network
type: enhancement

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

From report at bugs.python.org  Fri Nov 28 20:49:04 2014
From: report at bugs.python.org (Harsh Gupta)
Date: Fri, 28 Nov 2014 19:49:04 +0000
Subject: [New-bugs-announce] [issue22963] type in PEP 102
Message-ID: <1417204144.27.0.6150414989.issue22963@psf.upfronthosting.co.za>


New submission from Harsh Gupta:

In PEP 102 [1], the link to PEP 101 is broken.

[1]: https://www.python.org/dev/peps/pep-0102/

----------
components: Devguide
messages: 231825
nosy: ezio.melotti, hargup
priority: normal
severity: normal
status: open
title: type in PEP 102
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 28 23:42:31 2014
From: report at bugs.python.org (Antony Lee)
Date: Fri, 28 Nov 2014 22:42:31 +0000
Subject: [New-bugs-announce] [issue22964] dbm.open(..., "x")
Message-ID: <1417214551.97.0.349316203885.issue22964@psf.upfronthosting.co.za>


New submission from Antony Lee:

It would be nice if dbm.open() supported the "x" flag that open() now supports (create a new db, failing if it already exists).

----------
components: Library (Lib)
messages: 231835
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: dbm.open(..., "x")
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 29 09:57:52 2014
From: report at bugs.python.org (mattes)
Date: Sat, 29 Nov 2014 08:57:52 +0000
Subject: [New-bugs-announce] [issue22965] smtplib.py: senderrs[each] ->
	TypeError: unhashable	instance
Message-ID: <1417251472.86.0.2977752969.issue22965@psf.upfronthosting.co.za>


New submission from mattes:

I get the following error:

File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/smtplib.py", line 731, in sendmail
    senderrs[each] = (code, resp)
TypeError: unhashable instance

senderrs[str(each)] = (code, resp) fixes it. Not sure if that is the best fix though.

See also http://stackoverflow.com/questions/27195432/google-app-engine-mail-send-returns-typeerror-unhashable-instance-in-python2

----------
components: Library (Lib), email
messages: 231854
nosy: barry, mattes, r.david.murray
priority: normal
severity: normal
status: open
title: smtplib.py: senderrs[each] -> TypeError: unhashable instance
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 29 11:16:42 2014
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Sat, 29 Nov 2014 10:16:42 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue22966=5D_py=5Fcompile=3A_fo?=
 =?utf-8?b?by5iYXIucHkg4oaSIF9fcHljYWNoZV9fL2Zvby5jcHl0aG9uLTM0LnB5Yw==?=
Message-ID: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za>


New submission from Piotr O?arowski:

when py_compile module is asked to create .pyc file for file with invalid name, it doesn't fail or ignore such request - it creates/overwrites .pyc file for sane file name (i.e. ignores everything after dot)

$ touch foo.bar.py
$ python3.4 -m py_compile foo.bar.py
$ ls __pycache__
foo.cpython-34.pyc

Even though foo.bar.py is not a valid file name, some programmers are using such names for plugins which leads to bugs similar to https://lists.debian.org/debian-python/2014/11/msg00061.html.

I will update my scripts to not feed py_compile module with file names containing dot (and remove already generated .pyc files if such files are detected), but please do not generate them or generate .pyc files with invalid file names as well.

----------
messages: 231859
nosy: piotr
priority: normal
severity: normal
status: open
title: py_compile: foo.bar.py ? __pycache__/foo.cpython-34.pyc
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 29 20:39:26 2014
From: report at bugs.python.org (Kyle Lahnakoski)
Date: Sat, 29 Nov 2014 19:39:26 +0000
Subject: [New-bugs-announce] [issue22967] tempfile.py does not work in
	windows8
Message-ID: <1417289966.96.0.104718230559.issue22967@psf.upfronthosting.co.za>


New submission from Kyle Lahnakoski:

I installed python 2.7.8  on Windows version 6.2 (build 9200) and get-pip.py does not run.  I traced the problem to c:\python27\lib\tempfile.py   Here is my session:

>> c:\Users\kyle\Downloads>python
>> Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit Intel)] on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import tempfile
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "c:\Python27\lib\tempfile.py", line 32, in <module>
>>     import io as _io
>>   File "io.py", line 72, in <module>
>>     import numpy as N
>> ImportError: No module named numpy

Ok, seems odd that numpy is required.  I installed numpy, and tried again:

>> >>> import tempfile
>> >>> tmpdir = tempfile.mkdtemp()
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "c:\Python27\lib\tempfile.py", line 325, in mkdtemp
>>     dir = gettempdir()
>>   File "c:\Python27\lib\tempfile.py", line 269, in gettempdir
>>     tempdir = _get_default_tempdir()
>>   File "c:\Python27\lib\tempfile.py", line 200, in _get_default_tempdir
>>     with _io.open(fd, 'wb', closefd=False) as fp:
>> AttributeError: 'module' object has no attribute 'open'

I expected that tempfile would import without issue.

----------
components: IO
messages: 231867
nosy: klahnakoski at mozilla.com
priority: normal
severity: normal
status: open
title: tempfile.py does not work in windows8
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 29 21:38:34 2014
From: report at bugs.python.org (Greg Turner)
Date: Sat, 29 Nov 2014 20:38:34 +0000
Subject: [New-bugs-announce] [issue22968] types._calculate_meta nit:
	isinstance != PyType_IsSubtype
Message-ID: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za>


New submission from Greg Turner:

Kinda trivial but...

Something like the enclosed, untested patch would seem to make new_class work a bit more like type_new.

To be explicit, the difference is whether or not to respect virtual subclasses.

So, for example, as implemented, we can implement __subclasscheck__ on a 'AtypicalMeta' metaclass to create an 'Atypical' class whose __mro__ is (ATypical, object) -- note, no 'type' -- but for which issubclass(type, ATypical) is true.

If I'm not mistaken, this disguise will suffice sneak our psuedo-metatype past new_class (but not type.__new__, so we still get the same error message, and the universe does not implode on itself as planned...)

In my case,the only sequela was that the fantasy of my very own type-orthogonal graph of "foo"-style classes in 3.x was first subtly encouraged and then dashed against the Cpython rocks... (just kidding, sort-of).

----------
components: Library (Lib)
files: fix_types_calculate_meta.patch
keywords: patch
messages: 231871
nosy: gmt
priority: normal
severity: normal
status: open
title: types._calculate_meta nit: isinstance != PyType_IsSubtype
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37318/fix_types_calculate_meta.patch

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