From report at bugs.python.org  Mon Jun  1 04:11:34 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 01 Jun 2015 02:11:34 +0000
Subject: [New-bugs-announce] [issue24342] coroutine wrapper recursion
Message-ID: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Consider following piece of code:

    async def foo():
        return 'spam'

    def wrapper(coro):
        async def wrap(coro):
            print('before')
            try:
                return await coro
            finally:
                print('after')
        return wrap(coro)

    import sys
    sys.set_coroutine_wrapper(wrapper)
    print(foo().send(None))


Current python will crash with a "RuntimeError: maximum recursion depth exceeded", because  "wrap" is itself a coroutine, so ceval will call "wrapper" recursively.

There are three options here:

1. Leave things as is;

2. Add a flag in tstate that coroutine_wrapper is executing, and raise a RuntimeError if it's reentering;

3. Add a flag in tstate (see 2) and skip wrapping when reentering (i.e. return what was passed to the wrapper).

The attached patch implements (2).  It also makes PyEval*CoroWrapper methods private.

I, myself, vote for option 2.

----------
assignee: yselivanov
components: Interpreter Core
files: coro_wrapper.patch
keywords: patch
messages: 244569
nosy: gvanrossum, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: coroutine wrapper recursion
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39578/coro_wrapper.patch

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

From report at bugs.python.org  Mon Jun  1 10:28:41 2015
From: report at bugs.python.org (Laura Creighton)
Date: Mon, 01 Jun 2015 08:28:41 +0000
Subject: [New-bugs-announce] [issue24343] Installing 3.4.3 gives error codes
	2503 and 2502 on	windows 8
Message-ID: <1433147321.07.0.242833893345.issue24343@psf.upfronthosting.co.za>


New submission from Laura Creighton:

This came in to webmaster, i.e. I don't have the machine with the
problem and cannot test it.  Two different people reported the
same thing.  One of them was able to get things working by running as Admin. The other was not.  He was able to get things working by
running in compatibility mode.  When he reached that error, he got
a popup, and the popup asked if he wanted to troubleshoot.  He said
yes.  Then things silently ran, the installation suceeded and nothing
was mentioned that needed troubleshooting.

Thought you would like to know.

----------
components: Installation
messages: 244573
nosy: lac
priority: normal
severity: normal
status: open
title: Installing 3.4.3 gives  error codes 2503 and 2502  on windows 8
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun  1 14:42:01 2015
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 01 Jun 2015 12:42:01 +0000
Subject: [New-bugs-announce] [issue24344] Overlap display issue in windows
	installer
Message-ID: <1433162521.72.0.397093450999.issue24344@psf.upfronthosting.co.za>


New submission from Ionel Cristian M?rie?:

It appears that the  new installer has some overlap issue when displaying progress info. Attached a screenshot.

----------
components: Installation
files: installer-display-bug.png
messages: 244579
nosy: ionelmc, steve.dower
priority: normal
severity: normal
status: open
title: Overlap display issue in windows installer
versions: Python 3.5
Added file: http://bugs.python.org/file39584/installer-display-bug.png

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

From report at bugs.python.org  Mon Jun  1 15:41:14 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 01 Jun 2015 13:41:14 +0000
Subject: [New-bugs-announce] [issue24345] Py_tp_finalize is missing
Message-ID: <1433166074.58.0.387309124026.issue24345@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

PEP 442 added the tp_finalize member for objects, but there's no corresponding Py_tp_finalize slot. This means that types defined using PyType_FromSpec (and in particular, extensions using the stable ABI) can't take advantage of the new GC finalization mechanism.

----------
components: Extension Modules, Interpreter Core
files: add-py-tp-finalize.patch
keywords: patch
messages: 244581
nosy: encukou
priority: normal
severity: normal
status: open
title: Py_tp_finalize is missing
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39585/add-py-tp-finalize.patch

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

From report at bugs.python.org  Mon Jun  1 16:48:05 2015
From: report at bugs.python.org (stf)
Date: Mon, 01 Jun 2015 14:48:05 +0000
Subject: [New-bugs-announce] [issue24346] Key Error at List in Tuple
	concatenation
Message-ID: <1433170085.86.0.270970129026.issue24346@psf.upfronthosting.co.za>


Changes by stf <steffhip at gmail.com>:


----------
components: Interpreter Core
nosy: stf
priority: normal
severity: normal
status: open
title: Key Error at List in Tuple concatenation
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun  1 18:19:10 2015
From: report at bugs.python.org (Eric Snow)
Date: Mon, 01 Jun 2015 16:19:10 +0000
Subject: [New-bugs-announce] [issue24347] unchecked return value in C
	OrderedDict
Message-ID: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za>


New submission from Eric Snow:

(from msg244574 in issue16991)

crash-1.py is due to an unchecked return value from _odictnode_VALUE().

We should probably use PyDict_GetItemWithError(), also in other
places.

I normally try to steer clear of stylistic remarks, but the
_odictnode* macros are hiding too many things.  As of now,
they were hiding that an assert() is always true and that a
return value was unchecked.

Also, they're very inconvenient in a debugger.

----------
assignee: eric.snow
components: Library (Lib)
files: crash-1.py
messages: 244597
nosy: eric.snow, skrah
priority: release blocker
severity: normal
stage: test needed
status: open
title: unchecked return value in C OrderedDict
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39588/crash-1.py

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

From report at bugs.python.org  Mon Jun  1 18:21:56 2015
From: report at bugs.python.org (Eric Snow)
Date: Mon, 01 Jun 2015 16:21:56 +0000
Subject: [New-bugs-announce] [issue24348] incorrect decref in C OrderedDict
Message-ID: <1433175716.41.0.847645147456.issue24348@psf.upfronthosting.co.za>


New submission from Eric Snow:

(from msg244575 in issue16991)

crash-2.py is due to the fact that _PyDict_Pop() deletes a reference
to 'key' in _odict_popkey().

The INCREF(key) in popitem should take place before calling _odict_popkey().


Again, I don't see the point of INCREF/DECREF *inside* of _odict_popkey().

----------
assignee: eric.snow
components: Library (Lib)
files: crash-2.py
messages: 244598
nosy: eric.snow, skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: incorrect decref in C OrderedDict
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39589/crash-2.py

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

From report at bugs.python.org  Mon Jun  1 18:24:34 2015
From: report at bugs.python.org (Eric Snow)
Date: Mon, 01 Jun 2015 16:24:34 +0000
Subject: [New-bugs-announce] [issue24349] Null pointer dereferences in C
	OrderedDict
Message-ID: <1433175874.7.0.776296707125.issue24349@psf.upfronthosting.co.za>


New submission from Eric Snow:

(from msg244587 in issue16991)

Coverity has found an issue in odict, too:

*** CID 1302699:  Null pointer dereferences  (NULL_RETURNS)
/Objects/odictobject.c: 1316 in odict_copy()
1310             od_copy = PyObject_CallFunctionObjArgs((PyObject *)Py_TYPE(od), NULL);
1311         if (od_copy == NULL)
1312             return NULL;
1313     
1314         if (PyODict_CheckExact(od)) {
1315             _odict_FOREACH(od, node) {
>>>     CID 1302699:  Null pointer dereferences  (NULL_RETURNS)
>>>     Dereferencing a pointer that might be null "PyDict_GetItem((PyObject *)(PyObject *)od, node->key)" when calling "PyODict_SetItem".
1316                 int res = PyODict_SetItem((PyObject *)od_copy,
1317                                           _odictnode_KEY(node),
1318                                           _odictnode_VALUE(node, od));
1319                 if (res != 0)
1320                     goto fail;
1321             }

----------
assignee: eric.snow
components: Library (Lib)
messages: 244599
nosy: christian.heimes, eric.snow
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Null pointer dereferences in C OrderedDict
type: crash
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun  1 18:33:07 2015
From: report at bugs.python.org (Graham Klyne)
Date: Mon, 01 Jun 2015 16:33:07 +0000
Subject: [New-bugs-announce] [issue24350] dict({'a':'aa'},
	a='bb') raises segmentation fault on Mac
Message-ID: <1433176387.97.0.111097599452.issue24350@psf.upfronthosting.co.za>


New submission from Graham Klyne:

conina:~ graham$ python
Python 2.7.3 (v2.7.3:70274d53c1dd, Apr  9 2012, 20:52:43)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> dict({'a':'aa'},b='bb')
{'a': 'aa', 'b': 'bb'}
>>> dict({'a':'aa'},a='bb')
Segmentation fault: 11
conina:~ graham$



>From the docs:
[[
If keyword arguments are given, the keyword arguments and their values are added to the dictionary created from the positional argument. If a key being added is already present, the value from the keyword argument replaces the value from the positional argument.
]]

----------
components: Macintosh
messages: 244601
nosy: Graham Klyne, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: dict({'a':'aa'},a='bb') raises segmentation fault on Mac
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  1 21:05:07 2015
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 01 Jun 2015 19:05:07 +0000
Subject: [New-bugs-announce] [issue24351] string.Template documentation
	incorrectly references	"identifiers"
Message-ID: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>


New submission from July Tikhonov:

Documentation of Template says:

$identifier names a substitution placeholder matching a mapping key of "identifier". By default, "identifier" must spell a Python identifier. The first non-identifier character after the $ character terminates this placeholder specification.


While it was true when these lines were written, Python 3 has greatly extended identifier character set, and it no longer matches the set of characters used by Template:

>>> Template('$foo123??').substitute(foo=1, foo123=2, foo123??=3)
'2??'

I propose clarifying documentation.

Actually extending character set is backward-incompatible, although it won't be if restricted to "${identifier}" syntax.

----------
assignee: docs at python
components: Documentation
messages: 244607
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: string.Template documentation incorrectly references "identifiers"
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun  1 21:15:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2015 19:15:30 +0000
Subject: [New-bugs-announce] [issue24352] Provide a way for assertLogs to
	optionally not hide the	logging output
Message-ID: <1433186130.81.0.919581568401.issue24352@psf.upfronthosting.co.za>


New submission from R. David Murray:

In my test framework I have a 'verbose' flag that causes the logging output to be written to the console[*], which helps greatly during debugging.  However, if assertLogs is used, the logging is suppressed, and when debugging logging failures it is really helpful to see the full logging output :).

Ideally there would be a unittest-supported 'verbose' flag that assertLogs could look at and not suppress existing logging when it is at level 2 or greater.  Or perhaps a flag specific to logging output would be better?  I don't really care what the API is as long as I can arrange to set it from the CLI as part of running individual tests.

----------
components: Library (Lib)
messages: 244608
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Provide a way for assertLogs to optionally not hide the logging output
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Jun  1 21:51:56 2015
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 01 Jun 2015 19:51:56 +0000
Subject: [New-bugs-announce] [issue24353] NameError: name 'path_separators'
	is not defined
Message-ID: <1433188316.2.0.247864565419.issue24353@psf.upfronthosting.co.za>


New submission from Ionel Cristian M?rie?:

I get this:

Traceback (most recent call last):
  File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\basecommand.py", line 223, in main
    status = self.run(options, args)
  File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\commands\install.py", line 297, in run
    root=options.root_path,
  File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_set.py", line 622, in install
    **kwargs
  File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_install.py", line 808, in install
    self.move_wheel_files(self.source_dir, root=root)
  File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_install.py", line 1003, in move_wheel_files
    isolated=self.isolated,
  File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\wheel.py", line 266, in move_wheel_files
    compileall.compile_dir(source, force=True, quiet=True)
  File "C:\Program Files\Python 3.5\lib\compileall.py", line 88, in compile_dir
    legacy, optimize):
  File "C:\Program Files\Python 3.5\lib\compileall.py", line 126, in compile_file
    cfile = importlib.util.cache_from_source(fullname)
  File "<frozen importlib._bootstrap_external>", line 267, in cache_from_source
  File "<frozen importlib._bootstrap_external>", line 58, in _path_split
NameError: name 'path_separators' is not defined

Any idea what's going on? Should I try to make a minimal reproducing example?

----------
components: Interpreter Core
messages: 244609
nosy: ionelmc
priority: normal
severity: normal
status: open
title: NameError: name 'path_separators' is not defined
versions: Python 3.5

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

From report at bugs.python.org  Mon Jun  1 22:18:22 2015
From: report at bugs.python.org (loginname)
Date: Mon, 01 Jun 2015 20:18:22 +0000
Subject: [New-bugs-announce] [issue24354] Requests Library get issue
Message-ID: <1433189902.19.0.138832290406.issue24354@psf.upfronthosting.co.za>


New submission from loginname:

requests.get fails to get the website "http://www.merrickbank.com/"
just doesn't get the website, and it freezes up quite a bit

----------
messages: 244611
nosy: loginname
priority: normal
severity: normal
status: open
title: Requests Library get issue
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  1 22:28:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2015 20:28:25 +0000
Subject: [New-bugs-announce] [issue24355] Provide a unittest api for
	controlling verbosity in tests
Message-ID: <1433190505.1.0.734052090716.issue24355@psf.upfronthosting.co.za>


New submission from R. David Murray:

The python regression test suite has a 'verbose' flag in its test.support that some tests and test fixtures (asserts, helper methods, etc) use to control how much additional information they output.  unittest has a -v command line flag which controls the verbosity of the test runner (or whatever it is that prints out which tests have been run).  It would be very helpful if the verbosity level specified on the unittest command line were accessible to test code so that the verbosity level of the test output can also be affected from the unittest command line (I, for example, would use this to control printing logging output to the console while using tests to do debugging).  See also issue 24352.

----------
components: Library (Lib)
messages: 244613
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Provide a unittest api for controlling verbosity in tests
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Jun  2 00:21:33 2015
From: report at bugs.python.org (Graham Oliver)
Date: Mon, 01 Jun 2015 22:21:33 +0000
Subject: [New-bugs-announce] [issue24356] venv documentation incorrect /
	misleading
Message-ID: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>


New submission from Graham Oliver:

See my question here
https://groups.google.com/forum/#!topic/comp.lang.python/BUmyc_hzAsA
In particular Carl Meyer's response
https://groups.google.com/d/msg/comp.lang.python/BUmyc_hzAsA/-cT-N-g_LL4J

I am not sure what is possible with venv but I would suggest that the statement 'allowing creation of environments with various Python versions' needs to be clarified and / or altered.

Thanks
Graham

----------
assignee: docs at python
components: Documentation
messages: 244618
nosy: Graham.Oliver, docs at python
priority: normal
severity: normal
status: open
title: venv documentation incorrect / misleading
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun  2 02:59:40 2015
From: report at bugs.python.org (Paul Marks)
Date: Tue, 02 Jun 2015 00:59:40 +0000
Subject: [New-bugs-announce] [issue24357] www.python.org lost IPv6
	connectivity
Message-ID: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>


New submission from Paul Marks:

Python's web servers were formerly reachable from IPv6 clients, as evidenced by this example code for socket.getaddrinfo():

https://docs.python.org/3/library/socket.html#socket.getaddrinfo

But today, www.python.org is IPv4-only:

>>> import socket
>>> socket.getaddrinfo("www.python.org", 80, proto=socket.IPPROTO_TCP)
[(<AddressFamily.AF_INET: 2>, <SocketType.SOCK_STREAM: 1>, 6, '', ('23.235.40.223', 80))]

Please either restore IPv6 connectivity to www.python.org, or accept the shame and defeat of pointing the documentation to someone else's domain.

----------
assignee: docs at python
components: Documentation
messages: 244625
nosy: Paul Marks, docs at python
priority: normal
severity: normal
status: open
title: www.python.org lost IPv6 connectivity

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

From report at bugs.python.org  Tue Jun  2 03:03:01 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 02 Jun 2015 01:03:01 +0000
Subject: [New-bugs-announce] [issue24358] Should compression file-like
	objects provide .fileno(), misleading subprocess?
Message-ID: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

subprocess, when accepting objects for stdin, stdout, and stderr, assumes that possessing a .fileno() means it's a legitimate object for use with the forked process; that the file descriptor is interchangeable with the object itself. But gzip, bz2 and lzma file-like objects all violate this rule; they provide .fileno(), but it's unadorned. Providing .fileno() on these objects is misleading, since they produce the uncompressed data (likely useless) which causes subprocess to pass the "wrong" data to the subprocess, or write uncompressed data from the process (the exception being processes that expect compressed data from stdin or write compressed data to stdout, but that usually just means the compressor utilities themselves).

Is subprocess's assumption about fileno() (that you can read equivalent data from it, modulo issues with flushing/seeking) intended? If so, should .fileno() be removed from the compressed file interfaces? If not, should subprocess attempt to perform further checking, document this wart, or something else?

----------
components: IO
messages: 244626
nosy: josh.r
priority: normal
severity: normal
status: open
title: Should compression file-like objects provide .fileno(), misleading subprocess?
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jun  2 07:21:56 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 02 Jun 2015 05:21:56 +0000
Subject: [New-bugs-announce] [issue24359] C OrderedDict needs to check for
	changes during iteration
Message-ID: <1433222516.05.0.83881283764.issue24359@psf.upfronthosting.co.za>


New submission from Eric Snow:

Currently test_detect_deletion_during_iteration is disabled for the C implementation of OrderedDict.  The test needs to pass after being enabled.

----------
assignee: eric.snow
components: Library (Lib)
messages: 244651
nosy: eric.snow
priority: release blocker
severity: normal
stage: needs patch
status: open
title: C OrderedDict needs to check for changes during iteration
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jun  2 08:00:51 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Tue, 02 Jun 2015 06:00:51 +0000
Subject: [New-bugs-announce] [issue24360] improve argparse.Namespace
 __repr__ for invalid identifiers.
Message-ID: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za>


New submission from Matthias Bussonnier:

The argparse Namespace can be missleading in case where the args names are not valid identifiers, eg thinks like a closing bracket:

In [5]: Namespace(a=1, **{')':3})
Out[5]: Namespace()=3, a=1)

more funny:

In [3]: Namespace(a=1, **{s:3})
Out[3]: Namespace(a=1, b=2), Namespace(c=3)

for `s = 'b=2), Namespace(c'`


With this patch the args that are not valid identifiers are shown in ** unpacked-dict, which has the side effect of almost always having repr(eval(repr(obj)))== repr(obj). I'm sure we can find counter example with quotes and triple-quoted string... but anyway.


with this patch (indentation mine for easy comparison):

>>> from argparse import Namespace
>>> Namespace(a=1, **{')': 3})
    Namespace(a=1, **{')': 3})

Which is I think what most user would expect.

Test passes locally (except SSL cert, network thingies, curses and threaded_lru_cache) which look unrelated and is most likely due to my machine.

----------
components: Library (Lib)
files: improve-namespace-repr.patch
keywords: patch
messages: 244655
nosy: mbussonn
priority: normal
severity: normal
status: open
title: improve argparse.Namespace __repr__ for invalid identifiers.
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file39593/improve-namespace-repr.patch

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

From report at bugs.python.org  Tue Jun  2 12:02:57 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 02 Jun 2015 10:02:57 +0000
Subject: [New-bugs-announce] [issue24361] OrderedDict: crash with threads
Message-ID: <1433239377.83.0.708657008711.issue24361@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I tried to disprove my own claim of unreachable code in resize()/get_index() using a convoluted threaded test case.

The code still fails to be reached, but another segfault turned up.

----------
components: Extension Modules
files: crash-th.py
messages: 244661
nosy: Arfrever, BreamoreBoy, Jim.Jewett, Mark.Shannon, Ryan.Gonzalez, alex, asvetlov, benjamin.peterson, christian.heimes, eric.araujo, eric.smith, eric.snow, ezio.melotti, flox, gregory.p.smith, introom, josh.r, mrabarnett, ncoghlan, ned.deily, pitrou, python-dev, rhettinger, scoder, serhiy.storchaka, skrah, tonn81, westurner, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: OrderedDict: crash with threads
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file39595/crash-th.py

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

From report at bugs.python.org  Tue Jun  2 16:00:31 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 02 Jun 2015 14:00:31 +0000
Subject: [New-bugs-announce] [issue24362] Simplify the fast nodes resize
	logic in C OrderedDict.
Message-ID: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za>


New submission from Eric Snow:

Between comments on issue16991 and review comments there, it's clear that the implementation of _odict_resize and _odict_get_index in Objects/odictobject.c are too complicated to be a long-term solution.  simplifying the approach to avoid recursion should help substantially.

----------
assignee: eric.snow
components: Library (Lib)
messages: 244667
nosy: eric.snow, skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Simplify the fast nodes resize logic in C OrderedDict.
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jun  2 17:06:03 2015
From: report at bugs.python.org (Michael Del Monte)
Date: Tue, 02 Jun 2015 15:06:03 +0000
Subject: [New-bugs-announce] [issue24363] httplib fails to handle semivalid
	HTTP headers
Message-ID: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za>


New submission from Michael Del Monte:

Initially reported at https://github.com/kennethreitz/requests/issues/2622

Closely related to http://bugs.python.org/issue19996

An HTTP response with an invalid header line that contains non-blank characters but *no* colon (contrast http://bugs.python.org/issue19996 in which it contained a colon as the first character) causes the same behavior.

httplib.HTTPMessage.readheaders() oddly does not appear even to attempt to follow RFC 2616, which requires the header to terminate with a blank line.  The invalid header line, which admittedly also breaks RFC 2616, is at least non-blank and should not terminate the header.  Yet readheaders() takes it as an indicator that the header is over and then fails properly to process the rest of the response.

The problem is exacerbated by a chunked encoding, which will not be properly received if the encoding header is not seen because readheaders() terminates early.  An example (why are banks always the miscreants here?) is:

p = response.get("http://www.merrickbank.com/")

My recommended fix would be to insert these lines at httplib:327

                # continue reading headers on non-blank lines
                elif not len(line.strip()):
                    continue
                # break only on blank lines


This would cause readheaders() to terminate only on a non-blank non-header non-comment line, in accordance with RFC 2616.

----------
components: Library (Lib)
messages: 244672
nosy: mgdelmonte
priority: normal
severity: normal
status: open
title: httplib fails to handle semivalid HTTP headers
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun  2 18:39:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jun 2015 16:39:13 +0000
Subject: [New-bugs-announce] [issue24364] Not all defects pass through email
	policy
Message-ID: <1433263153.11.0.33312264244.issue24364@psf.upfronthosting.co.za>


New submission from R. David Murray:

This is a note to myself.  While looking at another issue I noticed that I never completed the work to make sure that all message defects discovered by feedparser are passed through the policy defect handler.  The fix is simple, the time consuming part is writing the tests.

----------
components: email
keywords: easy
messages: 244679
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Not all defects pass through email policy
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jun  2 20:54:59 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 02 Jun 2015 18:54:59 +0000
Subject: [New-bugs-announce] [issue24365] Conditionalize 3.5 additions to
	the stable API
Message-ID: <1433271299.64.0.126998075643.issue24365@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

I have sent patches to 3.5 that add new stable API, and later I learned [0] that additions should be conditional on the value of Py_LIMITED_API.
This patch adds #ifdef blocks for what was added in issues #24268 and #24345.


[0] https://mail.python.org/pipermail/python-dev/2015-June/140425.html

----------
components: Extension Modules, Interpreter Core
files: guard-stable-api.patch
keywords: patch
messages: 244684
nosy: encukou
priority: normal
severity: normal
status: open
title: Conditionalize 3.5 additions to the stable API
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39596/guard-stable-api.patch

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

From report at bugs.python.org  Wed Jun  3 00:26:10 2015
From: report at bugs.python.org (Daniel)
Date: Tue, 02 Jun 2015 22:26:10 +0000
Subject: [New-bugs-announce] [issue24366] Simple indentation
Message-ID: <1433283970.95.0.861661990338.issue24366@psf.upfronthosting.co.za>


Changes by Daniel <danielciugurean at yahoo.com>:


----------
files: indent.patch
keywords: patch
nosy: li4ick
priority: normal
severity: normal
status: open
title: Simple indentation
versions: Python 3.6
Added file: http://bugs.python.org/file39597/indent.patch

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

From report at bugs.python.org  Wed Jun  3 00:47:06 2015
From: report at bugs.python.org (ppperry)
Date: Tue, 02 Jun 2015 22:47:06 +0000
Subject: [New-bugs-announce] [issue24367] Idle hangs when you close the
	debugger while debugging
Message-ID: <1433285226.41.0.804518988574.issue24367@psf.upfronthosting.co.za>


New submission from ppperry:

[DEBUG ON]
>>> some_code
(debugger closed before pressing any buttons)
[DEBUG OFF]
>>> more_code
(no response)

----------
components: IDLE
messages: 244707
nosy: kbk, ppperry, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Idle hangs when you close the debugger while debugging
type: behavior

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

From report at bugs.python.org  Wed Jun  3 02:02:42 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 03 Jun 2015 00:02:42 +0000
Subject: [New-bugs-announce] [issue24368] Some C OrderedDict methods need to
 support keyword arguments.
Message-ID: <1433289762.01.0.562215924476.issue24368@psf.upfronthosting.co.za>


New submission from Eric Snow:

Several methods were implemented using PyArg_UnpackTuple and need to use PyArg_ParseTupleAndKeywords instead.

----------
assignee: eric.snow
components: Library (Lib)
messages: 244716
nosy: eric.snow
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Some C OrderedDict methods need to support keyword arguments.
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun  3 02:12:18 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 03 Jun 2015 00:12:18 +0000
Subject: [New-bugs-announce] [issue24369] Using OrderedDict.move_to_end
 during iteration is problematic.
Message-ID: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za>


New submission from Eric Snow:

While the dict/OrderedDict iterators already check for additions and deletions, using the OrderedDict.move_to_end during iteration can lead to surprising results.

The following results in an infinite loop:

    od = OrderedDict.fromkeys('abc')
    last = None
    for k in od:
        if last is not None:
            od.move_to_end(last)
        last = k

Ideally we could disallow changing order during iteration, just like we disallow deletion.  Since we've gone 3 minor versions already, would it be too late to break backward compatibility on this point?

----------
components: Library (Lib)
messages: 244718
nosy: eric.snow, rhettinger
priority: high
severity: normal
stage: test needed
status: open
title: Using OrderedDict.move_to_end during iteration is problematic.
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun  3 05:01:20 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 03 Jun 2015 03:01:20 +0000
Subject: [New-bugs-announce] [issue24370] OrderedDict behavior is unclear
	with misbehaving keys.
Message-ID: <1433300480.06.0.538096094872.issue24370@psf.upfronthosting.co.za>


New submission from Eric Snow:

How well does OrderedDict need to behave in the face of keys with unstable hashes (e.g. define __hash__ with varying results across calls)?  I would expect the behavior to be undefined (though non-crashing).  Here's an example of a misbehaving key:

    class Key:
        def __hash__(self):
            return randrange(10000)

FWIW, dict does pretty well even with bad keys.  The pure Python OrderedDict does okay.

----------
assignee: eric.snow
components: Library (Lib)
messages: 244727
nosy: eric.snow, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: OrderedDict behavior is unclear with misbehaving keys.
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun  3 09:34:28 2015
From: report at bugs.python.org (Yavuz Selim Komur)
Date: Wed, 03 Jun 2015 07:34:28 +0000
Subject: [New-bugs-announce] [issue24371] configparser hate dot in option
	like eth2.6
Message-ID: <1433316868.88.0.0222677980936.issue24371@psf.upfronthosting.co.za>


New submission from Yavuz Selim Komur:

[remember]
eth2.6 = True
eth5 = True



eth5 correct but eth2.6 return exception

----------
components: Extension Modules, Library (Lib)
messages: 244730
nosy: Yavuz Selim Komur
priority: normal
severity: normal
status: open
title: configparser hate dot in option like eth2.6
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jun  3 15:10:46 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Jun 2015 13:10:46 +0000
Subject: [New-bugs-announce] [issue24372] Documentation for
 ssl.wrap_socket's ssl_version parameter is odd
Message-ID: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

The documentation for ssl.wrap_socket()'s ssl_version parameter says "ssl_version={see docs}". But as far as I can tell, there's no reason not to document it as PROTOCOL_SSLv23, since that's what it actually is in the code.

My use case is that I'm producing a utility function for an RFC-5804 Manage Sieve client, which implements starttls(). I want to expose most of wrap_sockets()'s parameters, and pass them in to ssl.wrap_socket() itself. In order to do so, I need to specify the default values to match wrap_socket(). But ssl_version's default isn't documented.

Is the reason to allow us to change the default in a bug fix release? If that's the case, I suggest creating a sentinel value, like ssl.DEFAULT_PROTOCOL, and have that be the documented default. Then I could declare my parameter as defaulting to ssl.DEFAULT_PROTOCOL, pass it in to ssl.wrap_socket(), and have it use the "current" default.

If that's a desirable solution, I'll happily write a patch. If so, it would just apply to 3.6, but if we just want to document the actual value of ssl_version, then it would apply to the versions I've selected.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 244742
nosy: docs at python, eric.smith
priority: low
severity: normal
status: open
title: Documentation for ssl.wrap_socket's ssl_version parameter is odd
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun  3 15:21:01 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 03 Jun 2015 13:21:01 +0000
Subject: [New-bugs-announce] [issue24373] Use traverse & finalize in
	xxlimited and in PEP 489 tests
Message-ID: <1433337661.83.0.639894570386.issue24373@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

The example object in the xxlimited module can be part of a reference loop (it can contain itself), so it needs GC and tp_traverse.

The tp_dealloc hook was incorrect, and a correct version would be difficult to generalize for something more complicated than a example class (#16690; [0]). It's better to avoid dealloc and show off tp_finalize.

Same for the class in _testmultiphase (PEP 489 tests), which is based on xxlimited. The incorrect dealloc is causing the reference leak mentioned in #24268.

The Xxo object also wasn't actually added to the module.

Here is a patch to fix these.

[0] https://mail.python.org/pipermail/python-dev/2015-June/140422.html

----------
components: Extension Modules
files: xxlimited-finalize.patch
keywords: patch
messages: 244743
nosy: encukou, ncoghlan
priority: normal
severity: normal
status: open
title: Use traverse & finalize in xxlimited and in PEP 489 tests
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39605/xxlimited-finalize.patch

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

From report at bugs.python.org  Wed Jun  3 16:11:59 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Jun 2015 14:11:59 +0000
Subject: [New-bugs-announce] [issue24374] Plug refleak in
	set_coroutine_wrapper
Message-ID: <1433340719.96.0.108674882489.issue24374@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Code to raise RuntimeError introduced in issue24342 has some refleaks.  Please review the attached patch.

----------
assignee: yselivanov
components: Interpreter Core
files: set_coro.patch
keywords: patch
messages: 244749
nosy: ncoghlan, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Plug refleak in set_coroutine_wrapper
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39607/set_coro.patch

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

From report at bugs.python.org  Wed Jun  3 16:49:27 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Jun 2015 14:49:27 +0000
Subject: [New-bugs-announce] [issue24375] Performance regression relative to
	2.7
Message-ID: <1433342967.51.0.80560077079.issue24375@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Attached (t.py) is a random script that I stumbled upon pretty randomly on the internet -- someone used it to test different languages VMs performance.

The interesting thing is that 2.7 runs it 20-30% faster than 3.4 & 3.5 consistently.  The script does not involve any unicode data manipulation, it's mostly abount float arithmetic and function calls.

----------
components: Interpreter Core
files: t.py
messages: 244754
nosy: benjamin.peterson, haypo, ncoghlan, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: Performance regression relative to 2.7
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39609/t.py

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

From report at bugs.python.org  Wed Jun  3 17:53:47 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 03 Jun 2015 15:53:47 +0000
Subject: [New-bugs-announce] [issue24376] xxlimited.c errors when building
	32 and 64 bit on Windows
Message-ID: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

5>..\Modules\xxlimited.c(268): error C2061: syntax error : identifier 'xx_slots'
5>..\Modules\xxlimited.c(268): error C2059: syntax error : ';'
5>..\Modules\xxlimited.c(268): error C3409: empty attribute block is not allowed
5>..\Modules\xxlimited.c(268): error C2513: '/*global*/ ' : no variable declared before '='
5>..\Modules\xxlimited.c(269): error C2065: 'Py_mod_exec' : undeclared identifier
5>..\Modules\xxlimited.c(279): error C2065: 'xx_slots' : undeclared identifier
5>..\Modules\xxlimited.c(283): error C2099: initializer is not a constant
5>..\Modules\xxlimited.c(290): warning C4013: 'PyModuleDef_Init' undefined; assuming extern returning int
5>..\Modules\xxlimited.c(290): warning C4047: 'return' : 'PyObject *' differs in levels of indirection from 'int'

I believe it's down to r46496.

----------
components: Windows
messages: 244764
nosy: BreamoreBoy, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: xxlimited.c errors when building 32 and 64 bit on Windows
type: compile error
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun  3 19:08:50 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 03 Jun 2015 17:08:50 +0000
Subject: [New-bugs-announce] [issue24377] Refleak in OrderedDict.__repr__
 when an item is not found.
Message-ID: <1433351330.67.0.565425708761.issue24377@psf.upfronthosting.co.za>


New submission from Eric Snow:

It should be a one-line fix.

----------
assignee: eric.snow
messages: 244775
nosy: eric.snow
priority: high
severity: normal
stage: needs patch
status: open
title: Refleak in OrderedDict.__repr__ when an item is not found.
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jun  4 07:06:36 2015
From: report at bugs.python.org (Alka Yadav)
Date: Thu, 04 Jun 2015 05:06:36 +0000
Subject: [New-bugs-announce] [issue24378] dir(dictobject) returns empty list
 when __getattribute__ is overriden in the class
Message-ID: <1433394396.84.0.259561149442.issue24378@psf.upfronthosting.co.za>


New submission from Alka Yadav:

When __getattribute__ method is overrriden in a class,then in case of calling 
an attribute not in class object should throw KeyError.

But when calling dir on classs object gives an empty list as dir(dictobject) 
calls dictobject.__getattribute__(dir) and it throws KeyError instead of AttributeError in dir annd it returns NULL upstream

So dir source code need to be fixed to catch KeyError appropriately.

----------
components: Library (Lib)
files: direrror.py
messages: 244798
nosy: alkayadavit07 at gmail.com
priority: normal
severity: normal
status: open
title: dir(dictobject) returns empty list when __getattribute__ is overriden in the class
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file39613/direrror.py

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

From report at bugs.python.org  Thu Jun  4 08:07:04 2015
From: report at bugs.python.org (Joe Jevnik)
Date: Thu, 04 Jun 2015 06:07:04 +0000
Subject: [New-bugs-announce] [issue24379] slice.literal notation
Message-ID: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>


New submission from Joe Jevnik:

I often find that when working with pandas and numpy I want to store slice objects in variables to pass around and re-use; however, the syntax for constructing a slice literal outside of an indexer is very different from the syntax used inside of a subscript. This patch proposes the following change:

    slice.literal

This would be a singleton instance of a class that looks like:

class sliceliteral(object):
    def __getitem__(self, key):
        return key


The basic idea is to provide an alternative constructor to 'slice' that uses the subscript syntax. This allows people to write more understandable code.

Consider the following examples:

reverse = slice(None, None, -1)
reverse = slice.literal[::-1]

all_rows_first_col = slice(None), slice(0)
all_rows_first_col = slice.literal[:, 0]

first_row_all_cols_but_last = slice(0), slice(None, -1)
first_row_all_cols_but_last = slice.literal[0, :-1]


Again, this is not intended to make the code shorter, instead, it is designed to make it more clear what the slice object your are constructing looks like.

Another feature of the new `literal` object is that it is not limited to just the creation of `slice` instances; instead, it is designed to mix slices and other types together. For example:

>>> slice.literal[0]
0
>>> slice.literal[0, 1]
(0, 1)
>>> slice.literal[0, 1:]
(0, slice(1, None, None)
>>> slice.literal[:, ..., ::-1]
(slice(None, None, None), Ellipsis, slice(None, None, -1)

These examples show that sometimes the subscript notation is much more clear that the non-subscript notation.
I believe that while this is trivial, it is very convinient to have on the slice type itself so that it is quickly available. This also prevents everyone from rolling their own version that is accesible in different ways (think Py_RETURN_NONE).
Another reason that chose this aproach is that it requires no change to the syntax to support.

There is a second change proposed here and that is to 'slice.__repr__'. This change makes the repr of a slice object match the new literal syntax to make it easier to read.

>>> slice.literal[:]
slice.literal[:]
>>> slice.literal[1:]
slice.literal[1:]
>>> slice.literal[1:-1]
slice.literal[1:-1]
>>> slice.literal[:-1]
slice.literal[:-1]
>>> slice.literal[::-1]
slice.literal[::-1]

This change actually affects old behaviour so I am going to upload it as a seperate patch. I understand that the change to repr much be less desirable than the addition of 'slice.literal'

----------
components: Interpreter Core
files: slice.patch
keywords: patch
messages: 244801
nosy: llllllllll
priority: normal
severity: normal
status: open
title: slice.literal notation
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file39614/slice.patch

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

From report at bugs.python.org  Thu Jun  4 16:20:59 2015
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 04 Jun 2015 14:20:59 +0000
Subject: [New-bugs-announce] [issue24380] Got warning when compiling
	_scproxy.c on Mac
Message-ID: <1433427659.62.0.118183885403.issue24380@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Got this warning when compiling Python on Mac:

building '_scproxy' extension
gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/Users/sky/Code/python/cpython/Include -I/Users/sky/Code/python/cpython -c /Users/sky/Code/python/cpython/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_scproxy.o
/Users/sky/Code/python/cpython/Modules/_scproxy.c:74:10: warning: comparison of address of 'kSCPropNetProxiesExcludeSimpleHostnames' not equal to a null pointer is
      always true [-Wtautological-pointer-compare]
    if (&kSCPropNetProxiesExcludeSimpleHostnames != NULL) {
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ~~~~
/System/Library/Frameworks/SystemConfiguration.framework/Headers/SCSchemaDefinitions.h:3812:17: note: expanded from macro 'kSCPropNetProxiesExcludeSimpleHostnames'
          SC_SCHEMA_KV(kSCPropNetProxiesExcludeSimpleHostnames          \
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/SystemConfiguration.framework/Headers/SCSchemaDefinitions.h:469:31: note: expanded from macro 'SC_SCHEMA_KV'
  #define SC_SCHEMA_KV(k,v,t)   k
                                ^
1 warning generated.
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.9-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_scproxy.o -L/usr/local/lib -o build/lib.macosx-10.9-x86_64-3.6-pydebug/_scproxy.cpython-36dm-darwin.so -framework SystemConfiguration -framework CoreFoundation

I am not sure though whether the patch is correct solution. But anyway....

----------
components: Macintosh
files: fix_scproxy_compile_warning.patch
keywords: patch
messages: 244824
nosy: ned.deily, ronaldoussoren, vajrasky
priority: normal
severity: normal
status: open
title: Got warning when compiling _scproxy.c on Mac
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39617/fix_scproxy_compile_warning.patch

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

From report at bugs.python.org  Thu Jun  4 16:44:05 2015
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 04 Jun 2015 14:44:05 +0000
Subject: [New-bugs-announce] [issue24381] Got warning when compiling ffi.c
	on Mac
Message-ID: <1433429045.53.0.896226238413.issue24381@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

On my OS X Yosemite 10.10.3, I got this warning when compiling Modules/_ctypes/libffi_osx/ffi.c.

gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I_ctypes/darwin -I/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/include -I/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/powerpc -I./Include -I. -IInclude -I/usr/local/include -I/Users/sky/Code/python/cpython/Include -I/Users/sky/Code/python/cpython -c /Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/ffi.c -o build/temp.macosx-10.9-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/ffi.o -DMACOSX
/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/ffi.c:108:1: warning: unused function 'struct_on_stack' [-Wunused-function]
struct_on_stack(
^
1 warning generated.

Here is the patch that I think can fix the warning.

----------
components: Macintosh
files: fix_ffi_compile_warning.patch
keywords: patch
messages: 244825
nosy: ned.deily, ronaldoussoren, vajrasky
priority: normal
severity: normal
status: open
title: Got warning when compiling ffi.c on Mac
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39618/fix_ffi_compile_warning.patch

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

From report at bugs.python.org  Thu Jun  4 17:17:50 2015
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 04 Jun 2015 15:17:50 +0000
Subject: [New-bugs-announce] [issue24382] Fail to build time module on Mac
Message-ID: <1433431070.5.0.947300140334.issue24382@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

On my OSX Yosemite 10 with GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), I fail to build time module.

Failed to build these modules:
time

Here is the patch to fix the compile error.

----------
components: Macintosh
files: fix_fail_build_time_module.patch
keywords: patch
messages: 244827
nosy: ned.deily, ronaldoussoren, vajrasky
priority: normal
severity: normal
status: open
title: Fail to build time module on Mac
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file39619/fix_fail_build_time_module.patch

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

From report at bugs.python.org  Thu Jun  4 17:38:14 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Jun 2015 15:38:14 +0000
Subject: [New-bugs-announce] [issue24383] consider implementing __await__ on
 concurrent.futures.Future
Message-ID: <1433432294.12.0.421609125243.issue24383@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
assignee: yselivanov
components: Library (Lib), asyncio
nosy: gvanrossum, haypo, scoder, yselivanov
priority: normal
severity: normal
status: open
title: consider implementing __await__ on concurrent.futures.Future
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jun  4 22:12:55 2015
From: report at bugs.python.org (floyd)
Date: Thu, 04 Jun 2015 20:12:55 +0000
Subject: [New-bugs-announce] [issue24384] difflib.SequenceMatcher faster
 quick_ratio with lower bound specification
Message-ID: <1433448775.15.0.914528193485.issue24384@psf.upfronthosting.co.za>


New submission from floyd:

I guess a lot of users of difflib call the SequenceMatcher in the following way (where a and b often have different lengths):

if difflib.SequenceMatcher.quick_ratio(None, a, b) >= threshold:

However, for this use case the current quick_ratio is quite a performance loss. Therefore I propose to add an additional, optimized version quick_ratio_ge which would be called like this:

if difflib.SequenceMatcher.quick_ratio_ge(None, a, b, threshold):

As we are able to calculate upper bounds for threshold depending on the lengths of a and b this function would return much faster in a lot of cases.

An example of how quick_ratio_ge could be implemented is attached.

----------
components: Library (Lib)
files: difflib_SequenceMatcher_quick_ratio_ge.py
messages: 244840
nosy: floyd
priority: normal
severity: normal
status: open
title: difflib.SequenceMatcher faster quick_ratio with lower bound specification
type: enhancement
Added file: http://bugs.python.org/file39625/difflib_SequenceMatcher_quick_ratio_ge.py

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

From report at bugs.python.org  Thu Jun  4 22:52:13 2015
From: report at bugs.python.org (Jan Harkes)
Date: Thu, 04 Jun 2015 20:52:13 +0000
Subject: [New-bugs-announce] [issue24385] libpython27.a in python-2.7.10
 i386 (windows msi release) contains 64-bit objects
Message-ID: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za>


New submission from Jan Harkes:

mingw32 fails to link with libpython27.a fails with the following error

/cygdrive/C/Python27/libs/libpython27.a: error adding symbols: File format not recognized

extracting all the objects from libpython27.a and checking them with objdump shows that two objects (dmmet.o and dmmeh.o) are not recognized, file returns 'data' for their file types.

objdump from a 64-bit version of mingw recognizes these as pe-x86-64.

----------
components: Library (Lib)
messages: 244842
nosy: Jan Harkes
priority: normal
severity: normal
status: open
title: libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  5 01:41:44 2015
From: report at bugs.python.org (Graham Oliver)
Date: Thu, 04 Jun 2015 23:41:44 +0000
Subject: [New-bugs-announce] [issue24386] Bug Tracker emails going to gmail
	spam
Message-ID: <1433461304.02.0.848740275785.issue24386@psf.upfronthosting.co.za>


New submission from Graham Oliver:

I noticed that when I created an issue in this Bug Tracjer all of the associated emails were ending up in my gmail spam. '...in violation of Google's recommended email sender guidelines.' An explanatory link sends me to
https://support.google.com/mail/answer/81126?hl=en-GB#authentication
Cheers
g

----------
components: email
messages: 244849
nosy: Graham.Oliver, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Bug Tracker emails going to gmail spam
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Jun  5 14:21:48 2015
From: report at bugs.python.org (CT Radu)
Date: Fri, 05 Jun 2015 12:21:48 +0000
Subject: [New-bugs-announce] [issue24387] json.loads should be idempotent
 when the argument is a dictionary
Message-ID: <1433506908.4.0.832946693119.issue24387@psf.upfronthosting.co.za>


New submission from CT Radu:

Currently, json.loads expects a string as input and is expected to return a dictionary or raise an exception.

Proposal:
If the first argument of json.loads is a dictionary
return that dictionary, instead of raising a TypeError as it happens now.

There are some use cases where json.loads would be applied multiple times to the same object. Once the string has been parsed once, it shouldn't be reloaded.

----------
components: Library (Lib)
messages: 244864
nosy: CT Radu
priority: normal
severity: normal
status: open
title: json.loads should be idempotent when the argument is a dictionary
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jun  6 01:10:28 2015
From: report at bugs.python.org (Ed Maste)
Date: Fri, 05 Jun 2015 23:10:28 +0000
Subject: [New-bugs-announce] [issue24388] Python readline module crashes in
 history_get on FreeBSD with libedit
Message-ID: <1433545828.57.0.0902862993292.issue24388@psf.upfronthosting.co.za>


New submission from Ed Maste:

I encountered a segfault in Python's call_readline from LLDB on FreeBSD, with libedit. There is a fix for this issue already in readline.c, but under #ifdef __APPLE__

Backtrace:

(lldb) target create "/data/emaste/src/llvm/build/bin/lldb" --core "lldb-3.7.0.core"
Core file '/tank/emaste/projects/lldb-talk/demo/lldb-3.7.0.core' (x86_64) was loaded.
(lldb) bt
* thread #1: tid = 0, 0x0000000809706dcd readline.so`call_readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 397 at readline.c:1132, name = 'lldb-3.7.0', stop reason = signal SIGSEGV
  * frame #0: 0x0000000809706dcd readline.so`call_readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 397 at readline.c:1132
    frame #1: 0x0000000805c48f1f libpython2.7.so.1`PyOS_Readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 383 at myreadline.c:207
    frame #2: 0x0000000805d7f94f libpython2.7.so.1`builtin_raw_input(self=0x0000000000000000, args=0x000000080bec1df0) + 639 at bltinmodule.c:2060
    frame #3: 0x0000000805cce5c6 libpython2.7.so.1`PyCFunction_Call(func=0x00000008007b78d0, arg=0x000000080bec1df0, kw=0x0000000000000000) + 166 at methodobject.c:81
    frame #4: 0x0000000805d992aa libpython2.7.so.1`call_function(pp_stack=0x00007fffffffbcd0, oparg=1) + 1754 at ceval.c:4033
    frame #5: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x0000000806ecfdf0, throwflag=0) + 51160 at ceval.c:2679
    frame #6: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0000000805a6af60, globals=0x0000000806f9a580, locals=0x0000000000000000, args=0x000000080a06c670, argcount=2, kws=0x000000080a06c680, kwcount=0, defs=0x0000000805aaeda8, defcount=1, closure=0x0000000000000000) + 5284 at ceval.c:3265
    frame #7: 0x0000000805d9c2b6 libpython2.7.so.1`fast_function(func=0x0000000806f7da38, pp_stack=0x00007fffffffc520, n=2, na=2, nk=0) + 822 at ceval.c:4129
    frame #8: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffc520, oparg=1) + 2296 at ceval.c:4054
    frame #9: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080a06c4b0, throwflag=0) + 51160 at ceval.c:2679
    frame #10: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0000000805a5ebf0, globals=0x0000000806f9a580, locals=0x0000000000000000, args=0x000000080a06c3e0, argcount=2, kws=0x000000080a06c3f0, kwcount=0, defs=0x0000000805aaecc8, defcount=1, closure=0x0000000000000000) + 5284 at ceval.c:3265
    frame #11: 0x0000000805d9c2b6 libpython2.7.so.1`fast_function(func=0x0000000806f7d8e8, pp_stack=0x00007fffffffcd70, n=2, na=2, nk=0) + 822 at ceval.c:4129
    frame #12: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffcd70, oparg=1) + 2296 at ceval.c:4054
    frame #13: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080a06c230, throwflag=0) + 51160 at ceval.c:2679
    frame #14: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0000000805a869e0, globals=0x0000000806f9a580, locals=0x0000000000000000, args=0x000000080a06b9f8, argcount=0, kws=0x000000080a06b9f8, kwcount=2, defs=0x00000008009af688, defcount=3, closure=0x0000000000000000) + 5284 at ceval.c:3265
    frame #15: 0x0000000805d9c2b6 libpython2.7.so.1`fast_function(func=0x0000000806f7d300, pp_stack=0x00007fffffffd5c0, n=4, na=0, nk=2) + 822 at ceval.c:4129
    frame #16: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffd5c0, oparg=512) + 2296 at ceval.c:4054
    frame #17: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080a06b830, throwflag=0) + 51160 at ceval.c:2679
    frame #18: 0x0000000805d9c16a libpython2.7.so.1`fast_function(func=0x0000000806f9d300, pp_stack=0x00007fffffffdbd0, n=1, na=1, nk=0) + 490 at ceval.c:4119
    frame #19: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffdbd0, oparg=1) + 2296 at ceval.c:4054
    frame #20: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080098c9c0, throwflag=0) + 51160 at ceval.c:2679
    frame #21: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x00000008008ffa90, globals=0x00000008007d8580, locals=0x00000008007d8580, args=0x0000000000000000, argcount=0, kws=0x0000000000000000, kwcount=0, defs=0x0000000000000000, defcount=0, closure=0x0000000000000000) + 5284 at ceval.c:3265
    frame #22: 0x0000000805d857a5 libpython2.7.so.1`PyEval_EvalCode(co=0x00000008008ffa90, globals=0x00000008007d8580, locals=0x00000008007d8580) + 85 at ceval.c:667
    frame #23: 0x0000000805dd4a15 libpython2.7.so.1`run_mod(mod=0x000000080a14f128, filename=0x0000000805e22022, globals=0x00000008007d8580, locals=0x00000008007d8580, flags=0x0000000000000000, arena=0x000000080a027800) + 101 at pythonrun.c:1371
    frame #24: 0x0000000805dd50a4 libpython2.7.so.1`PyRun_StringFlags(str=0x000000080a0ff820, start=257, globals=0x00000008007d8580, locals=0x00000008007d8580, flags=0x0000000000000000) + 148 at pythonrun.c:1334
    frame #25: 0x0000000805dd4f54 libpython2.7.so.1`PyRun_SimpleStringFlags(command=0x000000080a0ff820, flags=0x0000000000000000) + 100 at pythonrun.c:975
    frame #26: 0x0000000802085fa4 liblldb.so.3.7`IOHandlerPythonInterpreter::Run() + 324
    frame #27: 0x0000000801f78c12 liblldb.so.3.7`lldb_private::Debugger::ExecuteIOHandlers() + 162
    frame #28: 0x000000080206635e liblldb.so.3.7`lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRunOptions&) + 126
    frame #29: 0x00000008012bc79f liblldb.so.3.7`lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 63
    frame #30: 0x0000000000406546 lldb`Driver::MainLoop() + 2454
    frame #31: 0x0000000000406a17 lldb`main + 439
    frame #32: 0x000000000040362f lldb`_start + 367

frame #0: 0x0000000809706dcd readline.so`call_readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 397 at readline.c:1132
   1129                 line = history_get(length + libedit_history_start - 1)->line;
   1130             } else
   1131 #endif /* __APPLE__ */
-> 1132             line = history_get(length)->line;
   1133         else
   1134             line = "";
   1135         if (strcmp(p, line))

It looks like a straightforward s/#ifdef __APPLE__/#if defined(__APPLE__) || defined(__FreeBSD__)/ fixes the issue (as in the attached proof of concept patch).

----------
components: Extension Modules
files: readline.diff
keywords: patch
messages: 244877
nosy: emaste
priority: normal
severity: normal
status: open
title: Python readline module crashes in history_get on FreeBSD with libedit
versions: Python 2.7
Added file: http://bugs.python.org/file39635/readline.diff

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

From report at bugs.python.org  Sat Jun  6 04:07:48 2015
From: report at bugs.python.org (Harvesting Ore)
Date: Sat, 06 Jun 2015 02:07:48 +0000
Subject: [New-bugs-announce] [issue24389] idle launches in cmd but not from
	any other method.
Message-ID: <1433556468.4.0.207321673571.issue24389@psf.upfronthosting.co.za>


New submission from Harvesting Ore:

so i've seen dozens of fixes for this, but none of them worked for me. i went to cmd prompt put in the directory

c:python31\lib\idlelib\idle.py which launched the program but gave me the following errors...

Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist.
Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist.
Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist.

please note that idle for 3.1.1 works when launched from cmd prompt but not via the shortcuts or from the menu. i've made double sure that 'run as administrator' is checked in properties and compatability is set for xp sp 1. 

i have made absolutely no changes to my system aside from the typical windows updates rubbish.

----------
components: IDLE
messages: 244884
nosy: Harvesting Ore
priority: normal
severity: normal
status: open
title: idle launches in cmd but not from any other method.
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Jun  6 11:20:26 2015
From: report at bugs.python.org (Ivan Bykov)
Date: Sat, 06 Jun 2015 09:20:26 +0000
Subject: [New-bugs-announce] [issue24390] Python 3.4.3 64 bits is not "high
	dpi aware"
Message-ID: <1433582426.79.0.462452103713.issue24390@psf.upfronthosting.co.za>


New submission from Ivan Bykov:

Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> SM_CYSCREEN = 1
>>> from ctypes import windll
>>> GetSystemMetrics = windll.user32.GetSystemMetrics
>>> GetSystemMetrics(SM_CYSCREEN)
1067
>>> 'really this value is 1600'
>>> 'executable must be labeled as "high dpi aware"'

----------
components: Windows
messages: 244894
nosy: ivb, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.4.3 64 bits is not "high dpi aware"
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun  6 12:21:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jun 2015 10:21:42 +0000
Subject: [New-bugs-announce] [issue24391] Better repr for threading objects
Message-ID: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds makes reprs of threading objects Semaphore, BoundedSemaphore, Event, and Barrier expose their public states. This will help for debugging.

Examples:

<Semaphore: 10 at 0xb710ec8c>
<BoundedSemaphore: 7/10 at 0xb6ff1d6c>
<unset Event at 0xb710ec8c>
<set Event at 0xb710ec8c>
<Barrier: 0/10 at 0xb6ff1d6c>
<Barrier: 3/10 at 0xb6ff1d6c>
<broken Barrier: 3/10 at 0xb6ff1d6c>

----------
components: Library (Lib)
messages: 244896
nosy: berker.peksag, brett.cannon, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Better repr for threading objects
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Jun  6 13:04:05 2015
From: report at bugs.python.org (Padmanabhan Tr)
Date: Sat, 06 Jun 2015 11:04:05 +0000
Subject: [New-bugs-announce] [issue24392] pop functioning
Message-ID: <1433588645.87.0.239082859229.issue24392@psf.upfronthosting.co.za>


New submission from Padmanabhan Tr:

I have attached the python sequence & my comments. I use Python version 3.4.2
I guess a bug need be corrected

----------
components: Regular Expressions
files: bug_a
messages: 244897
nosy: Padmanabhan.Tr, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: pop functioning
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file39638/bug_a

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

From report at bugs.python.org  Sat Jun  6 14:48:56 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=)
Date: Sat, 06 Jun 2015 12:48:56 +0000
Subject: [New-bugs-announce] [issue24393] Test urllib2_localnet fails
 depending on host proxy configuration
Message-ID: <1433594936.74.0.27552580361.issue24393@psf.upfronthosting.co.za>


New submission from ?tienne Buira:

test_urllib2_localnet make non-explicit use of host configured http_proxy and no_proxy, that will fail the test depending on their contents.

----------
components: Tests
files: test_urllib2_localnet_proxy_conf.diff
keywords: patch
messages: 244901
nosy: eacb
priority: normal
severity: normal
status: open
title: Test urllib2_localnet fails depending on host proxy configuration
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file39639/test_urllib2_localnet_proxy_conf.diff

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

From report at bugs.python.org  Sat Jun  6 16:00:50 2015
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 06 Jun 2015 14:00:50 +0000
Subject: [New-bugs-announce] [issue24394] TypeError: popitem() takes no
	keyword arguments
Message-ID: <1433599250.82.0.983830780418.issue24394@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Python 3.5.0b2 (v3.5.0b2:7a088af5615b, May 31 2015, 06:22:19) [MSC v.1900 64 bit (AMD64)] on win32  
Type "help", "copyright", "credits" or "license" for more information.                              
>>> import collections                                                                              
>>> o=collections.OrderedDict()                                                                     
>>> o.popitem(last=True)                                                                            
Traceback (most recent call last):                                                                  
  File "<stdin>", line 1, in <module>                                                               
TypeError: popitem() takes no keyword arguments

----------
messages: 244906
nosy: cool-RR
priority: normal
severity: normal
status: open
title: TypeError: popitem() takes no keyword arguments

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

From report at bugs.python.org  Sat Jun  6 17:22:59 2015
From: report at bugs.python.org (Hasan Diwan)
Date: Sat, 06 Jun 2015 15:22:59 +0000
Subject: [New-bugs-announce] [issue24395] webbrowser.py update to use
	argparse.py
Message-ID: <1433604179.81.0.192966490206.issue24395@psf.upfronthosting.co.za>


New submission from Hasan Diwan:

The webbrowser module uses getopt, which needs to be ripped out and replaced with argparse. The attached file does just this.

----------
components: Library (Lib)
files: webbrowser.py
messages: 244913
nosy: Hasan Diwan, georg.brandl
priority: normal
severity: normal
status: open
title: webbrowser.py update to use argparse.py
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file39641/webbrowser.py

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

From report at bugs.python.org  Sat Jun  6 18:47:47 2015
From: report at bugs.python.org (Madison May)
Date: Sat, 06 Jun 2015 16:47:47 +0000
Subject: [New-bugs-announce] [issue24396] Provide convenience function for
 paths relative to the current module
Message-ID: <1433609267.34.0.395735074965.issue24396@psf.upfronthosting.co.za>


New submission from Madison May:

I often find myself trying to access a file relative to the module I'm working on.  When this occurs, I'll often use something like the following:

```
os.path.abspath(os.path.join(os.path.dirname(__file__), "data/resource.pkl"))
```

I have good reason to believe that I'm not the only one, as searching for other examples of this code on github returns ~20k exact matches: https://github.com/search?utf8=%E2%9C%93&q=%22os.path.abspath%28os.path.join%28os.path.dirname%28__file__%29%22+&type=Code&ref=searchresults


Low priority, but a more concise way of achieving the same result would be much appreciated.

----------
components: Library (Lib)
messages: 244920
nosy: madison.may
priority: normal
severity: normal
status: open
title: Provide convenience function for paths relative to the current module
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jun  6 19:32:23 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=)
Date: Sat, 06 Jun 2015 17:32:23 +0000
Subject: [New-bugs-announce] [issue24397] Test asynchat makes wrong
	assumptions
Message-ID: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za>


New submission from ?tienne Buira:

Amount of data the server could not send back is not a reliable indication on how much data it received.

----------
components: Tests
files: test_asynchat_check_received_len_if_received_len_matters.diff
keywords: patch
messages: 244922
nosy: eacb
priority: normal
severity: normal
status: open
title: Test asynchat makes wrong assumptions
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39643/test_asynchat_check_received_len_if_received_len_matters.diff

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

From report at bugs.python.org  Sat Jun  6 20:13:52 2015
From: report at bugs.python.org (Christie)
Date: Sat, 06 Jun 2015 18:13:52 +0000
Subject: [New-bugs-announce] [issue24398] Update test_capi to use
	test.support.script_helper
Message-ID: <1433614432.33.0.0607159967244.issue24398@psf.upfronthosting.co.za>


New submission from Christie:

As described in Issue9517, many test modules do not make use of the helpers in script_helpers.py to invoke the python interpreter in a subprocess. Issue9517 will be broken down into several smaller issues so we can address smaller change sets.

This issue is to update test_capi.py to use script_helpers.py.

----------
messages: 244923
nosy: bobcatfish
priority: normal
severity: normal
status: open
title: Update test_capi to use test.support.script_helper
versions: Python 3.6

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

From report at bugs.python.org  Sat Jun  6 22:04:55 2015
From: report at bugs.python.org (Nathan Ringo)
Date: Sat, 06 Jun 2015 20:04:55 +0000
Subject: [New-bugs-announce] [issue24399] Backports Arch Linux support for
 platform.linux_distribution()
Message-ID: <1433621095.46.0.0189003442326.issue24399@psf.upfronthosting.co.za>


New submission from Nathan Ringo:

On Arch Linux, running `python2 -c "import platform; print platform.linux_distribution()"'

Before patch: ('', '', '')
After patch: ('arch', 'Arch', 'Linux')

This matches the Python 3 behavior:
`python3 -c "import platform; print(platform.linux_distribution())"'

('arch', 'Arch', 'Linux')

----------
files: support_dist_arch.patch
keywords: patch
messages: 244925
nosy: Nathan Ringo
priority: normal
severity: normal
status: open
title: Backports Arch Linux support for platform.linux_distribution()
versions: Python 2.7
Added file: http://bugs.python.org/file39644/support_dist_arch.patch

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

From report at bugs.python.org  Sun Jun  7 07:06:53 2015
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 07 Jun 2015 05:06:53 +0000
Subject: [New-bugs-announce] [issue24400] Awaitable ABC incompatible with
	functools.singledispatch
Message-ID: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za>


New submission from Ben Darnell:

The new collections.abc.Awaitable ABC relies on __instancecheck__, which makes it incompatible with functools.singledispatch (singledispatch works based on args[0].__class__; any instance-level information is discarded). This surprised me because the first thing I tried to do with Awaitable was add it to my singledispatch-based coroutine compatibility layer.

Ideally coroutine would be an actual subclass of generator, instead of a generator with an extra bit set on the instance that changes how it answers isinstance() checks. That would be a big change, though, so it might be better to just document that Awaitable is kind of unusual (if we weren't already in the beta period I might argue that the ABCs should be removed and we should just use the functions in the inspect module instead).

----------
components: asyncio
messages: 244942
nosy: Ben.Darnell, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Awaitable ABC incompatible with functools.singledispatch
versions: Python 3.5

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

From report at bugs.python.org  Sun Jun  7 11:10:28 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sun, 07 Jun 2015 09:10:28 +0000
Subject: [New-bugs-announce] [issue24401] Windows 8.1 install gives DLL
 required to complete could not run
Message-ID: <1433668228.61.0.22658051744.issue24401@psf.upfronthosting.co.za>


New submission from Laura Creighton:

Another report from webmaster.  (I still don't have a windows machine).  Somebody tried to install 3.3, 3.4 or 3.5 and got this error.  I asked
them to try the Activestate installer.  That worked.  Thus Activestate
knows to include something that users sometimes don't have, which we
do not. We probably should analyse this and include what we are missing.

----------
components: Installation, Windows
messages: 244948
nosy: lac, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows 8.1 install gives DLL required to complete could not run
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun  7 11:30:52 2015
From: report at bugs.python.org (Keita Kita)
Date: Sun, 07 Jun 2015 09:30:52 +0000
Subject: [New-bugs-announce] [issue24402] input() uses sys.__stdout__
 instead of sys.stdout for prompt
Message-ID: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>


New submission from Keita Kita:

On Python 3.4, input() does not use wrapped sys.stdout. For example, the following script should print "Wrapped stdout" by print() and input() because sys.stdout is replaced with Writer object.

--------
import io
import sys


class Writer:
    def __getattr__(self, name):
        return getattr(sys.__stdout__, name)

    def write(self, data):
        if data != '\n':
            sys.__stdout__.write('Wrapped stdout\n')

    def fileno():
        raise OSError()


sys.stdout = Writer()

print('print')
input('input')
------

But the script does not print "Wrapped stdout" as prompt of input(). The script
prints the following.

-----
Wrapped stdout
input
----

Although, when sys.stdin is also wrapped, input() will use sys.stdout for prompt. For example, the following script prints "Wrapped stdout" by print() and input().

----
import io
import sys


class Writer:
    def __getattr__(self, name):
        return getattr(sys.__stdout__, name)

    def write(self, data):
        if data != '\n':
            sys.__stdout__.write('Wrapped stdout\n')

    def fileno():
        raise OSError()


class Reader:
    def __getattr__(self, name):
        return getattr(sys.__stdin__, name)

    def read(self, size):
        return sys.__stdin__.read(size)

    def fileno():
        raise OSError()


sys.stdout = Writer()
sys.stdin = Reader()

print('print')
input('input')
----

The script prints the following.

-----
Wrapped stdout
Wrapped stdout
----

----------
components: Interpreter Core
messages: 244949
nosy: Keita Kita
priority: normal
severity: normal
status: open
title: input() uses sys.__stdout__ instead of sys.stdout for prompt
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  7 12:58:41 2015
From: report at bugs.python.org (priska)
Date: Sun, 07 Jun 2015 10:58:41 +0000
Subject: [New-bugs-announce] [issue24403] Missing fixer for changed round()
	behavior
Message-ID: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za>


New submission from priska:

The behavior of the round() function has changed between Python 2.x and Python3.x. 

>From the release notes of Python 3.0: "The round() function rounding strategy and return type have changed. Exact halfway cases are now rounded to the nearest even result instead of away from zero. (For example, round(2.5) now returns 2 rather than 3.) round(x[, n]) now delegates to x.__round__([n]) instead of always returning a float. It generally returns an integer when called with a single argument and a value of the same type as x when called with two arguments."

2to3 conversion does not take this into account and thereby changes code behavior.

Suggested translations:

round(n) -> float(math.floor(n + math.copysign(0.5, n)))

or 

round(n) -> float(math.trunc(n + math.copysign(0.5, n)))

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 244951
nosy: priska
priority: normal
severity: normal
status: open
title: Missing fixer for changed round() behavior
type: behavior

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

From report at bugs.python.org  Sun Jun  7 19:45:24 2015
From: report at bugs.python.org (Fabian)
Date: Sun, 07 Jun 2015 17:45:24 +0000
Subject: [New-bugs-announce] [issue24404] Python 2.7.0's BZ2File does not
	support with-statements
Message-ID: <1433699124.98.0.649145124993.issue24404@psf.upfronthosting.co.za>


New submission from Fabian:

I had a weird bug recently where someone tried to use the with-statement on a BZ2File. According to the documentation it was added in 2.7 and looking at https://hg.python.org/cpython/rev/5d5d9074f4ca it looks like it was added together with the support in gzip.

But after I've installed 2.7.0 I could use the with-statement on gzip but not in BZ2File:

Python 2.7 (r27:82500, Jun  7 2015, 19:01:29) 
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f:
...   c = f.read()
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __exit__

So I've installed 2.7.1 and sure enough it works there:

Python 2.7.1 (r271:86832, Jun  7 2015, 19:21:02) 
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f:
...   c = f.read()
... 
>>> 

I guess the documentation needs be updated that since Python 2.7.1 BZ2File supports the with-statement.

See also: https://phabricator.wikimedia.org/T101649

----------
assignee: docs at python
components: Documentation
messages: 244962
nosy: docs at python, xZise
priority: normal
severity: normal
status: open
title: Python 2.7.0's BZ2File does not support with-statements
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  8 13:21:15 2015
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 08 Jun 2015 11:21:15 +0000
Subject: [New-bugs-announce] [issue24405] Missing code markup in
	"Expressions" documentation
Message-ID: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za>


New submission from Gareth Rees:

The "Expressions" documentation contains the text:

> * Sets and frozensets define comparison operators to mean subset and superset
>  tests.  Those relations do not define total orderings (the two sets ``{1,2}``
>  and {2,3} are not equal, nor subsets of one another, nor supersets of one
>  another).

Here {2,3} should be marked up as code (like {1,2}) but is not.

----------
assignee: docs at python
components: Documentation
files: markup.patch
keywords: patch
messages: 244996
nosy: Gareth.Rees, docs at python
priority: normal
severity: normal
status: open
title: Missing code markup in "Expressions" documentation
type: enhancement
Added file: http://bugs.python.org/file39657/markup.patch

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

From report at bugs.python.org  Mon Jun  8 13:32:38 2015
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 08 Jun 2015 11:32:38 +0000
Subject: [New-bugs-announce] [issue24406] "Bulit-in Types" documentation
 doesn't explain how dictionaries are compared for equality
Message-ID: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za>


New submission from Gareth Rees:

The "Built-in Types" section of the library documentation does not explain how two dictionaries are compared for equality.

The place where this is documented is under "Comparisons" in the Language Reference:

> Mappings (dictionaries) compare equal if and only if they have the same (key, value) pairs.

but it is not obvious from the section on dictionaries in "Built-in Types" that this is where to look.

(Contrast with the situation for sequences and sets, where "Built-in Types" does explain how these objects are compared for equality.)

I suggest that the "Built-in Types" section should explain how two dictionaries are tested for equality.

----------
assignee: docs at python
components: Documentation
files: dict-equality.patch
keywords: patch
messages: 244998
nosy: Gareth.Rees, docs at python
priority: normal
severity: normal
status: open
title: "Bulit-in Types" documentation doesn't explain how dictionaries are compared for equality
type: enhancement
Added file: http://bugs.python.org/file39658/dict-equality.patch

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

From report at bugs.python.org  Mon Jun  8 13:57:05 2015
From: report at bugs.python.org (paul)
Date: Mon, 08 Jun 2015 11:57:05 +0000
Subject: [New-bugs-announce] [issue24407] Use after free in PyDict_merge
Message-ID: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za>


New submission from paul:

# PyDict_Merge:
# 
# 1       for (i = 0, n = DK_SIZE(other->ma_keys); i < n; i++) {
#             ...
# 3           entry = &other->ma_keys->dk_entries[i];
#             ...
# 2               if (insertdict(mp, entry->me_key,
#                                entry->me_hash,
#                                value) != 0)
#                     return -1;
#             ...
#         }
# 
# 1. n is set once 
# 2. it's possible to run a custom __eq__ method from inside the insertdict. 
#    __eq__ clears the "other" dict. "n" variables is now out of date
# 3. out of bounds read
# 
# CRASH:
# ------
#
# * thread #1: tid = 27715, 0x080d1c1d python`insertdict(mp=0xb71d66f4, key=0x61682044, hash=543582496, value=0xb71d6664) + 132 at dictobject.c:819, name = 'python', stop reason = invalid address (fault address: 0x61682050)
#     frame #0: 0x080d1c1d python`insertdict(mp=0xb71d66f4, key=0x61682044, hash=543582496, value=0xb71d6664) + 132 at dictobject.c:819
#    816      if (ep == NULL) {
#    817          return -1;
#    818      }
# -> 819      assert(PyUnicode_CheckExact(key) || mp->ma_keys->dk_lookup == lookdict);
#    820      Py_INCREF(value);
#    821      MAINTAIN_TRACKING(mp, key, value);
#    822      old_value = *value_addr;
#

----------
files: dict_merge.py
messages: 245001
nosy: pkt
priority: normal
severity: normal
status: open
title: Use after free in PyDict_merge
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file39659/dict_merge.py

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

From report at bugs.python.org  Mon Jun  8 15:22:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Jun 2015 13:22:17 +0000
Subject: [New-bugs-announce] [issue24408] tkinter.font.Font.measure() broken
	in 3.5
Message-ID: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za>


New submission from Martin Panter:

>>> import tkinter, tkinter.font
>>> tk = tkinter.Tk()
>>> tkinter.font.nametofont("TkHeadingFont").measure("string")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/proj/python/cpython/Lib/tkinter/font.py", line 154, in measure
    return self._root.tk.getint(self._call("font", "measure", self.name, *args))
AttributeError: 'Font' object has no attribute '_root'

This appears to be broken by revision cb80dd82d3da, Issue 23880, which included this change at the end of the measure() method:

-return int(self._call("font", "measure", self.name, *args))
+return self._root.tk.getint(self._call("font", "measure", self.name, *args))

The Font class does not have a ?_root? attribute.

----------
components: Tkinter
messages: 245003
nosy: serhiy.storchaka, vadmium
priority: normal
severity: normal
stage: needs patch
status: open
title: tkinter.font.Font.measure() broken in 3.5
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun  8 17:38:37 2015
From: report at bugs.python.org (nivin)
Date: Mon, 08 Jun 2015 15:38:37 +0000
Subject: [New-bugs-announce] [issue24409] PythonPROD abrt
Message-ID: <1433777917.0.0.0137238616785.issue24409@psf.upfronthosting.co.za>


New submission from nivin:

There is a cronjob running in every 3 minutes.For One or two days this works properly. After that Mysql service get crashed.Bulk data is inserted into database using the service . Following errors found in /var/log/messages  (OS : RHEL 6)


Jun  6 13:27:02 PythonPROD abrt: detected unhandled Python exception in '/var/www/html/CrossCDR/Cronjobs/cdrcollector/CdrCollector.py'
Jun  6 13:27:02 PythonPROD abrtd: New client connected
Jun  6 13:27:02 PythonPROD abrtd: Directory 'pyhook-2015-06-06-13:27:02-1796' creation detected
Jun  6 13:27:02 PythonPROD abrt-server[1800]: Saved Python crash dump of pid 1796 to /var/spool/abrt/pyhook-2015-06-06-13:27:02-1796
Jun  6 13:27:07 PythonPROD kernel: Bridge firewalling registered
Jun  6 13:28:07 PythonPROD abrtd: Sending an email...
Jun  6 13:28:07 PythonPROD abrtd: Email was sent to: root at localhost
Jun  6 13:28:07 PythonPROD abrtd: Duplicate: UUID
Jun  6 13:28:07 PythonPROD abrtd: DUP_OF_DIR: /var/spool/abrt/pyhook-2015-06-04-00:48:02-1797
Jun  6 13:28:07 PythonPROD abrtd: Deleting problem directory pyhook-2015-06-06-13:27:02-1796 (dup of pyhook-2015-06-04-00:48:02-1797)
Jun  6 13:28:07 PythonPROD abrtd: No actions are found for event 'notify-dup'

----------
messages: 245006
nosy: nivin
priority: normal
severity: normal
status: open
title: PythonPROD abrt
type: crash

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

From report at bugs.python.org  Mon Jun  8 17:50:47 2015
From: report at bugs.python.org (Steve Zelaznik)
Date: Mon, 08 Jun 2015 15:50:47 +0000
Subject: [New-bugs-announce] [issue24410] set.__eq__ returns False when it
 should return NotImplemented
Message-ID: <1433778647.83.0.662569129582.issue24410@psf.upfronthosting.co.za>


New submission from Steve Zelaznik:

[in] >>> d = {'x':3,'y':4,'z':5}
  [in] >>> set(d.items()) == d.viewitems()
 [out] >>> False
  [in] >>> d.viewitems() == set(d.items())
 [out] >>> True
  [in] >>> set(d.items()).__eq__(d.viewitems())
 [out] >>> False

The last line should return NotImplemented rather than False.  This problem seems to have been addressed in Python3.

----------
components: Build
messages: 245009
nosy: zelaznik
priority: normal
severity: normal
status: open
title: set.__eq__ returns False when it should return NotImplemented
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  8 20:15:29 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 08 Jun 2015 18:15:29 +0000
Subject: [New-bugs-announce] [issue24411] Drop redundant lock in queue.Queue
 methods qsize(), empty() and full()
Message-ID: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

Now those methods use lock for querying queue size, like

    def qsize(self):
        with self.mutex:
            return self._qsize()

The lock is not necessary because thread context switch may be done *after* returning from mutex protected code but *before* getting result by calling side.

All three methods (qsize(), empty() and full()) gives *approximated value*, so getting rid of lock doesn't make it less stringent.

----------
components: Library (Lib)
messages: 245029
nosy: asvetlov
priority: low
severity: normal
status: open
title: Drop redundant lock in queue.Queue methods qsize(), empty() and full()
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun  8 20:31:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jun 2015 18:31:39 +0000
Subject: [New-bugs-announce] [issue24412] setUpClass equivalent for
	addCleanup
Message-ID: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za>


New submission from R. David Murray:

Since tearDownClass isn't run if setUpClass fails, there is a need for the class level equivalent of addCleanup.  addClassCleanup?

----------
components: Library (Lib)
messages: 245030
nosy: ezio.melotti, michael.foord, r.david.murray, rbcollins
priority: normal
severity: normal
stage: needs patch
status: open
title: setUpClass equivalent for addCleanup
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Jun  8 23:04:25 2015
From: report at bugs.python.org (Richard Futrell)
Date: Mon, 08 Jun 2015 21:04:25 +0000
Subject: [New-bugs-announce] [issue24413] Inconsistent behavior between set
 and dict_keys/dict_items: for non-iterable object x,
 set().__or__(x) raises NotImplementedError,
 but {}.keys().__or__(x) raises TypeError
Message-ID: <1433797465.6.0.816569551411.issue24413@psf.upfronthosting.co.za>


Changes by Richard Futrell <futrell at mit.edu>:


----------
nosy: canjo
priority: normal
severity: normal
status: open
title: Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun  8 23:44:34 2015
From: report at bugs.python.org (debohman)
Date: Mon, 08 Jun 2015 21:44:34 +0000
Subject: [New-bugs-announce] [issue24414] MACOSX_DEPLOYMENT_TARGET set
	incorrectly by configure
Message-ID: <1433799874.27.0.587161975864.issue24414@psf.upfronthosting.co.za>


New submission from debohman:

MACOSX_DEPLOYMENT_TARGET is not set correctly when building the 2.7.10 sources.  This causes readline to not be included in the build.

This appears to already be fixed in 3.4.3.  I picked up the change to configure.ac from 3.4.3 and it resolved the problem.

I am building on 10.9.5.  In my case MACOSX_DEPLOYMENT_TARGET was chosen as 10.4.

The configuration options I am using are:

./configure --enable-shared

Attaching diffs.

----------
components: Build
files: configure.ac_diffs.txt
messages: 245038
nosy: debohman
priority: normal
severity: normal
status: open
title: MACOSX_DEPLOYMENT_TARGET set incorrectly by configure
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file39661/configure.ac_diffs.txt

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

From report at bugs.python.org  Tue Jun  9 14:30:06 2015
From: report at bugs.python.org (ABalmosan)
Date: Tue, 09 Jun 2015 12:30:06 +0000
Subject: [New-bugs-announce] [issue24415] SIGINT always reset to SIG_DFL by
	Py_Finalize()
Message-ID: <1433853006.37.0.519208037884.issue24415@psf.upfronthosting.co.za>


New submission from ABalmosan:

We use the Python lib as part of a larger process. This process sets its own signal handlers to achieve the expected behavior of the process.

We use Py_InitializeEx(0) to prevent Python to install its own signal handlers.

On process reconfigure we shutdown Python with Py_Finalize() to call Py_InitializeEx(0) anew. 

Even so Py_InitializeEx(0) did not touch any signal and especially not SIGINT, Py_Finalize() resets unconditionally SIGINT to SIG_DFL.

The result is that our process terminates immediately on SIGINT instead of execution its shutdown procedure which was handled by the orginal installed SIGINT handler.

The problem is visible in the python code in 

Modules/signalmodule.c:
static void
finisignal(void)
{
    int i;
    PyObject *func;

    PyOS_setsig(SIGINT, old_siginthandler);
    old_siginthandler = SIG_DFL;


In Python/pythonrun.c Py_InitializeEx()I find:

    if (install_sigs)
        initsigs(); /* Signal handling stuff, including initintr() */


Also I wonder by whom PyOS_InitInterrupts() is called. It would unconditionally install the Python signal handler even if Py_InitializeEx(0) was once executed.

----------
components: Interpreter Core
messages: 245060
nosy: ABalmosan
priority: normal
severity: normal
status: open
title: SIGINT always reset to SIG_DFL by Py_Finalize()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun  9 14:37:20 2015
From: report at bugs.python.org (Baptiste Mispelon)
Date: Tue, 09 Jun 2015 12:37:20 +0000
Subject: [New-bugs-announce] [issue24416] Return a namedtuple from
	date.isocalendar()
Message-ID: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za>


New submission from Baptiste Mispelon:

Currently, `date.isocalendar()` returns a plain tuple of (year, week, weekday).

It would be a bit more useful if this tuple could be made into a namedtuple (with fields year, week and weekday).

----------
components: Library (Lib)
messages: 245061
nosy: bmispelon
priority: normal
severity: normal
status: open
title: Return a namedtuple from date.isocalendar()
versions: Python 3.6

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

From report at bugs.python.org  Tue Jun  9 15:38:05 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 09 Jun 2015 13:38:05 +0000
Subject: [New-bugs-announce] [issue24417] Type-specific documentation for
	__format__ methods
Message-ID: <1433857085.94.0.53514781812.issue24417@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

I am only now just prying my fingers off printf-style string
formatting. The new syntax always seemed Perl-like to me, so I ignored
it. Finally, yesterday, I got some cheat sheet pointers from
comp.lang.python and dove in.

I hit a minor roadblock when I couldn't find any type-specific
documentation for the various __format__ methods. In the documentation
on the format() builtin
(https://docs.python.org/3.5/library/functions.html#format) I read,
"The interpretation of format_spec will depend on the type of the
value argument..." which led me to believe I would find something
about (for example) float.__format__ in the section on floats
(https://docs.python.org/3.5/library/stdtypes.html#typesnumeric).

I realize now that the documentation for many formats is in the string
documentation
(https://docs.python.org/3.5/library/string.html#formatspec), but I
think it would still be useful to have at least stubs in the
documentation for the __format__ method of the various builtin types,
even if all those stubs to is refer the reader to the string
documentation.

I started to work on a patch, but I quickly got myself confused about
where to describe <sometype>.__format__. Perhaps it's time that
stdtypes.rst is broken into multiple files, with the structure of the
documentation for the various builtin types made more uniform. For
instance, int and float have sections describing methods, while list,
tuple, set, and dict don't.

----------
assignee: docs at python
components: Documentation
messages: 245063
nosy: docs at python, skip.montanaro
priority: normal
severity: normal
status: open
title: Type-specific documentation for __format__ methods

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

From report at bugs.python.org  Tue Jun  9 20:01:53 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jun 2015 18:01:53 +0000
Subject: [New-bugs-announce] [issue24418] "make install" will not install
 pip if already present in user site-packages
Message-ID: <1433872913.68.0.595008906061.issue24418@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is what happens when building Python with conda-build (which implies doing "make install" with a custom prefix):


[...]
if test "xupgrade" != "xno"  ; then \
	case upgrade in \
		upgrade) ensurepip="--upgrade" ;; \
		install|*) ensurepip="" ;; \
	esac; \
	LD_LIBRARY_PATH=/home/antoine/miniconda3/conda-bld/work/cpython-default ./python -E -m ensurepip \
		$ensurepip --root=/ ; \
fi
Ignoring indexes: https://pypi.python.org/simple/
Requirement already up-to-date: setuptools in /home/antoine/.local/lib/python3.5/site-packages
Requirement already up-to-date: pip in /home/antoine/.local/lib/python3.5/site-packages
[...]


Note that conda-build *does* set PYTHONNOUSERSITE to make builds as isolated as possible, but the Python Makefile deliberately ignores it using "python -E"!

----------
components: Build
messages: 245078
nosy: dstufft, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: "make install" will not install pip if already present in user site-packages
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun 10 01:05:09 2015
From: report at bugs.python.org (py.user)
Date: Tue, 09 Jun 2015 23:05:09 +0000
Subject: [New-bugs-announce] [issue24419] In argparse action append_const
 doesn't work for positional arguments
Message-ID: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za>


New submission from py.user:

Action append_const works for options:

>>> import argparse
>>> 
>>> parser = argparse.ArgumentParser()
>>> _ = parser.add_argument('--foo', dest='x', action='append_const', const=42)
>>> _ = parser.add_argument('--bar', dest='x', action='append_const', const=43)
>>> parser.parse_args('--foo --bar'.split())
Namespace(x=[42, 43])
>>>

Action append_const works for single positionals:

>>> import argparse
>>> 
>>> parser = argparse.ArgumentParser()
>>> _ = parser.add_argument('foo', action='append_const', const=42)
>>> _ = parser.add_argument('bar', action='append_const', const=43)
>>> parser.parse_args([])
Namespace(bar=[43], foo=[42])
>>>

Action append_const doesn't work for positionals in one list:

>>> import argparse
>>> 
>>> parser = argparse.ArgumentParser()
>>> _ = parser.add_argument('foo', dest='x', action='append_const', const=42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py", line 1282, in add_argument
    """
ValueError: dest supplied twice for positional argument
>>> _ = parser.add_argument('bar', dest='x', action='append_const', const=43)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py", line 1282, in add_argument
    """
ValueError: dest supplied twice for positional argument
>>> parser.parse_args([])
Namespace()
>>>


The reason is that a positional argument can't accept dest:

>>> import argparse
>>> 
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', dest='x')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py", line 1282, in add_argument
    """
ValueError: dest supplied twice for positional argument
>>>

----------
components: Library (Lib)
messages: 245099
nosy: py.user
priority: normal
severity: normal
status: open
title: In argparse action append_const doesn't work for positional arguments
type: behavior
versions: Python 3.3, Python 3.6

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

From report at bugs.python.org  Wed Jun 10 06:04:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Jun 2015 04:04:16 +0000
Subject: [New-bugs-announce] [issue24420] Documentation regressions from
	adding subprocess.run()
Message-ID: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>


New submission from Martin Panter:

After the documentation was rearranged by Issue 23342 (revision f0a00ee094ff), the ?older high-level APIs? lost the paragraphs that said ?The arguments shown above are merely the most common ones?. Given the limited signatures of call(), check_call() and check_output(), it is now too easy to assume that these functions do not accept the less-common Popen arguments.

Also, in that issue I discovered an awkward edge case: there is actually no default value for the check_output() input parameter. Without an ?input? parameter, the subprocess inherits its parent?s input, but input=None is equivalent to passing an empty string of the correct type.

This patch hopefully fixes both problems.

----------
assignee: docs at python
components: Documentation
files: high-args.patch
keywords: patch
messages: 245111
nosy: docs at python, takluyver, vadmium
priority: normal
severity: normal
status: open
title: Documentation regressions from adding subprocess.run()
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39671/high-args.patch

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

From report at bugs.python.org  Wed Jun 10 10:06:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Jun 2015 08:06:40 +0000
Subject: [New-bugs-announce] [issue24421] Race condition compiling
	Modules/_math.c
Message-ID: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za>


New submission from Martin Panter:

Once or twice I have had the math or cmath modules fail to build. There seems to be a race condition, because the _math.c file seems to be compiled twice, once for each module. Attached is a GCC wrapper that should help reproduce this fairly consistently. First, build Python normally:

$ ./configure
$ make -j2

Then force Modules/_math.c to be recompiled using my wrapper script to amplify the race condition:

$ touch Modules/_math.c
$ rm build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o
$ make -j2 CC=./slow-cc.py
running build
running build_ext
building 'cmath' extension
compiling for  cmath
./slow-cc.py [. . .]/Modules/cmathmodule.o
building 'math' extension
./slow-cc.py [. . .]/Modules/mathmodule.o
./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/media/disk/home/proj/python/cpython/Include -I/media/disk/home/proj/python/cpython -c /media/disk/home/proj/python/cpython/Modules/_math.c -o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o
INITIAL COMPILE
./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/media/disk/home/proj/python/cpython/Include -I/media/disk/home/proj/python/cpython -c /media/disk/home/proj/python/cpython/Modules/_math.c -o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o
RECOMPILE
RECOMPIILE TRUNCATING
INITIAL COMPILE FINISHED
./slow-cc.py -shared build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/mathmodule.o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o -L/usr/local/lib -lm -o build/lib.linux-x86_64-3.6/math.cpython-36m-x86_64-linux-gnu.so
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status
RECOMPILE FINISHED
./slow-cc.py -shared build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/cmathmodule.o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o -L/usr/local/lib -lm -o build/lib.linux-x86_64-3.6/cmath.cpython-36m-x86_64-linux-gnu.so

Failed to build these modules:
math

----------
components: Build
files: slow-cc.py
messages: 245121
nosy: vadmium
priority: normal
severity: normal
status: open
title: Race condition compiling Modules/_math.c
type: behavior
Added file: http://bugs.python.org/file39672/slow-cc.py

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

From report at bugs.python.org  Wed Jun 10 11:56:19 2015
From: report at bugs.python.org (Hector Cloud)
Date: Wed, 10 Jun 2015 09:56:19 +0000
Subject: [New-bugs-announce] [issue24422] base64 not encode correctly
Message-ID: <1433930179.84.0.22171571246.issue24422@psf.upfronthosting.co.za>


New submission from Hector Cloud:

I use Python 3.4.0 now. But its base64 encoding is not as expected.
----------------------------
import base64
ascii = base64.b64encode(u"YAU-interview-revised20120921".encode(), b'-_')
print(ascii)
----------------------------
The result is b'WUFVLWludGVydmlldy1yZXZpc2VkMjAxMjA5MjE='. There is a character '=' at the end which is not expected. In my opinion, the result should contain characters [A-Za-z0-9] and '-_'. The '=' should not be in the encoding result.

Is it a bug?

----------
components: Library (Lib)
messages: 245123
nosy: Hector Cloud
priority: normal
severity: normal
status: open
title: base64 not encode correctly
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 10 14:34:37 2015
From: report at bugs.python.org (Stefan Tatschner)
Date: Wed, 10 Jun 2015 12:34:37 +0000
Subject: [New-bugs-announce] [issue24423] Fix wrong indentation in
	Doc/whatsnew/3.5.rst
Message-ID: <1433939677.74.0.149159718564.issue24423@psf.upfronthosting.co.za>


New submission from Stefan Tatschner:

A list item which describes the changes of #22631 is badly indented. The attached (trivial) patch fixes that problem.

----------
assignee: docs at python
components: Documentation
files: fix-indentation.patch
keywords: patch
messages: 245127
nosy: docs at python, rumpelsepp
priority: normal
severity: normal
status: open
title: Fix wrong indentation in Doc/whatsnew/3.5.rst
versions: Python 3.5
Added file: http://bugs.python.org/file39673/fix-indentation.patch

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

From report at bugs.python.org  Wed Jun 10 15:29:16 2015
From: report at bugs.python.org (Robert Haschke)
Date: Wed, 10 Jun 2015 13:29:16 +0000
Subject: [New-bugs-announce] [issue24424] xml.dom.minidom: performance issue
 with Node.insertBefore()
Message-ID: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za>


New submission from Robert Haschke:

Node.insertBefore() has a serious performance issue:

Using self.childNodes.index(refChild) it searches for the correct index in childNodes where the newChild should be inserted.
However, index() is linear in time w.r.t. the size of childNodes.
Hence, if there are many children, runtime dramatically increases.

Adding a simple caching mechanism (caching the previously used reference)
I was able to reduce runtime in my particular case from 16s to 1.6s, i.e. a factor of 10!

----------
components: XML
files: minidom.insertBefore.patch
keywords: patch
messages: 245128
nosy: Robert Haschke
priority: normal
severity: normal
status: open
title: xml.dom.minidom: performance issue with Node.insertBefore()
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file39674/minidom.insertBefore.patch

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

From report at bugs.python.org  Wed Jun 10 17:44:21 2015
From: report at bugs.python.org (Hayden Young)
Date: Wed, 10 Jun 2015 15:44:21 +0000
Subject: [New-bugs-announce] [issue24425] Installer Vender Issue
Message-ID: <1433951061.45.0.0884040195007.issue24425@psf.upfronthosting.co.za>


New submission from Hayden Young:

For some reason, my Python installer won't run properly. When I click install, after DISabling PIP in the installer (And with pip on), it tells me the following: "There is a problem with this windows installer package. A program required for this install to complete cannot be run. Contact your support personnel or package vendor." 

Can anyone help me here?
I really need Python for school, but my laptop won't run this properly.
If it's to do with my specs, they are this:

Laptop: Dell Latitude E6230 (Non-SSD)
Core: Intel i5 Processor

PLEASE HELP!

----------
components: Installation
messages: 245132
nosy: Hayden Young
priority: normal
severity: normal
status: open
title: Installer Vender Issue
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 10 20:53:09 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Wed, 10 Jun 2015 18:53:09 +0000
Subject: [New-bugs-announce] [issue24426] re.split performance degraded
 significantly by capturing group
Message-ID: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za>


New submission from Patrick Maupin:

The addition of a capturing group in a re.split() pattern, e.g. using '(\n)' instead of '\n', causes a factor of 10 performance degradation.

I use re.split a() lot, but never noticed the issue before.  It was extremely noticeable on 1000 patterns in a 5BG file, though, requiring 40 seconds instead of 4.

I have attached a script demonstrating the issue.  I have tested on 2.7 and 3.4, but have no reason to believe it doesn't exist on other vesions as well.

Thanks,
Pat

----------
components: Regular Expressions
files: splitter2.py
messages: 245137
nosy: Patrick Maupin, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.split performance degraded significantly by capturing group
type: performance
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file39676/splitter2.py

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

From report at bugs.python.org  Wed Jun 10 21:26:55 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 10 Jun 2015 19:26:55 +0000
Subject: [New-bugs-announce] [issue24427] subclass of multiprocessing
 Connection segfault upon attribute acces
Message-ID: <1433964415.99.0.226244144163.issue24427@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

The following segfaults in _PyObject_GenericGetAttrWithDict:

"""
from socket import socketpair
from _multiprocessing import Connection


class Crash(Connection):
    pass

_, w = socketpair()

Crash(w.fileno()).bar
"""

#0  _PyObject_GenericGetAttrWithDict (dict=0xa6b001c, name=0xb7281020, obj=0x8c12478) at Objects/object.c:1427
#1  PyObject_GenericGetAttr (obj=0x8c12478, name=0xb7281020) at Objects/object.c:1461

(gdb) p *(obj + obj->ob_type->tp_dictoffset)
$8 = {ob_refcnt = 0, ob_type = 0x0}

It's probably not specific to this example, but I'm not familiar enough with object construction/descriptors to know what's going on here.

Note that the following atch fixes the crash, but I don't know why:
"""
--- a/Modules/_multiprocessing/connection.h     Wed Apr 15 19:30:38 2015 +0100
+++ b/Modules/_multiprocessing/connection.h     Wed Jun 10 20:25:15 2015 +0100
@@ -58,7 +58,7 @@
         return NULL;
     }
 
-    self = PyObject_New(ConnectionObject, type);
+    self = type->tp_alloc(type, 0);
     if (self == NULL)
         return NULL;
 
@@ -86,7 +86,7 @@
         CLOSE(self->handle);
         Py_END_ALLOW_THREADS
     }
-    PyObject_Del(self);
+    Py_TYPE(self)->tp_free((PyObject*)self);
 }
 
 /*
"""

----------
messages: 245140
nosy: neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: subclass of multiprocessing Connection segfault upon attribute acces

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

From report at bugs.python.org  Wed Jun 10 21:42:08 2015
From: report at bugs.python.org (venkata suresh gummadillli)
Date: Wed, 10 Jun 2015 19:42:08 +0000
Subject: [New-bugs-announce] [issue24428] Import sys,
	getopt is having issue while taking inputs
Message-ID: <1433965328.43.0.612100341004.issue24428@psf.upfronthosting.co.za>


New submission from venkata suresh gummadillli:

[@outsidetried ~]$ python validate_json_adj.py 
[@outsidetried ~]$ python validate_json_adj.py -h
validate_json.py -i <input_file>
[@outsidetried ~]$ python validate_json_adj.py -i hello.txt
Input JSON file provided for verification: hello.txt
[@outsidetried ~]$ python validate_json_adj.py -i firstfile
Input JSON file provided for verification: firstfile
[@outsidetried ~]$ python validate_json_adj.py -i <hello.txt>
-bash: syntax error near unexpected token `newline'
[sureshgv at outsidetried ~]$ python validate_json_adj.py -i ??
Input JSON file provided for verification: ci
[@outsidetried ~]$ python validate_json_adj.py -i ???
Input JSON file provided for verification: bf1
[@outsidetried ~]$ python validate_json_adj.py -i $#@%
Input JSON file provided for verification: 0@%
[@outsidetried ~]$ cat validate_json_adj.py 
#!/usr/bin/python
"""
"""

import sys,getopt


"""
 """

def main(argv):
   inputfile = ''
   try:
      opts, args = getopt.getopt(argv,"hi:",["input_file="])
   except getopt.GetoptError:
      print 'validate_json.py -i <input_file>'
      sys.exit(2)
   for opt, arg in opts:
      if opt == '-h':
         print 'validate_json.py -i <input_file>'
         sys.exit()
      elif opt in ("-i", "--input_file"):
         inputfile = arg
   	 print 'Input JSON file provided for verification:', inputfile 
if __name__ == "__main__":
   main(sys.argv[1:])

----------
components: Library (Lib)
messages: 245142
nosy: venkata suresh gummadillli
priority: normal
severity: normal
status: open
title: Import sys,getopt is having issue while taking inputs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 11 12:59:30 2015
From: report at bugs.python.org (erik flister)
Date: Thu, 11 Jun 2015 10:59:30 +0000
Subject: [New-bugs-announce] [issue24429] msvcrt error when embedded
Message-ID: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za>


New submission from erik flister:

normally, CDLL(find_library('c')) is fine.  but when running embedded in a context that uses a different runtime version, this will cause an error (example: http://stackoverflow.com/questions/30771380/how-use-ctypes-with-msvc-dll-from-within-matlab-on-windows/).

using ctypes.cdll.msvcrt apparently finds the correct runtime.  i was surprised by this, i thought this was supposed to be identical to find_library('c').

in any case, some libraries (uuid.py) use the one that breaks.  can you either switch everything to ctypes.cdll.msvcrt, or have find_library('c') change to be identical to it?

----------
components: Library (Lib), Windows, ctypes
messages: 245162
nosy: erik flister, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: msvcrt error when embedded
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 11 15:53:41 2015
From: report at bugs.python.org (era)
Date: Thu, 11 Jun 2015 13:53:41 +0000
Subject: [New-bugs-announce] [issue24430] ZipFile.read() cannot decrypt
 multiple members from Windows 7zfm
Message-ID: <1434030821.12.0.415764944762.issue24430@psf.upfronthosting.co.za>


New submission from era:

The attached archive from the Windows version of the 7z file manager (7zFM version 9.20) cannot be decrypted into memory.  The first file succeeds, but the second one fails.

The following small program is able to unzip other encrypted zip archives (tried one created by Linux 7z version 9.04 on Debian from the package p7zip-full, and one from plain zip 3.0-3 which comes from the InfoZip distribution, as well as a number of archives of unknown provenance) but fails on the attached one.

from zipfile import ZipFile
from sys import argv

container = ZipFile(argv[1])
for member in container.namelist():
    print("member %s" % member)
    try:
        extracted = container.read(member)
        print("extracted %s" % repr(extracted)[0:64])
    except RuntimeError, err:
        extracted = container.read(member, 'hello')
        container.setpassword('hello')
        print("extracted with password 'hello': %s" % repr(extracted)[0:64])

Here is the output and backtrace:

member hello/
extracted ''
member hello/goodbye.txt
Traceback (most recent call last):
  File "./nst.py", line 13, in <module>
    extracted = container.read(member, 'hello')
  File "/usr/lib/python2.6/zipfile.py", line 834, in read
    return self.open(name, "r", pwd).read()
  File "/usr/lib/python2.6/zipfile.py", line 901, in open
    raise RuntimeError("Bad password for file", name)
RuntimeError: ('Bad password for file', 'hello/goodbye.txt')

The 7z command is able to extract it just fine:

$ 7z -phello x /tmp/hello.zip

7-Zip 9.04 beta  Copyright (c) 1999-2009 Igor Pavlov  2009-05-30
p7zip Version 9.04 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU)

Processing archive: /tmp/hello.zip

Extracting  hello
Extracting  hello/goodbye.txt
Extracting  hello/hello.txt

Everything is Ok

Folders: 1
Files: 2
Size:       15
Compressed: 560

----------
files: hello.zip
messages: 245165
nosy: era
priority: normal
severity: normal
status: open
title: ZipFile.read() cannot decrypt multiple members from Windows 7zfm
Added file: http://bugs.python.org/file39680/hello.zip

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

From report at bugs.python.org  Thu Jun 11 16:59:12 2015
From: report at bugs.python.org (Martin Teichmann)
Date: Thu, 11 Jun 2015 14:59:12 +0000
Subject: [New-bugs-announce] [issue24431] StreamWriter.drain is not callable
	concurrently
Message-ID: <1434034752.25.0.200116855736.issue24431@psf.upfronthosting.co.za>


New submission from Martin Teichmann:

Currently there is an assert statement asserting that no two
tasks (asyncio tasks, that is) can use StreamWriter.drain at
the same time. This is a weird limitiation, if there are two
tasks writing to the same network socket, there is no reason
why not both of them should drain the socket after (or before)
writing to it.

A simple bug fix is attached.

----------
components: asyncio
files: patch
messages: 245172
nosy: Martin.Teichmann, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: StreamWriter.drain is not callable concurrently
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39681/patch

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

From report at bugs.python.org  Thu Jun 11 17:05:25 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 11 Jun 2015 15:05:25 +0000
Subject: [New-bugs-announce] [issue24432] Upgrade windows builds to use
	OpenSSL 1.0.2b
Message-ID: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

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

----------
components: Library (Lib)
keywords: security_issue
messages: 245173
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, paul.moore, pitrou, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade windows builds to use OpenSSL 1.0.2b

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

From report at bugs.python.org  Thu Jun 11 18:32:20 2015
From: report at bugs.python.org (=?utf-8?b?0J7Qu9C10LMg0JjQstCw0L3QvtCy?=)
Date: Thu, 11 Jun 2015 16:32:20 +0000
Subject: [New-bugs-announce] [issue24433] There is no asyncio.ensure_future
	in Python 3.4.3
Message-ID: <1434040340.54.0.582208217128.issue24433@psf.upfronthosting.co.za>


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

Docs claims there there is asyncio.ensure_future

https://docs.python.org/3/library/asyncio-task.html?highlight=ensure_future#asyncio.ensure_future

but example from docs does'nt work:

import asyncio

loop = asyncio.get_event_loop()
tasks = [
    asyncio.ensure_future(print("asasda")),

]
loop.run_until_complete(asyncio.wait(tasks))
loop.close()

Fails with:

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

----------
assignee: docs at python
components: Documentation
messages: 245176
nosy: docs at python, ???? ??????
priority: normal
severity: normal
status: open
title: There is no asyncio.ensure_future in Python 3.4.3
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jun 11 20:57:53 2015
From: report at bugs.python.org (Caleb Levy)
Date: Thu, 11 Jun 2015 18:57:53 +0000
Subject: [New-bugs-announce] [issue24434] ItemsView.__contains__ does not
	mimic dict_items
Message-ID: <1434049073.59.0.107157683253.issue24434@psf.upfronthosting.co.za>


Changes by Caleb Levy <caleb.levy at berkeley.edu>:


----------
components: Library (Lib)
nosy: clevy, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: ItemsView.__contains__ does not mimic dict_items
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jun 11 21:07:34 2015
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 11 Jun 2015 19:07:34 +0000
Subject: [New-bugs-announce] [issue24435] Grammar/Grammar points to outdated
	guide
Message-ID: <1434049654.36.0.351948731258.issue24435@psf.upfronthosting.co.za>


New submission from Chris Angelico:

Grammar/Grammar points to PEP 306, which points instead to the dev guide. The exact link is not provided, but it'd be useful to skip the PEP altogether and just link to https://docs.python.org/devguide/grammar.html in the file.

----------
messages: 245180
nosy: Rosuav
priority: normal
severity: normal
status: open
title: Grammar/Grammar points to outdated guide

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

From report at bugs.python.org  Thu Jun 11 22:24:52 2015
From: report at bugs.python.org (Michael Ensslin)
Date: Thu, 11 Jun 2015 20:24:52 +0000
Subject: [New-bugs-announce] [issue24436] _PyTraceback_Add has no const
 qualifier for its char * arguments
Message-ID: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za>


New submission from Michael Ensslin:

The prototype for the public API function _PyTraceback_Add is declared

_PyTraceback_Add(char *, char *, int);

Internally, its char * arguments are passed verbatim to PyCode_NewEmpty, which takes const char * arguments.

The missing 'const' qualifier for the arguments of _PyTraceback_Add thus serves no purpose, and means that C++ code can't invoke the method with const char * arguments.

I've attached a proposed patch.

I can't think of any negative consequences from adding the 'const' qualifier (famous last words).

----------
components: Interpreter Core
files: const.patch
keywords: patch
messages: 245185
nosy: mic-e
priority: normal
severity: normal
status: open
title: _PyTraceback_Add has no const qualifier for its char * arguments
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39685/const.patch

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

From report at bugs.python.org  Thu Jun 11 23:35:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Jun 2015 21:35:43 +0000
Subject: [New-bugs-announce] [issue24437] Add information about the buildbot
 console view and irc notices to devguide
Message-ID: <1434058543.2.0.729414223223.issue24437@psf.upfronthosting.co.za>


New submission from R. David Murray:

Here is a proposed addition to the devguide talking about the buildbot console interface (which I find far more useful than the waterfall view), and mentioning the notifications posted to #python-dev (which is a good way to find out if you broke the buildbots).

----------
components: Devguide
files: buildbot-console-irc.patch
keywords: patch
messages: 245190
nosy: ezio.melotti, ncoghlan, r.david.murray, willingc
priority: normal
severity: normal
stage: patch review
status: open
title: Add information about the buildbot console view and irc notices to devguide
Added file: http://bugs.python.org/file39687/buildbot-console-irc.patch

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

From report at bugs.python.org  Fri Jun 12 15:22:58 2015
From: report at bugs.python.org (Alex Monk)
Date: Fri, 12 Jun 2015 13:22:58 +0000
Subject: [New-bugs-announce] [issue24438] Strange behaviour when multiplying
	imaginary inf by 1
Message-ID: <1434115378.51.0.752150988215.issue24438@psf.upfronthosting.co.za>


New submission from Alex Monk:

alex at alex-laptop:~$ python3
Python 3.4.3 (default, Mar 26 2015, 22:03:40) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> infj = complex(0, float("inf"))
>>> infj
infj
>>> infj*1
(nan+infj)
>>> infj*1*1
(nan+nanj)

----------
messages: 245247
nosy: Alex Monk
priority: normal
severity: normal
status: open
title: Strange behaviour when multiplying imaginary inf by 1
type: behavior

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

From report at bugs.python.org  Fri Jun 12 16:46:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Jun 2015 14:46:06 +0000
Subject: [New-bugs-announce] [issue24439] Feedback for awaitable coroutine
	documentation
Message-ID: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>


New submission from Martin Panter:

Today I tried playing with the new ?async def? functionality in the interactive interpreter, based on reading the documentation. Here are some bits that surprised me, so could be the focus of further documentation. (Initial documentation added in Issue 24180.)

1. Confusion between coroutine and generator terms

<coroutine object f at 0x7f9a5ae45200>
AttributeError: 'generator' object has no attribute '__await__'
<class 'generator'>
TypeError: coroutine-objects do not support iteration
TypeError: can't send non-None value to a just-started generator

Is it a coroutine object, or a generator object? The error messages etc seem to be split between the two terms. I guess the underlying implementation is closely shared between the two types, so old error messages still say ?generator?, while new ones say ?coroutine?. So there may not be an easy fix, but it was initially disconcerting. Perhaps a statement somewhere explaining coroutine instances are (based on / modified / a kind of / evolved from) generator instance objects, as appropriate.

2. Properties of a coroutine instance object

<https://docs.python.org/dev/reference/datamodel.html#awaitable-objects> suggests that a coroutine instance should implement __await__(), but it apparently does not.

How to drive through the coroutine?s await points? This should be documented, and linked from relevant places in the documentation; perhaps the ?coroutine? glossary entry, ?async? statement, and ?await? expression. The best clue that I found in the current documentation was <https://docs.python.org/dev/library/collections.abc.html#collections.abc.Coroutine>, suggesting to use send().

Without having studied the PEP recently, I was expecting __await__() to be implemented, and invoking it would be similar to calling next() on an old-skool generator-iterator. Instead I see that calling __await__() is semantically more like __iter__(): it is only invoked once per ?await? expression, and the return value is iterated over.

3. Allergic reaction to ?await? on the same line as ?async def?

>>> async def f(): await A(())
SyntaxError: invalid syntax

I see this is mentioned in the PEP that this is necessary so that ?await? doesn?t have to be made a strict language keyword. But it should also be in the documentation.

4. Coroutine instances don?t implement the Coroutine ABC

>>> isinstance(c, Coroutine)
True
>>> hasattr(Coroutine, "__await__")
True
>>> hasattr(c, "__await__")
False

Reading closely, the documentation says ?coroutine compatible classes?, but given the liberal use of ?coroutine? everywhere, I think there should be a more obvious warning of how much a coroutine is a Coroutine.

----------
assignee: docs at python
components: Documentation
messages: 245256
nosy: docs at python, vadmium, yselivanov
priority: normal
severity: normal
status: open
title: Feedback for awaitable coroutine documentation
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 12 18:03:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Jun 2015 16:03:59 +0000
Subject: [New-bugs-announce] [issue24440] Move the buildslave setup
 information from the wiki to the devguide
Message-ID: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za>


New submission from R. David Murray:

I propose that we move the information on setting up a buildslave from the wiki to the devguide.  The attached patch is my rewrite (hopefully an improvement) of the information from the wiki.  Note that there are a couple of TBD pieces (setup on Windows, restart at boot on windows and mac).  I'll be filling in the mac stuff as I set up the Intel ICC mac buildbot and figure out what all is missing from the docs.

----------
components: Devguide
messages: 245262
nosy: ezio.melotti, ncoghlan, pitrou, r.david.murray, willingc, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Move the buildslave setup information from the wiki to the devguide
type: enhancement

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

From report at bugs.python.org  Fri Jun 12 23:41:11 2015
From: report at bugs.python.org (py.user)
Date: Fri, 12 Jun 2015 21:41:11 +0000
Subject: [New-bugs-announce] [issue24441] In argparse add_argument() allows
 the empty choices argument
Message-ID: <1434145271.17.0.0249492593034.issue24441@psf.upfronthosting.co.za>


New submission from py.user:

A script, configuring argparse to have no choices:

#!/usr/bin/env python3

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('foo', choices=[])

args = parser.parse_args()
print(args)


Running it:

[guest at localhost args]$ ./t.py
usage: t.py [-h] {}
t.py: error: too few arguments
[guest at localhost args]$ ./t.py a
usage: t.py [-h] {}
t.py: error: argument foo: invalid choice: 'a' (choose from )
[guest at localhost args]$ ./t.py ""
usage: t.py [-h] {}
t.py: error: argument foo: invalid choice: '' (choose from )
[guest at localhost args]$

[guest at localhost args]$ ./t.py -h
usage: t.py [-h] {}

positional arguments:
  {}

optional arguments:
  -h, --help  show this help message and exit
[guest at localhost args]$


ISTM, it should throw an exception about empty choices rather than show help with empty choices.

----------
components: Library (Lib)
messages: 245277
nosy: py.user
priority: normal
severity: normal
status: open
title: In argparse add_argument() allows the empty choices argument
type: behavior
versions: Python 3.3, Python 3.6

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

From report at bugs.python.org  Sat Jun 13 04:57:56 2015
From: report at bugs.python.org (Perry Randall)
Date: Sat, 13 Jun 2015 02:57:56 +0000
Subject: [New-bugs-announce] [issue24442] Readline Bindings Don't Report Any
 Error On Completer Function Exception
Message-ID: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za>


New submission from Perry Randall:

Noticed this while writing a non-trivial completion function for readline.set_completer. When an exception is thrown in the completion function readline doesnt do anything, squashes the error, this should not be the case.

----------
components: Interpreter Core
files: readline_exception.patch
keywords: patch
messages: 245285
nosy: Perry Randall
priority: normal
severity: normal
status: open
title: Readline Bindings Don't Report Any Error On Completer Function Exception
type: behavior
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/file39698/readline_exception.patch

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

From report at bugs.python.org  Sat Jun 13 08:41:15 2015
From: report at bugs.python.org (Jaivish Kothari)
Date: Sat, 13 Jun 2015 06:41:15 +0000
Subject: [New-bugs-announce] [issue24443] Link for clear and wait missing in
	EventObjects
Message-ID: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za>


New submission from Jaivish Kothari:

https://docs.python.org/2/library/threading.html#threading.Event.set

links missing for wait and clear .
set() is linked though.

Line: "

An event object manages an internal flag that can be set to true with the set() method and reset to false with the clear() method. The wait() method blocks until the flag is true.

"

----------
assignee: docs at python
components: Documentation
files: Fix_link.patch
keywords: patch
messages: 245294
nosy: berker.peksag, docs at python, georg.brandl, janonymous, janonymous, tim.golden, willingc
priority: normal
severity: normal
status: open
title: Link for clear and wait missing in EventObjects
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file39702/Fix_link.patch

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

From report at bugs.python.org  Sat Jun 13 08:47:02 2015
From: report at bugs.python.org (py.user)
Date: Sat, 13 Jun 2015 06:47:02 +0000
Subject: [New-bugs-announce] [issue24444] In argparse empty choices cannot
	be printed in the help
Message-ID: <1434178022.79.0.230343884775.issue24444@psf.upfronthosting.co.za>


New submission from py.user:

>>> import argparse
>>> 
>>> parser = argparse.ArgumentParser()
>>> _ = parser.add_argument('foo', choices=[], help='%(choices)s')
>>> parser.print_help()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 2358, in print_help
    self._print_message(self.format_help(), file)
  File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 2342, in format_help
    return formatter.format_help()
  File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 278, in format_help
    help = self._root_section.format_help()
  File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 208, in format_help
    func(*args)
  File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 208, in format_help
    func(*args)
  File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 517, in _format_action
    parts.append('%*s%s\n' % (indent_first, '', help_lines[0]))
IndexError: list index out of range
>>>

It's not very useful to print empty choices, but the choices list could be formed dynamically. So the command-line user can't figure out what's happen.

----------
components: Library (Lib)
messages: 245297
nosy: py.user
priority: normal
severity: normal
status: open
title: In argparse empty choices cannot be printed in the help
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Jun 13 15:29:53 2015
From: report at bugs.python.org (o1da)
Date: Sat, 13 Jun 2015 13:29:53 +0000
Subject: [New-bugs-announce] [issue24445] rstrip strips what it doesn't have
	to
Message-ID: <1434202193.55.0.291762155512.issue24445@psf.upfronthosting.co.za>


New submission from o1da:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> text = 'test1/1.jp2'
>>> text.rstrip('.jp2')
'test1/1'
>>> text = 'test1.jp2'
>>> text.rstrip('.jp2')
'test1'
>>> text = 'test1/2.jp2'
>>> text.rstrip('.jp2')
'test1/'
>>> 

Why the rstrip function stripped '2' from the last example? I think that it is a bug.

----------
messages: 245311
nosy: o1da
priority: normal
severity: normal
status: open
title: rstrip strips what it doesn't have to
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun 14 00:05:16 2015
From: report at bugs.python.org (Ernesto Alfonso)
Date: Sat, 13 Jun 2015 22:05:16 +0000
Subject: [New-bugs-announce] [issue24446] imap and map inconsistent behaviour
Message-ID: <1434233116.75.0.429169275547.issue24446@psf.upfronthosting.co.za>


New submission from Ernesto Alfonso:

itertools.imap and map in Python 2.7 produces inconsistent behaviour when mapping the null (None) function over multiple sequences.
 


>>> [a for a in map(None, list("abcd"), range(3))]
[('a', 0), ('b', 1), ('c', 2), ('d', None)]
>>> from itertools import imap
>>> [a for a in imap(None, list("abcd"), range(3))]
[('a', 0), ('b', 1), ('c', 2)]
>>> [a for a in map(None, list("abcd"), range(3))] == [a for a in imap(None, list("abcd"), range(3))]
False
>>> 



This inconsistent and unintuitive behvaiour caused a bug in my program

----------
components: Interpreter Core, Library (Lib)
messages: 245329
nosy: Ernesto Alfonso
priority: normal
severity: normal
status: open
title: imap and map inconsistent behaviour
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun 14 05:33:14 2015
From: report at bugs.python.org (Dingyuan Wang)
Date: Sun, 14 Jun 2015 03:33:14 +0000
Subject: [New-bugs-announce] [issue24447] tab indentation breaks in
	tokenize.untokenize
Message-ID: <1434252794.24.0.0112893923697.issue24447@psf.upfronthosting.co.za>


New submission from Dingyuan Wang:

If a script uses tabs for indentation, tokenize.untokenize won't restore original indentation correctly from the second line of the indentation level, and thus breaks the file.

This affects all Python versions.

Test code:

python2 -c 'import sys, tokenize; sys.stdout.write(tokenize.untokenize(tokenize.generate_tokens(sys.stdin.readline)))' < tab.py

python3 -c 'import sys, tokenize; sys.stdout.buffer.write(tokenize.untokenize(tokenize.tokenize(sys.stdin.buffer.readline)))' < tab.py

Out:

def foo():
	pass
 pass
 if 1:
		pass
  pass

----------
components: Library (Lib)
files: tab.py
messages: 245333
nosy: gumblex
priority: normal
severity: normal
status: open
title: tab indentation breaks in tokenize.untokenize
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file39704/tab.py

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

From report at bugs.python.org  Sun Jun 14 08:16:16 2015
From: report at bugs.python.org (irdb)
Date: Sun, 14 Jun 2015 06:16:16 +0000
Subject: [New-bugs-announce] [issue24448] Syntax highlighting marks
	multiline comments as strings
Message-ID: <1434262576.97.0.123947261736.issue24448@psf.upfronthosting.co.za>


New submission from irdb:

It has been suggested by BDFL to use triple-quoted strings as multiline comments.[1]

Allegedly, some editors already makes a distinction between these kind of comments and docstring and highlight them differently.

It would be nice if IDLE could also highlight these kind of comments with the same color as the other single-line comments.

[1]: https://stackoverflow.com/posts/7696966/revisions

----------
components: IDLE
messages: 245334
nosy: irdb
priority: normal
severity: normal
status: open
title: Syntax highlighting marks multiline comments as strings
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun 14 09:50:50 2015
From: report at bugs.python.org (Paul Sokolovsky)
Date: Sun, 14 Jun 2015 07:50:50 +0000
Subject: [New-bugs-announce] [issue24449] Please add async write method to
	asyncio.StreamWriter
Message-ID: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

This issue was brought is somewhat sporadic manner on python-tulip mailing list, hence this ticket. The discussion on the ML:

https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/knMvVGxp2WsJ
(all other messages below threaded from this)

https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/lGqT54yupOIJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/U0NBC1jLGSgJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/zIx59jj8krsJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/zSpjGKv23ioJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/3mfGI8HIe_gJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/rM4fyA9qlY4J

Summary of arguments:

1. This would make such async_write() (a tentative name) symmetrical in usage with read() method (i.e. be a coroutine to be used with "yield from"/"await"), which certainly reduce user confusion and will help novices to learn/use asyncio.

2. write() method is described (by transitively referring to WriteTransport.write()) as "This method does not block; it buffers the data and arranges for it to be sent out asynchronously." Such description implies requirement of unlimited data buffering. E.g., being fed with 1TB of data, it still must buffer it. Bufferings of such size can't/won't work in practice - they only will lead to excessive swapping and/or termination due to out of memory conditions. Thus, providing only synchronous high-level write operation goes against basic system reliability/security principles.

3. The whole concept of synchronous write in an asynchronous I/O framework stems from: 1) the way it was done in some pre-existing Python async I/O frameworks ("pre-existing" means brought up with older versions of Python and based on concepts available at that time; many people use word "legacy" in such contexts); 2) on PEP3153, which essentially captures ideas used in the aforementioned pre-existing Python frameworks. PEP3153 was rejected; it also contains some "interesting" claims like "Considered API alternatives - Generators as producers - [...] - nobody produced actually working code demonstrating how they could be used." That wasn't true at the time of PEP writing (http://www.dabeaz.com/generators/ , 2008, 2009), and asyncio is actually *the* framework which uses generators as producers.

asyncio also made a very honorable step of uniting generators/coroutine and Transport paradigm - note that as PEP3153 shows, Transport proponents contrasted it with coroutine-based design. But asyncio also blocked (in both senses) high-level I/O on Transport paradigm. What I'm arguing is not that Transports are good or bad, but that there should be a way to consistently use coroutine paradigm for I/O in asyncio - for people who may appreciate it. This will also enable alternative implementations of asyncio subsets without Transport layer, with less code size, and thus more suitable for constrained environments.

Proposed change is to add following to asyncio.StreamWriter implementation:

@coroutine
def async_write(self, data):
    self.write(data)

I.e. default implementation will be just coroutine version of synchronous write() method. The messages linked above discuss alternative implementations (which are really interesting for complete alternative implementations of asyncio).


The above changes are implemented in MicroPython's uasyncio package, which asyncio subset for memory-constrained systems.

Thanks for your consideration!

----------
components: asyncio
messages: 245336
nosy: gvanrossum, haypo, pfalcon, yselivanov
priority: normal
severity: normal
status: open
title: Please add async write method to asyncio.StreamWriter
versions: Python 3.5

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

From report at bugs.python.org  Sun Jun 14 12:29:47 2015
From: report at bugs.python.org (Benno Leslie)
Date: Sun, 14 Jun 2015 10:29:47 +0000
Subject: [New-bugs-announce] [issue24450] Add gi_yieldfrom calculated
	property to generator object
Message-ID: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za>


New submission from Benno Leslie:

When a co-routine has delegated computation to another co-routine via "yield from", it is useful to be able to access the delegated-to co-routine.

This proposed enhancement would add a new calculated property to the generator object called "gi_yieldfrom", which returns the delegated-to co-routine (or None).

----------
components: Interpreter Core
messages: 245338
nosy: bennoleslie
priority: normal
severity: normal
status: open
title: Add gi_yieldfrom calculated property to generator object
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Jun 14 19:16:11 2015
From: report at bugs.python.org (Joshua Harlow)
Date: Sun, 14 Jun 2015 17:16:11 +0000
Subject: [New-bugs-announce] [issue24451] Add metrics to future objects
	(concurrent or asyncio?)
Message-ID: <1434302171.22.0.0439382195068.issue24451@psf.upfronthosting.co.za>


New submission from Joshua Harlow:

It would be quite useful to have some types of metrics attached to future objects so that callers could use them for various activities (scheduling repeated runs, post-analysis and such):

Some of the ones that I can think would be useful:

- 'submitted_at' (when the callback was submitted to the executor responsible for executing it)
- 'started_at' (when the executor actually started executing the callback, which is typically sometime after it was submitted)
- 'finished_at' (when the executor finished calling the callback)
- elapsed [finished_at - started_at] (the elapsed runtime of the callback)

Do others feel this would be useful (if so I can put up some patches)? Right now getting this information is pretty hard to get at (since the executors that exist currently do not expose this information and it is quite hard to obtain it in a reliable manner).

----------
components: Library (Lib)
messages: 245345
nosy: Joshua.Harlow
priority: normal
severity: normal
status: open
title: Add metrics to future objects (concurrent or asyncio?)
type: enhancement

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

From report at bugs.python.org  Sun Jun 14 23:33:25 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 14 Jun 2015 21:33:25 +0000
Subject: [New-bugs-announce] [issue24452] Make webbrowser support Chrome on
	Mac OS/X
Message-ID: <1434317605.99.0.218705045555.issue24452@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

This doesn't work on Python 3.4 on a Mac with Yosemite and Chrome installed:

import webbrowser
webbrowser.get("chrome")

This patch makes it work:
```
*** /usr/local/pythonz/pythons/CPython-3.4.1/lib/python3.4/webbrowser.py	2014-09-21 16:37:46.000000000 -0400
--- /Users/ned/foo/webbrowser.py	2015-06-14 17:31:28.000000000 -0400
***************
*** 605,614 ****
--- 605,615 ----

      # Don't clear _tryorder or _browsers since OS X can use above Unix support
      # (but we prefer using the OS X specific stuff)
      register("safari", None, MacOSXOSAScript('safari'), -1)
      register("firefox", None, MacOSXOSAScript('firefox'), -1)
+     register("chrome", None, MacOSXOSAScript('chrome'), -1)
      register("MacOSX", None, MacOSXOSAScript('default'), -1)


  # OK, now that we know what the default preference orders for each
  # platform are, allow user to override them with the BROWSER variable.
```

----------
components: Library (Lib)
messages: 245351
nosy: nedbat
priority: normal
severity: normal
status: open
title: Make webbrowser support Chrome on Mac OS/X
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 15 00:14:20 2015
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 14 Jun 2015 22:14:20 +0000
Subject: [New-bugs-announce] [issue24453] A typo of doubled "the" words in
	the doc (easy fix)
Message-ID: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak:

https://docs.python.org/3.4/library/webbrowser.html#module-webbrowser

Visit the link and read the first sentence of the 3rd paragraph. You'll notice that there are two "the" words by the end of that sentence. That's obviously a typo. Please fix it. The typo, however, is not present in the documentation for Python 3.5. Don't know why the 3.4 branch of the docs wasn't fixed as well.

----------
assignee: docs at python
components: Documentation
messages: 245352
nosy: Pikec, docs at python
priority: normal
severity: normal
status: open
title: A typo of doubled "the" words in the doc (easy fix)
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 15 05:47:52 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jun 2015 03:47:52 +0000
Subject: [New-bugs-announce] [issue24454] Improve the usability of the match
	object named group API
Message-ID: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The usability, learnability, and readability of match object code would be improved by giving it a more Pythonic API (inspired by ElementTree).

Given a search like:

   data = 'Answer found on row 8 column 12.'
   mo = re.search(r'row (?P<row>\d+) column (?P<col>\d+)', data)

We currently access results with:

  print(mo.group('col'))
  print(len(mo.groups())

A better way would look like this:

  print(mo['col'])
  print(len(mo))

This would work nicely with string formatting:

  print('Located coordinate at (%(row)s, %(col)s)' % mo)
  print('Located coordinate at ({row}, {col})'.format_map(mo))

----------
components: Library (Lib)
messages: 245361
nosy: rhettinger
priority: low
severity: normal
status: open
title: Improve the usability of the match object named group API
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Jun 15 17:57:30 2015
From: report at bugs.python.org (irdb)
Date: Mon, 15 Jun 2015 15:57:30 +0000
Subject: [New-bugs-announce] [issue24455] IDLE debugger causes crash if not
 quitted properly before next run
Message-ID: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za>


New submission from irdb:

# Open a module using IDLE
# Run the module (Press F5)
# Activate the debugger ([DEBUG ON])
# Set a breakpoint in the module
# Run the module again
# Run the module for the third time
# Hit the Quit button in Debug Control window (twice, as the first click appears to do nothing)

Congratulations! You got yourself a crash!
After a while, a window dialogue appears asking "Do you want to end this process?". Click "End Process" (As there doesn't seem to be any other way).

One way to avoid this crash is to press quit before the third run. But even without it, this shouldn't happen. Sometimes the programmer may simply forget that there is an active debugger running...

I'm using 
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32
(Windows 8.1)

----------
components: IDLE
messages: 245384
nosy: irdb
priority: normal
severity: normal
status: open
title: IDLE debugger causes crash if not quitted properly before next run
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 15 22:57:26 2015
From: report at bugs.python.org (JohnLeitch)
Date: Mon, 15 Jun 2015 20:57:26 +0000
Subject: [New-bugs-announce] [issue24456] audioop.adpcm2lin Buffer Over-read
Message-ID: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za>


New submission from JohnLeitch:

The audioop.adpcm2lin function suffers from a buffer over-read caused by unchecked access to stepsizeTable at line 1545 of Modules\audioop.c:

    } else if ( !PyArg_ParseTuple(state, "ii", &valpred, &index) )
        return 0;

    step = stepsizeTable[index];
    
Because the index variable can be controlled via the third parameter of audioop.adpcm2lin, this behavior could potentially be exploited to disclose arbitrary memory, should an application expose the parameter to the attack surface.

0:000> r
eax=01f13474 ebx=00000000 ecx=00000002 edx=01f13460 esi=01f13460 edi=00000001
eip=1e01c4f0 esp=0027fcdc ebp=7e86ecdd iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
python27!audioop_adpcm2lin+0xe0:
1e01c4f0 8b04adb0dd1f1e  mov     eax,dword ptr python27!stepsizeTable (1e1fddb0)[ebp*4] ss:002b:183b9124=????????
0:000> k
ChildEBP RetAddr
0027fd18 1e0aafd7 python27!audioop_adpcm2lin+0xe0
0027fd30 1e0edd10 python27!PyCFunction_Call+0x47
0027fd5c 1e0f017a python27!call_function+0x2b0
0027fdcc 1e0f1150 python27!PyEval_EvalFrameEx+0x239a
0027fe00 1e0f11b2 python27!PyEval_EvalCodeEx+0x690
0027fe2c 1e11707a python27!PyEval_EvalCode+0x22
0027fe44 1e1181c5 python27!run_mod+0x2a
0027fe64 1e118760 python27!PyRun_FileExFlags+0x75
0027fea4 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190
0027fec0 1e038d35 python27!PyRun_AnyFileExFlags+0x59
0027ff3c 1d00116d python27!Py_Main+0x965
0027ff80 76477c04 python!__tmainCRTStartup+0x10f
0027ff94 7799ad1f KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7799acea ntdll!__RtlUserThreadStart+0x2f
0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000>

To fix this issue, it is recommended that bounds checking be performed prior to accessing stepsizeTable.

----------
files: audioop.adpcm2lin_buffer_over-read.py
messages: 245407
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: audioop.adpcm2lin Buffer Over-read
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file39712/audioop.adpcm2lin_buffer_over-read.py

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

From report at bugs.python.org  Mon Jun 15 22:58:26 2015
From: report at bugs.python.org (JohnLeitch)
Date: Mon, 15 Jun 2015 20:58:26 +0000
Subject: [New-bugs-announce] [issue24457] audioop.lin2adpcm Buffer Over-read
Message-ID: <1434401906.27.0.811918052895.issue24457@psf.upfronthosting.co.za>


New submission from JohnLeitch:

The audioop.lin2adpcm function suffers from a buffer over-read caused by unchecked access to stepsizeTable at line 1436 of Modules\audioop.c:

    } else if ( !PyArg_ParseTuple(state, "ii", &valpred, &index) )
        return 0;

    step = stepsizeTable[index];
    
Because the index variable can be controlled via the third parameter of audioop.lin2adpcm, this behavior could potentially be exploited to disclose arbitrary memory, should an application expose the parameter to the attack surface.

0:000> r
eax=00000001 ebx=00000001 ecx=2fd921bb edx=00000002 esi=00000001 edi=01e79160
eip=1e01c286 esp=0027fcdc ebp=df531970 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
python27!audioop_lin2adpcm+0xd6:
1e01c286 8b34adb0dd1f1e  mov     esi,dword ptr python27!stepsizeTable (1e1fddb0)[ebp*4] ss:002b:9b6c4370=????????
0:000> k
ChildEBP RetAddr
0027fd18 1e0aafd7 python27!audioop_lin2adpcm+0xd6
0027fd30 1e0edd10 python27!PyCFunction_Call+0x47
0027fd5c 1e0f017a python27!call_function+0x2b0
0027fdcc 1e0f1150 python27!PyEval_EvalFrameEx+0x239a
0027fe00 1e0f11b2 python27!PyEval_EvalCodeEx+0x690
0027fe2c 1e11707a python27!PyEval_EvalCode+0x22
0027fe44 1e1181c5 python27!run_mod+0x2a
0027fe64 1e118760 python27!PyRun_FileExFlags+0x75
0027fea4 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190
0027fec0 1e038d35 python27!PyRun_AnyFileExFlags+0x59
0027ff3c 1d00116d python27!Py_Main+0x965
0027ff80 76477c04 python!__tmainCRTStartup+0x10f
0027ff94 7799ad1f KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7799acea ntdll!__RtlUserThreadStart+0x2f
0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000>

To fix this issue, it is recommended that bounds checking be performed prior to accessing stepsizeTable.

----------
files: audioop.lin2adpcm_buffer_over-read.py
messages: 245408
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: audioop.lin2adpcm Buffer Over-read
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file39713/audioop.lin2adpcm_buffer_over-read.py

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

From report at bugs.python.org  Tue Jun 16 13:07:46 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 16 Jun 2015 11:07:46 +0000
Subject: [New-bugs-announce] [issue24458] Documentation for PEP 489
Message-ID: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

Hello,
Here is a patch documenting PEP 489.

I don't feel comfortable rewriting the tutorial [0] yet: before the issue with callbacks/module state [1] is solved, which is 3.6 material, multi-phase init is not suitable for all modules.
So everything in PEP 489 is described in reference-style documentation.


[0] https://docs.python.org/3/extending/extending.html
[1] https://www.python.org/dev/peps/pep-0489/#module-state-and-c-level-callbacks

----------
assignee: docs at python
components: Documentation
files: pep489-docs.patch
keywords: patch
messages: 245419
nosy: brett.cannon, docs at python, encukou, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Documentation for PEP 489
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39715/pep489-docs.patch

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

From report at bugs.python.org  Tue Jun 16 22:51:35 2015
From: report at bugs.python.org (Antony Lee)
Date: Tue, 16 Jun 2015 20:51:35 +0000
Subject: [New-bugs-announce] [issue24459] Mention PYTHONFAULTHANDLER in the
	man page
Message-ID: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>


New submission from Antony Lee:

The man page doesn't mention PYTHONFAULTHANDER in the list of environment variables (I haven't thoroughly checked that everyone else is there, either).  I would also suggest reordering the environment variables in alphabetical order.

----------
assignee: docs at python
components: Documentation
messages: 245422
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Mention PYTHONFAULTHANDLER in the man page
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 17 08:48:42 2015
From: report at bugs.python.org (David Rueter)
Date: Wed, 17 Jun 2015 06:48:42 +0000
Subject: [New-bugs-announce] [issue24460] urlencode() of dictionary not as
	expected
Message-ID: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za>


New submission from David Rueter:

In Python 3.4 I would like to serialize a dictionary into a URL-encoded string.

Given a dictionary like this: 

>>> thisDict = {'SomeVar1': [b'abc'], 'SomeVar2': [b'def'], 'SomeVar3': [b'ghi']}

I would like to be able to return this string:

	SomeVar1=abc&SomeVar2=def&SomeVar3=ghi

I thought that urllib.parse.urlencode would work for me, but it does not:

>>> print(urllib.parse.urlencode(thisDict))
	SomeVar1=%5Bb%27abc%27%5D&SomeVar2=%5Bb%27def%27%5D&SomeVar3=%5Bb%27ghi%27%5D

In other words, urlencode on the dictionary is performing a URL encode on the string that is returned when the dictionary is cast to a string...and is including the square brackets (escaped) and the byte literal "b" indicator.

{'SomeVar1': [b'abc'], 'SomeVar2': [b'def'], 'SomeVar3': [b'ghi']}

I can obtain the desired string with this:

>>> '&'.join("{!s}={!s}".format(key,urllib.parse.quote_plus(str(val[0],'utf-8'))) for (key,val) in thisDict.items())

Is the behavior of urllib.parse.urlencode() on a dictionary intentional?  When would the current behavior ever be useful?

Would it make sense to change the behavior of urllib.parse.urlencode such that it works as described above?

----------
components: Library (Lib)
messages: 245431
nosy: drueter at assyst.com
priority: normal
severity: normal
status: open
title: urlencode() of dictionary not as expected
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 17 11:51:02 2015
From: report at bugs.python.org (=?utf-8?b?6L+b6ZmG?=)
Date: Wed, 17 Jun 2015 09:51:02 +0000
Subject: [New-bugs-announce] [issue24461] os.environ.get treats Environt
 variant with double quotation marks wrong
Message-ID: <1434534662.14.0.922780196773.issue24461@psf.upfronthosting.co.za>


New submission from ??:

On windows, if a Directory/Filename has SPACE, double quotation mark should be used. For example, "R:\just a test\hello.bat" has only one line "@echo hello world", so in the dos prompt
[quote]
R:\just a test>hello.bat
hello world

R:\just a test>cd ..

R:\>set dir1="R:\just a test"

R:\>set dir2=R:\just a test

R:\>%dir1%\hello.bat
hello world

R:\>%dir2%\hello.bat
'R:\just' is not recognized as an internal or external command 
[/quote]

Then, in python (it seems to be a common problem in all(?) python version)
[quote]
dir1= os.environ.get('dir1')
print (dir1)
print (os.path.isdir(dir1))
print (os.path.isdir(dir1.replace('"', '')))

print ('*'*10)

dir2= os.environ.get('dir2')
print (dir2)
print (os.path.isdir(dir2))
print (os.path.isdir(dir2.replace('"', '')))
[/quote]
displays
[quote]
"R:\just a test"
False                  <--obviously, the double quotation marks is treated as the part of the directory name by python, so the answer is wrong
True
**********
R:\just a test
True
True
[/quote]

the patched method is simple
[quote]
if os.name=='nt':
    res=res.replace('"', '')
[/quote]
but the not simple thing is that os.py for python 3.4.3 changes a lot than os.py for python 2.7, I get lost while reading os.py for python 3.4.3 by no IDE. So I just report this issue, sorry.

----------
components: Library (Lib)
messages: 245433
nosy: ??
priority: normal
severity: normal
status: open
title: os.environ.get treats Environt variant with double quotation marks wrong
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Jun 17 16:26:39 2015
From: report at bugs.python.org (JohnLeitch)
Date: Wed, 17 Jun 2015 14:26:39 +0000
Subject: [New-bugs-announce] [issue24462] bytearray.find Buffer Over-read
Message-ID: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za>


New submission from JohnLeitch:

The bytearray.find method suffers from a buffer over-read that can be triggered by passing a string equal in length to the buffer. The result is a read off the end of the buffer, which could potentially be exploited to disclose the contents of adjacent memory.

Repro:
var_kcjtxvgr = bytearray([0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44])
var_kcjtxvgr.find("\x41" * 0x58)

Exception:
0:000> r
eax=00000002 ebx=00000058 ecx=071adf41 edx=00000000 esi=071f2264 edi=00000057
eip=1e081cf9 esp=0027fc2c ebp=071ae000 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
python27!stringlib_find+0x169:
1e081cf9 0fbe0c2a        movsx   ecx,byte ptr [edx+ebp]     ds:002b:071ae000=??
0:000> dV
            str = 0x071adfa8 "ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD"
        str_len = 0n2
            sub = 0x071f2264 "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
        sub_len = 0n88
         offset = 0n0
0:000> db ebp-0x10
071adff0  41 42 43 44 41 42 43 44-41 42 43 44 41 42 43 44  ABCDABCDABCDABCD
071ae000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071ae010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071ae020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071ae030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071ae040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071ae050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071ae060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> !analyze -v -nodb
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
python27!stringlib_find+169 [c:\build27\cpython\objects\stringlib\find.h @ 22]
1e081cf9 0fbe0c2a        movsx   ecx,byte ptr [edx+ebp]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 1e081cf9 (python27!stringlib_find+0x00000169)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 071ae000
Attempt to read from address 071ae000

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=00000002 ebx=00000058 ecx=071adf41 edx=00000000 esi=071f2264 edi=00000057
eip=1e081cf9 esp=0027fc2c ebp=071ae000 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
python27!stringlib_find+0x169:
1e081cf9 0fbe0c2a        movsx   ecx,byte ptr [edx+ebp]     ds:002b:071ae000=??

FAULTING_THREAD:  00001e90

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  pythonw.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  071ae000

READ_ADDRESS:  071ae000 

FOLLOWUP_IP: 
python27!stringlib_find+169 [c:\build27\cpython\objects\stringlib\find.h @ 22]
1e081cf9 0fbe0c2a        movsx   ecx,byte ptr [edx+ebp]

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APP:  pythonw.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 1e081ee5 to 1e081cf9

STACK_TEXT:  
0027fc48 1e081ee5 071adfa8 071f2264 00000058 python27!stringlib_find+0x169
0027fc5c 1e083ac1 071adfa8 071f2264 00000058 python27!stringlib_find_slice+0x35
0027fcb4 1e083b20 00000001 1e083b10 1e0aafd7 python27!bytearray_find_internal+0x81
0027fcc0 1e0aafd7 070880c8 071d7a10 07086170 python27!bytearray_find+0x10
0027fcd8 1e0edd10 07086170 071d7a10 00000000 python27!PyCFunction_Call+0x47
0027fd04 1e0f017a 0027fd5c 06cc7c80 06cc7c80 python27!call_function+0x2b0
0027fd74 1e0f1150 07060d60 00000000 06cc7c80 python27!PyEval_EvalFrameEx+0x239a
0027fda8 1e0f11b2 06cc7c80 07060d60 06ccba50 python27!PyEval_EvalCodeEx+0x690
0027fdd4 1e11707a 06cc7c80 06ccba50 06ccba50 python27!PyEval_EvalCode+0x22
0027fdec 1e1181c5 0710ee20 06ccba50 06ccba50 python27!run_mod+0x2a
0027fe0c 1e118760 623a7408 06c87fa4 00000101 python27!PyRun_FileExFlags+0x75
0027fe4c 1e1190d9 623a7408 06c87fa4 00000001 python27!PyRun_SimpleFileExFlags+0x190
0027fe68 1e038d35 623a7408 06c87fa4 00000001 python27!PyRun_AnyFileExFlags+0x59
0027fee4 1d001017 00000002 06c87f80 1d0011b6 python27!Py_Main+0x965
0027fef0 1d0011b6 1d000000 00000000 03bdffa0 pythonw!WinMain+0x17
0027ff80 76477c04 7ffde000 76477be0 c4cc721a pythonw!__tmainCRTStartup+0x140
0027ff94 7799ad1f 7ffde000 c53e80b9 00000000 KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7799acea ffffffff 77980232 00000000 ntdll!__RtlUserThreadStart+0x2f
0027ffec 00000000 1d001395 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  c:\build27\cpython\objects\stringlib\find.h

FAULTING_SOURCE_FILE:  c:\build27\cpython\objects\stringlib\find.h

FAULTING_SOURCE_LINE_NUMBER:  22

FAULTING_SOURCE_CODE:  
    18:         return -1;
    19:     if (sub_len == 0)
    20:         return offset;
    21: 
>   22:     pos = fastsearch(str, str_len, sub, sub_len, -1, FAST_SEARCH);
    23: 
    24:     if (pos >= 0)
    25:         pos += offset;
    26: 
    27:     return pos;


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  python27!stringlib_find+169

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: python27

IMAGE_NAME:  python27.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  5488ac17

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_python27.dll!stringlib_find

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_python27!stringlib_find+169

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_python27.dll!stringlib_find

FAILURE_ID_HASH:  {e37593ba-d07f-07cf-b7e5-32630cfd6e24}

Followup: MachineOwner
---------

----------
files: bytearray.find_Buffer_Over-read.py
messages: 245436
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: bytearray.find Buffer Over-read
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file39719/bytearray.find_Buffer_Over-read.py

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

From report at bugs.python.org  Thu Jun 18 13:01:13 2015
From: report at bugs.python.org (vasya yugov)
Date: Thu, 18 Jun 2015 11:01:13 +0000
Subject: [New-bugs-announce] [issue24463] Python 3.4 bugs
Message-ID: <1434625273.11.0.800818633314.issue24463@psf.upfronthosting.co.za>


New submission from vasya yugov:

This code:

w = [[0] * 2] * 2
w[1][1] = 1
print(w)

prints
[[0, 1], [0, 1]]
Is it a bug?

----------
components: Macintosh
messages: 245460
nosy: ned.deily, ronaldoussoren, vasya yugov
priority: normal
severity: normal
status: open
title: Python 3.4 bugs
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jun 18 13:31:43 2015
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 18 Jun 2015 11:31:43 +0000
Subject: [New-bugs-announce] [issue24464] Got warning when compiling sqlite3
	module on Mac OSX
Message-ID: <1434627103.24.0.34027869681.issue24464@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I got this warning when compiling sqlite3 module.

gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DMODULE_NAME="sqlite3" -DSQLITE_OMIT_LOAD_EXTENSION=1 -IModules/_sqlite -I/usr/include -I./Include -I. -IInclude -I/usr/local/include -I/Users/sky/Code/python/cpython/Include -I/Users/sky/Code/python/cpython -c /Users/sky/Code/python/cpython/Modules/_sqlite/module.c -o build/temp.macosx-10.10-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_sqlite/module.o
/Users/sky/Code/python/cpython/Modules/_sqlite/module.c:136:10: warning: 'sqlite3_enable_shared_cache' is
      deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
    rc = sqlite3_enable_shared_cache(do_enable);
         ^
/usr/include/sqlite3.h:5006:16: note: 'sqlite3_enable_shared_cache' has been explicitly marked deprecated here
SQLITE_API int sqlite3_enable_shared_cache(int) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_7, __I...
               ^
1 warning generated.

The enable_shared_cache method will fail if it is used afterwards.
"Changing the shared_cache flag failed"

Here is the patch to remove the warning.

----------
components: Macintosh
files: remove_warning_compile__sqlite.patch
keywords: patch
messages: 245463
nosy: ned.deily, ronaldoussoren, vajrasky
priority: normal
severity: normal
status: open
title: Got warning when compiling sqlite3 module on Mac OSX
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39726/remove_warning_compile__sqlite.patch

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

From report at bugs.python.org  Thu Jun 18 14:14:12 2015
From: report at bugs.python.org (Sam Thursfield)
Date: Thu, 18 Jun 2015 12:14:12 +0000
Subject: [New-bugs-announce] [issue24465] Make tar files created by
 shutil.make_archive() have deterministic sorting
Message-ID: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za>


New submission from Sam Thursfield:

I want shutil.make_archive() to produce deterministic output when given identical data as inputs.

Right now there are two holes in this. One is that mtimes might not match. This can be fixed by the caller. The second is that the order that files in a subdirectory get added to the tarfile is not deterministic. This can't be fixed by the caller.

Attached is a trivial patch to sort the results of os.listdir() to ensure the output tarfile is stable.

This only applies to the 'tar' format.

I've attached my testcase for this, which creates 3 tarfiles in /tmp. When this patch is applied, the 3 tarfiles it creates are identical according to `sha1sum`. Without this patch, they are all different.

----------
components: Library (Lib)
files: tar-reproducible-testcase.py
messages: 245464
nosy: samthursfield
priority: normal
severity: normal
status: open
title: Make tar files created by shutil.make_archive() have deterministic sorting
type: enhancement
Added file: http://bugs.python.org/file39727/tar-reproducible-testcase.py

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

From report at bugs.python.org  Thu Jun 18 16:33:16 2015
From: report at bugs.python.org (alanf)
Date: Thu, 18 Jun 2015 14:33:16 +0000
Subject: [New-bugs-announce] [issue24466] extend_path explanation in
	documentation is ambiguous
Message-ID: <1434637996.53.0.698059319376.issue24466@psf.upfronthosting.co.za>


New submission from alanf:

The description of pkgutil.extend_path in the doc (e.g., https://docs.python.org/2/library/pkgutil.html , https://docs.python.org/3/library/pkgutil.html ) is so ambiguous that I had to run a test to understand its behavior.

The doc says:

This will add to the package?s __path__ all subdirectories of directories on sys.path named after the package.

It wasn't clear to me how this should be parsed. Using parentheses to group the clauses, there's this possibility :

(1) This will add to the package?s __path__ all (subdirectories of directories on sys.path) named after the package.

That is, given all subdirectories of directories on sys.path, find the ones that are named after the package, and add them to the package's __path__.

or:

(2) This will add to the package?s __path__ all subdirectories of (directories on sys.path named after the package).

That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__.

or: 

(3) This will add to the package?s __path__ all subdirectories of ((directories on sys.path) named after the package).

That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__.

or:

(4) This will add to the package?s __path__ all (subdirectories of (directories on sys.path)) named after the package.

That is, given all directories on sys.path, add any of their subdirectories that are named after the package to the package's __path__.

It was also unclear to me whether the subdirectories were meant to be traversed recursively.

My testing indicates that (4) is the correct parse, and that the subdirectories are not meant to be traversed recursively.

I suggest this wording: For each directory on sys.path that has a subdirectory that matches the package name, add the subdirectory to the package's __path__.

----------
assignee: docs at python
components: Documentation
messages: 245468
nosy: alanf, docs at python
priority: normal
severity: normal
status: open
title: extend_path explanation in documentation is ambiguous
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Jun 18 23:04:35 2015
From: report at bugs.python.org (JohnLeitch)
Date: Thu, 18 Jun 2015 21:04:35 +0000
Subject: [New-bugs-announce] [issue24467] bytearray pop and remove Buffer
	Over-read
Message-ID: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za>


New submission from JohnLeitch:

The bytearray pop and remove methods suffer from buffer over-reads caused by memmove use under the assumption that PyByteArrayObject ob_size is less than ob_alloc, leading to a single byte over-read. This condition can be triggered by creating a bytearray from a range of length 0x10, then calling pop with a valid index:

bytearray(range(0x10)).pop(0)

The result is a memmove that reads off the end of src:

0:000> r
eax=071aeff0 ebx=00000000 ecx=071aeff1 edx=00000010 esi=06ff80c8 edi=00000010
eip=6234b315 esp=0027fc98 ebp=0027fca0 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
MSVCR90!memmove+0x5:
6234b315 8b750c          mov     esi,dword ptr [ebp+0Ch] ss:002b:0027fcac=071aeff1
0:000> dV
            dst = 0x071aeff0 ""
            src = 0x071aeff1 "???"
          count = 0x10
0:000> db poi(dst)
071aeff0  00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f  ................
071af000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> db poi(src)
071aeff1  01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f ??  ...............?
071af001  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af011  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af021  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af031  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af041  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af051  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
071af061  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> g
(1968.1a88): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0c0b0a09 ebx=00000000 ecx=00000004 edx=00000000 esi=071aeff1 edi=071aeff0
eip=6234b468 esp=0027fc98 ebp=0027fca0 iopl=0         nv up ei ng nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010297
MSVCR90!UnwindUpVec+0x50:
6234b468 8b448efc        mov     eax,dword ptr [esi+ecx*4-4] ds:002b:071aeffd=????????
0:000> k
ChildEBP RetAddr  
0027fca0 1e0856aa MSVCR90!UnwindUpVec+0x50 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\Intel\MEMCPY.ASM @ 322]
0027fcc0 1e0aafd7 python27!bytearray_pop+0x8a [c:\build27\cpython\objects\bytearrayobject.c @ 2378]
0027fcd8 1e0edd10 python27!PyCFunction_Call+0x47 [c:\build27\cpython\objects\methodobject.c @ 81]
0027fd04 1e0f017a python27!call_function+0x2b0 [c:\build27\cpython\python\ceval.c @ 4033]
0027fd74 1e0f1150 python27!PyEval_EvalFrameEx+0x239a [c:\build27\cpython\python\ceval.c @ 2682]
0027fda8 1e0f11b2 python27!PyEval_EvalCodeEx+0x690 [c:\build27\cpython\python\ceval.c @ 3265]
0027fdd4 1e11707a python27!PyEval_EvalCode+0x22 [c:\build27\cpython\python\ceval.c @ 672]
0027fdec 1e1181c5 python27!run_mod+0x2a [c:\build27\cpython\python\pythonrun.c @ 1371]
0027fe0c 1e118760 python27!PyRun_FileExFlags+0x75 [c:\build27\cpython\python\pythonrun.c @ 1358]
0027fe4c 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190 [c:\build27\cpython\python\pythonrun.c @ 950]
0027fe68 1e038d35 python27!PyRun_AnyFileExFlags+0x59 [c:\build27\cpython\python\pythonrun.c @ 753]
0027fee4 1d001017 python27!Py_Main+0x965 [c:\build27\cpython\modules\main.c @ 643]
0027fef0 1d0011b6 pythonw!WinMain+0x17 [c:\build27\cpython\pc\winmain.c @ 15]
0027ff80 76477c04 pythonw!__tmainCRTStartup+0x140 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578]
0027ff94 7799ad1f KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7799acea ntdll!__RtlUserThreadStart+0x2f
0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b

If the over-read is allowed to succeed, a byte adjacent to the buffer is copied:

0:000> r
eax=01d8e978 ebx=00000000 ecx=00000000 edx=0000003a esi=01dc80c8 edi=00000010
eip=1e08569a esp=0027fd0c ebp=01d5aa10 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
python27!bytearray_pop+0x7a:
1e08569a 8bd7            mov     edx,edi
0:000> dt self
Local var @ 0x27fd20 Type PyByteArrayObject*
0x01dc80c8 
   +0x000 ob_refcnt        : 0n2
   +0x004 ob_type          : 0x1e21a6d0 _typeobject
   +0x008 ob_size          : 0n16
   +0x00c ob_exports       : 0n0
   +0x010 ob_alloc         : 0n16
   +0x014 ob_bytes         : 0x01d8e978  ""
0:000> db 0x01d8e978
01d8e978  00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f  ................
01d8e988  ab ab ab ab ab ab ab ab-00 00 00 00 00 00 00 00  ................
01d8e998  da 49 7a 0e b6 ac 10 00-b0 af d8 01 78 1c ce 01  .Iz.........x...
01d8e9a8  ee fe ee fe ee fe ee fe-ee fe ee fe ee fe ee fe  ................
01d8e9b8  5f 49 79 88 b7 ac 10 1d-02 00 00 00 f8 8b 22 1e  _Iy...........".
01d8e9c8  d6 03 00 00 ff ff ff ff-00 00 00 00 20 54 72 69  ............ Tri
01d8e9d8  65 73 20 74 6f 20 64 65-74 65 72 6d 69 6e 65 20  es to determine 
01d8e9e8  74 68 65 20 64 65 66 61-75 6c 74 20 6c 6f 63 61  the default loca
0:000> p
eax=01d8e978 ebx=00000000 ecx=00000004 edx=00000000 esi=01dc80c8 edi=00000010
eip=1e0856aa esp=0027fd00 ebp=01d5aa10 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
python27!bytearray_pop+0x8a:
1e0856aa 4f              dec     edi
0:000> db 0x01d8e978
01d8e978  01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f ab  ................
01d8e988  ab ab ab ab ab ab ab ab-00 00 00 00 00 00 00 00  ................
01d8e998  da 49 7a 0e b6 ac 10 00-b0 af d8 01 78 1c ce 01  .Iz.........x...
01d8e9a8  ee fe ee fe ee fe ee fe-ee fe ee fe ee fe ee fe  ................
01d8e9b8  5f 49 79 88 b7 ac 10 1d-02 00 00 00 f8 8b 22 1e  _Iy...........".
01d8e9c8  d6 03 00 00 ff ff ff ff-00 00 00 00 20 54 72 69  ............ Tri
01d8e9d8  65 73 20 74 6f 20 64 65-74 65 72 6d 69 6e 65 20  es to determine 
01d8e9e8  74 68 65 20 64 65 66 61-75 6c 74 20 6c 6f 63 61  the default loca

However, a subsequent call to PyByteArray_Resize overwrites the copied byte with a null terminator:

0:000> p
eax=00000000 ebx=00000000 ecx=00000004 edx=00000000 esi=01dc80c8 edi=0000000f
eip=1e0856c0 esp=0027fd0c ebp=01d5aa10 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
python27!bytearray_pop+0xa0:
1e0856c0 0fb6d3          movzx   edx,bl
0:000> db 0x01d8e978
01d8e978  01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 00  ................
01d8e988  ab ab ab ab ab ab ab ab-00 00 00 00 00 00 00 00  ................
01d8e998  da 49 7a 0e b6 ac 10 00-b0 af d8 01 78 1c ce 01  .Iz.........x...
01d8e9a8  ee fe ee fe ee fe ee fe-ee fe ee fe ee fe ee fe  ................
01d8e9b8  5f 49 79 88 b7 ac 10 1d-02 00 00 00 f8 8b 22 1e  _Iy...........".
01d8e9c8  d6 03 00 00 ff ff ff ff-00 00 00 00 20 54 72 69  ............ Tri
01d8e9d8  65 73 20 74 6f 20 64 65-74 65 72 6d 69 6e 65 20  es to determine 
01d8e9e8  74 68 65 20 64 65 66 61-75 6c 74 20 6c 6f 63 61  the default loca

Because of this, these vulnerabilities should be classified as defense-in-depth. If PyByteArray_Resize could be forced to fail, or its behavior changes at a future date, it may become possible to exploit these issues to read adjacent memory.

----------
files: bytearray.pop_Buffer_Over-read.py
messages: 245483
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: bytearray pop and remove Buffer Over-read
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file39731/bytearray.pop_Buffer_Over-read.py

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

From report at bugs.python.org  Fri Jun 19 06:47:33 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 19 Jun 2015 04:47:33 +0000
Subject: [New-bugs-announce] [issue24468] Expose compiler flag constants as
	code object attributes
Message-ID: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As part of the PEP 492 implementation, Yury has needed to hardcode compile flag contants in various places, with adjacent comments explaining what the magic numbers mean.

It occurred to me that there's a way we could make those constants readily available to any code manipulating code objects: expose them as read-only attributes via the code object type.

Does this seem like a reasonable idea?

If yes, would it be reasonable to classify it as part of the PEP 492 implementation process and include it during the 3.5 beta cycle?

----------
messages: 245487
nosy: gvanrossum, larry, ncoghlan, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose compiler flag constants as code object attributes
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 19 08:31:18 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 19 Jun 2015 06:31:18 +0000
Subject: [New-bugs-announce] [issue24469] Py2.x int free list can grow
	without bounds
Message-ID: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

A Cython user noticed a memory leak when C-inheriting from "int".

http://thread.gmane.org/gmane.comp.python.cython.devel/15689

The Cython code to reproduce this is simply this:

    cdef class ExtendedInt(int): pass
 
    for j in xrange(10000000):
        ExtendedInt(j)

The problem is due to the free-list of the int type. It uses this code for deallocation:

"""
static void
int_dealloc(PyIntObject *v)
{
    if (PyInt_CheckExact(v)) {
        Py_TYPE(v) = (struct _typeobject *)free_list;
        free_list = v;
    }
    else
        Py_TYPE(v)->tp_free((PyObject *)v);
}

static void
int_free(PyIntObject *v)
{
    Py_TYPE(v) = (struct _typeobject *)free_list;
    free_list = v;
}
"""

Now, when C-inheriting from PyInt_Type without providing an own tp_free implementation, PyType_Ready() will inherit the supertype's tp_free slot, which means that int_dealloc() above will end up calling int_free() in all cases, not only for the exact-int case. Thus, whether or not it's exactly "int" or a subtype, the object will always be added to the free-list on deallocation.

However, in the subtype case, the free-list is actually ignored by int_new() and int_subtype_new(), so that as long as the user code only creates tons of int subtype instances and not plain int instances, the freelist will keep growing without bounds by pushing dead subtype objects onto it that are never reused.

There are two problems here:

1) int subtypes should not be added to the freelist, or at least not unless they have exactly the same struct size as PyIntObject (which the ExtendedInt type above does but other subtypes may not)

2) if a free-list is used, it should be used in all instantiation cases, not just in PyInt_FromLong().

Fixing 1) by adding a type check to int_free() would be enough to fix the overall problem. Here's a quickly hacked up change that seems to work for me:

"""
static void
int_free(PyIntObject *v)
{
    if (PyInt_CheckExact(v)) {
        Py_TYPE(v) = (struct _typeobject *)free_list;
        free_list = v;
    }
    else if (Py_TYPE(v)->tp_flags & Py_TPFLAGS_HAVE_GC)
        PyObject_GC_Del(v);  // untested by probably necessary
    else
        PyObject_Del(v);
}
"""

----------
components: Interpreter Core
messages: 245492
nosy: scoder
priority: normal
severity: normal
status: open
title: Py2.x int free list can grow without bounds
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 19 10:35:40 2015
From: report at bugs.python.org (Marco Clemencic)
Date: Fri, 19 Jun 2015 08:35:40 +0000
Subject: [New-bugs-announce] [issue24470] ctypes incorrect handling of long
	int on 64bits Linux
Message-ID: <1434702940.98.0.688877329391.issue24470@psf.upfronthosting.co.za>


New submission from Marco Clemencic:

When passing a Python int to a C function expecting long int (or void*) via ctypes, the number gets truncated to 32 bits, even if the args types are correctly declared.
The workaround is to wrap the argument in c_long (or c_void_p), but the automatic unwrapping of c_long (or c_void_p) in the return type lead to undefined behaviour in code like:

myClib.getNumber.restype = c_long
myClib.doSomething.args = [c_long]
l = myClib.getnumber()
myClib.doSomething(l)

----------
components: ctypes
files: test_py.tar.bz2
messages: 245494
nosy: Marco Clemencic
priority: normal
severity: normal
status: open
title: ctypes incorrect handling of long int on 64bits Linux
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file39736/test_py.tar.bz2

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

From report at bugs.python.org  Fri Jun 19 14:01:04 2015
From: report at bugs.python.org (=?utf-8?b?6ZmI5a+M?=)
Date: Fri, 19 Jun 2015 12:01:04 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMjQ0NzFdIOWMl+S6rOWwjw==?=
 =?utf-8?b?5aeQ5om+5LiK6Zeo5YWo5aWX5pyN5Yqh?=
Message-ID: <1434715264.3.0.140511117983.issue24471@psf.upfronthosting.co.za>


New submission from ??:

? ? ? ? ? ? ? ? ?188.0207.9509? ? ?188.0207.9509?? ? 10?20 ? ? ? ? 2 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ? ?(? ?),(? ?) ? ? ? ? ? ? ? 1 ? ? ? ?`? ? ? ? 1 ? ? ? `? ? `? ? ? ? ?! ? ? ? 1 ? ? ?:188.0207.9509 ? ? MM ? ? ? ? ? ? ? ?! ?? ? ? ?? ?1?? ? ? ? 3 ? ? ? ? ? ? ? ? ? ?? ? ? ? ?? ? ? ? 3 ? ? ? ?? ? ? ? ? ? ?! ?2? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ! ?3? ? ? ? ?:188.0207.9509? ?ewgreth1111111

----------
components: Benchmarks
files: 69f0d6e0ecbcee6fbb52097c52a7ee76.jpg
messages: 245499
nosy: ddssaa123123
priority: normal
severity: normal
status: open
title: ???????????
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file39737/69f0d6e0ecbcee6fbb52097c52a7ee76.jpg

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

From report at bugs.python.org  Fri Jun 19 14:24:07 2015
From: report at bugs.python.org (=?utf-8?b?6ZmI5a+M?=)
Date: Fri, 19 Jun 2015 12:24:07 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMjQ0NzJdIOefs+WutuW6hA==?=
 =?utf-8?b?5bCP5aeQ5om+5LiK6Zeo5YWo5aWX5pyN5Yqh?=
Message-ID: <1434716647.75.0.323634381134.issue24472@psf.upfronthosting.co.za>


New submission from ??:

? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ?188.0207.9509?? ? 10?20 ? ? ? ? 2 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ? ?(? ?),(? ?) ? ? ? ? ? ? ? 1 ? ? ? ?`? ? ? ? 1 ? ? ? `? ? `? ? ? ? ?! ? ? ? 1 ? ? ?:188.0207.9509 ? ? MM ? ? ? ? ? ? ? ?! ?? ? ? ?? ?1?? ? ? ? 3 ? ? ? ? ? ? ? ? ? ?? ? ? ? ?? ? ? ? 3 ? ? ? ?? ? ? ? ? ? ?! ?2? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ! ?3? ? ? ? ?:188.0207.9509? ?ewgreth1111111

----------
components: Benchmarks
files: 9F059BE32A3FC19A52978B2901172641.jpg
messages: 245501
nosy: ddssaa123123
priority: normal
severity: normal
status: open
title: ????????????
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file39738/9F059BE32A3FC19A52978B2901172641.jpg

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

From report at bugs.python.org  Fri Jun 19 14:29:56 2015
From: report at bugs.python.org (=?utf-8?b?6ZmI5a+M?=)
Date: Fri, 19 Jun 2015 12:29:56 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMjQ0NzNdIOWNl+S6rOWwjw==?=
 =?utf-8?b?5aeQ5om+5LiK6Zeo5YWo5aWX5pyN5Yqh?=
Message-ID: <1434716996.22.0.597253490197.issue24473@psf.upfronthosting.co.za>


New submission from ??:

? ? ? ? ? ? ? ? ?188.0207.9509? ? ?188.0207.9509?? ? 10?20 ? ? ? ? 2 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ? ?(? ?),(? ?) ? ? ? ? ? ? ? 1 ? ? ? ?`? ? ? ? 1 ? ? ? `? ? `? ? ? ? ?! ? ? ? 1 ? ? ?:188.0207.9509 ? ? MM ? ? ? ? ? ? ? ?! ?? ? ? ?? ?1?? ? ? ? 3 ? ? ? ? ? ? ? ? ? ?? ? ? ? ?? ? ? ? 3 ? ? ? ?? ? ? ? ? ? ?! ?2? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ! ?3? ? ? ? ?:188.0207.9509? ?ewgreth1111111

----------
components: Benchmarks
files: 12493721761041772378.jpg
messages: 245502
nosy: ddssaa123123
priority: normal
severity: normal
status: open
title: ???????????
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file39739/12493721761041772378.jpg

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

From report at bugs.python.org  Fri Jun 19 18:16:29 2015
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 19 Jun 2015 16:16:29 +0000
Subject: [New-bugs-announce] [issue24474] Accidental exception chaining in
	inspect.Signature.bind()
Message-ID: <1434730589.67.0.681224722356.issue24474@psf.upfronthosting.co.za>


New submission from Walter D?rwald:

When an exception is raised by inspect.Signature.bind() in some cases the exception has a StopIteration as its __context__:

import inspect

try:
   inspect.signature(lambda x:None).bind()
except Exception as exc:
   print(repr(exc))
   print(repr(exc.__context__))

This prints:

   TypeError("missing a required argument: 'x'",)
   StopIteration()

I would have expected it to print:

   TypeError("missing a required argument: 'x'",)
   None

This reason for this is that the code in bind() has nested exception handlers. The innermost handler does

   raise TypeError(...) from None

to drop the exception context, but another context exception gets added by the outermost exception handler.

----------
messages: 245506
nosy: doerwalter
priority: normal
severity: normal
status: open
title: Accidental exception chaining in inspect.Signature.bind()

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

From report at bugs.python.org  Fri Jun 19 19:05:37 2015
From: report at bugs.python.org (Zahari Dim)
Date: Fri, 19 Jun 2015 17:05:37 +0000
Subject: [New-bugs-announce] [issue24475] The docs never define what a pool
	"task" is
Message-ID: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za>


New submission from Zahari Dim:

See:

http://stackoverflow.com/questions/30943161/multiprocessing-pool-with-maxtasksperchild-produces-equal-pids

The documentation never makes clear what a "task" in the context of Pool.map. At best, it says:

"This method chops the iterable into a number of chunks which it submits to the process pool as separate tasks. The (approximate) size of these chunks can be specified by setting chunksize to a positive integer."

in the map documentation. However it does not say how this chunks are calculated by default, making the maxtasksperchild argument not very useful. The fact that a function evaluated by map is not a "task" should be much clearer in the documentation.

Also, in the examples, such as:

 with multiprocessing.Pool(PROCESSES) as pool:
        #
        # Tests
        #

        TASKS = [(mul, (i, 7)) for i in range(10)] + \
                [(plus, (i, 8)) for i in range(10)]

        results = [pool.apply_async(calculate, t) for t in TASKS]
        imap_it = pool.imap(calculatestar, TASKS)
        imap_unordered_it = pool.imap_unordered(calculatestar, TASKS)

TASKS are not actually "tasks" but rather "task groups".

----------
assignee: docs at python
components: Documentation
messages: 245509
nosy: Zahari.Dim, docs at python
priority: normal
severity: normal
status: open
title: The docs never define what a pool "task" is
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 19 19:48:25 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 19 Jun 2015 17:48:25 +0000
Subject: [New-bugs-announce] [issue24476] Statically link vcruntime140.dll
Message-ID: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za>


New submission from Steve Dower:

It's possible to statically link the vcruntime140.dll dependency without statically linking the entire CRT, which will save us from having to redistribute the file (meaning the entire CRT dependency is now system components).

Patch to follow, and I'm very +1 on this, but didn't want to skip the chance for people to raise concerns or questions.

----------
assignee: steve.dower
components: Windows
messages: 245511
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Statically link vcruntime140.dll
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jun 20 02:52:43 2015
From: report at bugs.python.org (py.user)
Date: Sat, 20 Jun 2015 00:52:43 +0000
Subject: [New-bugs-announce] [issue24477] In argparse subparser's option
	goes to parent parser
Message-ID: <1434761563.1.0.609201116133.issue24477@psf.upfronthosting.co.za>


New submission from py.user:

Some misleading behaviour found with option belonging.
It's possible to put one option twicely, so it can set different
parameters accoding to context.

A source of argt.py for test:

#!/usr/bin/env python3

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('-f', dest='tf', action='store_true')

subs = parser.add_subparsers()

sub = subs.add_parser('cmd')
sub.add_argument('-f', dest='cf', action='store_true')

parser.add_argument('arg')

args = parser.parse_args()
print(args)


Running it:

[guest at localhost debug]$ ./argt.py cmd 1
Namespace(arg='1', cf=False, tf=False)
[guest at localhost debug]$ ./argt.py cmd -f 1
Namespace(arg='1', cf=True, tf=False)
[guest at localhost debug]$ ./argt.py cmd 1 -f
Namespace(arg='1', cf=False, tf=True)
[guest at localhost debug]$


ISTM, options for the top parser should be placed between program name and subcommand name in any order, and options for the subcommand should follow subcommand in any order. The argument of top parser should be moved to the end and parsed after all options were placed correctly.

----------
components: Library (Lib)
messages: 245536
nosy: py.user
priority: normal
severity: normal
status: open
title: In argparse subparser's option goes to parent parser
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Jun 20 09:38:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jun 2015 07:38:54 +0000
Subject: [New-bugs-announce] [issue24478] asyncio: segfault in
 test_env_var_debug() on non-debug Windows buildbot
Message-ID: <1434785934.32.0.696273570884.issue24478@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like buildbot slave crashs since:
http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/23
or
http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/22

Changes: changeset a1b76c1c3be8409565af71b02b84685233276120

======================================================================
FAIL: test_env_var_debug (test.test_asyncio.test_base_events.BaseEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "B:\buildarea\3.x.ware-win81-release\build\lib\test\test_asyncio\test_base_events.py", line 680, in test_env_var_debug
    PYTHONASYNCIODEBUG='')
  File "B:\buildarea\3.x.ware-win81-release\build\lib\test\support\script_helper.py", line 135, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "B:\buildarea\3.x.ware-win81-release\build\lib\test\support\script_helper.py", line 121, in _assert_python
    err))
AssertionError: Process return code is 3221225477
command line: ['B:\\buildarea\\3.x.ware-win81-release\\build\\PCbuild\\amd64\\python.exe', '-X', 'faulthandler', '-c', 'import asyncio\nloop = asyncio.get_event_loop()\nprint(loop.get_debug())']

stdout:
---

---

stderr:
---
Fatal Python error: Segmentation fault

Current thread 0x00000390 (most recent call first):
  File "B:\buildarea\3.x.ware-win81-release\build\lib\functools.py", line 423 in decorating_function
  File "B:\buildarea\3.x.ware-win81-release\build\lib\ipaddress.py", line 1963 in IPv6Address
  File "B:\buildarea\3.x.ware-win81-release\build\lib\ipaddress.py", line 1869 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 661 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "B:\buildarea\3.x.ware-win81-release\build\lib\ssl.py", line 90 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 661 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\sslproto.py", line 5 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 661 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1016 in _handle_fromlist
  File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\proactor_events.py", line 16 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 661 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1016 in _handle_fromlist
  File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\windows_events.py", line 13 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 661 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\__init__.py", line 46 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 661 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "<string>", line 1 in <module>
---

----------
components: Windows, asyncio
messages: 245551
nosy: gvanrossum, haypo, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot
versions: Python 3.6

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

From report at bugs.python.org  Sat Jun 20 12:18:22 2015
From: report at bugs.python.org (Andreas Nilsson)
Date: Sat, 20 Jun 2015 10:18:22 +0000
Subject: [New-bugs-announce] [issue24479] Support LMMS project files in
	mimetypes.guess_type
Message-ID: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za>


New submission from Andreas Nilsson:

There is no support for recognizing LMMS project files (.mmpz / .mmp). Could this be added for strict=False?

----------
components: Library (Lib)
messages: 245556
nosy: Andreas Nilsson
priority: normal
severity: normal
status: open
title: Support LMMS project files in mimetypes.guess_type
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 20 18:27:45 2015
From: report at bugs.python.org (Yunlong Liu)
Date: Sat, 20 Jun 2015 16:27:45 +0000
Subject: [New-bugs-announce] [issue24480] Python 2.7.10
Message-ID: <1434817665.64.0.647960324638.issue24480@psf.upfronthosting.co.za>


New submission from Yunlong Liu:

Hi,

I detected an inconsistency in the Modules stack of Python 2.7.10. In Module/_ssl.c, I see all _ssl._SSLContext are changed to ssl.SSLContext but it is inconsistent with the lib file in Lib/ssl.py. In ssl.py, it is still importing _SSLContext, which doesn't exist in the C file.

----------
components: Library (Lib)
messages: 245566
nosy: yliu120
priority: normal
severity: normal
status: open
title: Python 2.7.10
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 20 22:40:47 2015
From: report at bugs.python.org (JohnLeitch)
Date: Sat, 20 Jun 2015 20:40:47 +0000
Subject: [New-bugs-announce] [issue24481] hotspot pack_string Heap Buffer
	Overflow
Message-ID: <1434832847.29.0.0777461609837.issue24481@psf.upfronthosting.co.za>


New submission from JohnLeitch:

The hotspot module suffer from a heap buffer overflow due to a memcpy in the pack_string function at line 633:

static int
pack_string(ProfilerObject *self, const char *s, Py_ssize_t len)
{
    if (len + PISIZE + self->index >= BUFFERSIZE) {
        if (flush_data(self) < 0)
            return -1;
    }
    assert(len < INT_MAX);
    if (pack_packed_int(self, (int)len) < 0)
        return -1;
    memcpy(self->buffer + self->index, s, len);
    self->index += len;
    return 0;
}

The problem arises because const char *s is variable length, while ProfilerObject.buffer is fixed-length:

typedef struct {
    PyObject_HEAD
    PyObject *filemap;
    PyObject *logfilename;
    Py_ssize_t index;
    unsigned char buffer[BUFFERSIZE];
    FILE *logfp;
    int lineevents;
    int linetimings;
    int frametimings;
    /* size_t filled; */
    int active;
    int next_fileno;
    hs_time prev_timeofday;
} ProfilerObject;

An overflow can be triggered by passing a large string to the Profile.addinfo method via the value parameter:

from hotshot.stats import *
x = hotshot.Profile("A", "A")
x.addinfo("A", "A" * 0xfceb)

Which produces the following exception:

0:000> r
eax=00000041 ebx=0000fceb ecx=00003532 edx=00000002 esi=075dcb35 edi=075d9000
eip=6c29af1c esp=0027fc78 ebp=0027fc80 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
MSVCR90!LeadUpVec+0x70:
6c29af1c f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
0:000> db edi-0x10
075d8ff0  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075d9000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
075d9010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
075d9020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
075d9030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
075d9040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
075d9050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
075d9060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> db esi
075dcb35  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075dcb45  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075dcb55  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075dcb65  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075dcb75  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075dcb85  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075dcb95  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
075dcba5  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
0:000> !heap -p -a edi
    address 075d9000 found in
    _DPH_HEAP_ROOT @ 6ca1000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 722809c:          75d67c8             2838 -          75d6000             4000
    6c3194ec verifier!AVrfDebugPageHeapAllocate+0x0000023c
    77a257b7 ntdll!RtlDebugAllocateHeap+0x0000003c
    779c77ce ntdll!RtlpAllocateHeap+0x0004665a
    77981134 ntdll!RtlAllocateHeap+0x0000014d
    6c2c3db8 MSVCR90!malloc+0x00000079 [f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163]
    1e0ae6d1 python27!PyObject_Malloc+0x00000161 [c:\build27\cpython\objects\obmalloc.c @ 968]

 
0:000> !heap -p -a esi
    address 075dcb35 found in
    _DPH_HEAP_ROOT @ 6ca1000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 7228068:          75da300             fd00 -          75da000            11000
    6c3194ec verifier!AVrfDebugPageHeapAllocate+0x0000023c
    77a257b7 ntdll!RtlDebugAllocateHeap+0x0000003c
    779c77ce ntdll!RtlpAllocateHeap+0x0004665a
    77981134 ntdll!RtlAllocateHeap+0x0000014d
    6c2c3db8 MSVCR90!malloc+0x00000079 [f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163]
    1e0ae6d1 python27!PyObject_Malloc+0x00000161 [c:\build27\cpython\objects\obmalloc.c @ 968]

 
0:000> k4
ChildEBP RetAddr  
0027fc80 1e008380 MSVCR90!LeadUpVec+0x70 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 289]
0027fc90 1e008407 python27!pack_string+0x40 [c:\build27\cpython\modules\_hotshot.c @ 634]
0027fca8 1e0089bb python27!pack_add_info+0x77 [c:\build27\cpython\modules\_hotshot.c @ 652]
0027fcc0 1e0aafd7 python27!profiler_addinfo+0x5b [c:\build27\cpython\modules\_hotshot.c @ 1020]
0:000> .frame 1
01 0027fc90 1e008407 python27!pack_string+0x40 [c:\build27\cpython\modules\_hotshot.c @ 634]
0:000> dV
           self = 0x075dcb35
              s = 0x075da314 "AAAAAAAAAAAAAAAAAAA[...]AA..."
            len = 0n123572224
0:000> dt self
Local var @ esi Type ProfilerObject*
   +0x000 ob_refcnt        : 0n1094795585
   +0x004 ob_type          : 0x41414141 _typeobject
   +0x008 filemap          : 0x41414141 _object
   +0x00c logfilename      : 0x41414141 _object
   +0x010 index            : 0n1094795585
   +0x014 buffer           : [10240]  "AAAAAAAAAAAAAAAAAAA[...]AA..."
   +0x2814 logfp            : 0x41414141 _iobuf
   +0x2818 lineevents       : 0n1094795585
   +0x281c linetimings      : 0n1094795585
   +0x2820 frametimings     : 0n1094795585
   +0x2824 active           : 0n1094795585
   +0x2828 next_fileno      : 0n1094795585
   +0x2830 prev_timeofday   : 0n4702111234474983745

0:000> !analyze -v -nodb
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
MSVCR90!LeadUpVec+70 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 289]
6c29af1c f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 6c29af1c (MSVCR90!LeadUpVec+0x00000070)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 075d9000
Attempt to write to address 075d9000

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=00000041 ebx=0000fceb ecx=00003532 edx=00000002 esi=075dcb35 edi=075d9000
eip=6c29af1c esp=0027fc78 ebp=0027fc80 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
MSVCR90!LeadUpVec+0x70:
6c29af1c f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

FAULTING_THREAD:  000013b0

PROCESS_NAME:  pythonw.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000001

EXCEPTION_PARAMETER2:  075d9000

WRITE_ADDRESS:  075d9000 

FOLLOWUP_IP: 
MSVCR90!LeadUpVec+70 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 289]
6c29af1c f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APP:  pythonw.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

BUGCHECK_STR:  APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_WRITE_EXPLOITABLE_FILL_PATTERN_NXCODE

PRIMARY_PROBLEM_CLASS:  STRING_DEREFERENCE_EXPLOITABLE_FILL_PATTERN_NXCODE

DEFAULT_BUCKET_ID:  STRING_DEREFERENCE_EXPLOITABLE_FILL_PATTERN_NXCODE

LAST_CONTROL_TRANSFER:  from 1e008380 to 6c29af1c

STACK_TEXT:  
0027fc80 1e008380 075d67df 075da314 0000fceb MSVCR90!LeadUpVec+0x70
0027fc90 1e008407 075da314 1e008960 00000000 python27!pack_string+0x40
0027fca8 1e0089bb 072e67b4 075da314 0769e788 python27!pack_add_info+0x77
0027fcc0 1e0aafd7 075d67c8 071aabc0 0769e788 python27!profiler_addinfo+0x5b
0027fcd8 1e0edd10 0769e788 071aabc0 00000000 python27!PyCFunction_Call+0x47
0027fd04 1e0f017a 0027fd5c 06d57b18 06d57b18 python27!call_function+0x2b0
0027fd74 1e0f1150 071a9870 00000000 06d57b18 python27!PyEval_EvalFrameEx+0x239a
0027fda8 1e0f11b2 06d57b18 071a9870 06d5ba50 python27!PyEval_EvalCodeEx+0x690
0027fdd4 1e11707a 06d57b18 06d5ba50 06d5ba50 python27!PyEval_EvalCode+0x22
0027fdec 1e1181c5 0722e260 06d5ba50 06d5ba50 python27!run_mod+0x2a
0027fe0c 1e118760 6c2f7408 06d17fac 00000101 python27!PyRun_FileExFlags+0x75
0027fe4c 1e1190d9 6c2f7408 06d17fac 00000001 python27!PyRun_SimpleFileExFlags+0x190
0027fe68 1e038d35 6c2f7408 06d17fac 00000001 python27!PyRun_AnyFileExFlags+0x59
0027fee4 1d001017 00000002 06d17f88 1d0011b6 python27!Py_Main+0x965
0027fef0 1d0011b6 1d000000 00000000 04d3ffa8 pythonw!WinMain+0x17
0027ff80 76477c04 7ffde000 76477be0 63080f16 pythonw!__tmainCRTStartup+0x140
0027ff94 7799ad1f 7ffde000 62fa2f53 00000000 KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7799acea ffffffff 77980228 00000000 ntdll!__RtlUserThreadStart+0x2f
0027ffec 00000000 1d001395 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm

FAULTING_SOURCE_FILE:  f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm

FAULTING_SOURCE_LINE_NUMBER:  289

FAULTING_SOURCE_CODE:  
No source found for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm'


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  msvcr90!LeadUpVec+70

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: MSVCR90

IMAGE_NAME:  MSVCR90.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  51ea24a5

FAILURE_BUCKET_ID:  STRING_DEREFERENCE_EXPLOITABLE_FILL_PATTERN_NXCODE_c0000005_MSVCR90.dll!LeadUpVec

BUCKET_ID:  APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_WRITE_EXPLOITABLE_FILL_PATTERN_NXCODE_msvcr90!LeadUpVec+70

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:string_dereference_exploitable_fill_pattern_nxcode_c0000005_msvcr90.dll!leadupvec

FAILURE_ID_HASH:  {006f2a1a-db5d-7798-544b-da0c2e0bcf19}

Followup: MachineOwner
---------

To fix the issue, pack_string should confirm that the fixed-length buffer is of sufficient size prior to performing the memcpy.

----------
files: hotspot_pack_string_Buffer_Overflow.py
messages: 245574
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: hotspot pack_string Heap Buffer Overflow
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file39753/hotspot_pack_string_Buffer_Overflow.py

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

From report at bugs.python.org  Sun Jun 21 12:46:00 2015
From: report at bugs.python.org (Dmitry Odzerikho)
Date: Sun, 21 Jun 2015 10:46:00 +0000
Subject: [New-bugs-announce] [issue24482] itertools.tee causes segfault in a
 multithreading environment, while the equivalent implementation does'nt
Message-ID: <1434883560.45.0.736397732879.issue24482@psf.upfronthosting.co.za>


Changes by Dmitry Odzerikho <dmitry.odzerikho at gmail.com>:


----------
components: Library (Lib)
nosy: Dmitry Odzerikho
priority: normal
severity: normal
status: open
title: itertools.tee causes segfault in a multithreading environment, while the equivalent implementation does'nt
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun 21 14:34:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 21 Jun 2015 12:34:02 +0000
Subject: [New-bugs-announce] [issue24483] Avoid repeated hash calculation in
 C implementation of functools.lru_cache()
Message-ID: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a difference between Python and C implementations of functools.lru_cache(). Python implementation caches the hash of the key, C implementation doesn't. May be this is not too important (at least I have no an example that shows the benefit of caching the hash), but there is a place for possible optimization. Proposed patch uses private functions _PyDict_GetItem_KnownHash() and _PyDict_SetItem_KnownHash() to avoid the second calculating of the hash for new keys.

The hash is still calculated second time when the key is deleted from full cache. To avoid this _PyDict_DelItem_KnownHash() is needed.

----------
components: Library (Lib)
files: clru_cache_known_hash.patch
keywords: patch
messages: 245593
nosy: ncoghlan, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid repeated hash calculation in C implementation of  functools.lru_cache()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file39758/clru_cache_known_hash.patch

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

From report at bugs.python.org  Sun Jun 21 17:08:26 2015
From: report at bugs.python.org (Jorge Herskovic)
Date: Sun, 21 Jun 2015 15:08:26 +0000
Subject: [New-bugs-announce] [issue24484] multiprocessing cleanup
	occasionally throws exception
Message-ID: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za>


New submission from Jorge Herskovic:

I'm writing a library on top of multiprocessing. As part of the test suite, I create and destroy dozens of processes repeatedly. About once in 50 runs, the tests complete successfully but the program crashes with:

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 286, in _exit_function
    _run_finalizers(0)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 246, in _run_finalizers
    items = [x for x in list(_finalizer_registry.items()) if f(x)]
RuntimeError: dictionary changed size during iteration

(this is on OS X 10.10.3, Python 3.4.3; I've been unable to replicate the behavior on Python 2.7.9, 3.5.0b2, or pypy despite hundreds of runs)

The problematic code is available at https://github.com/jherskovic/mpetl and the tests should be run with nosetests

----------
components: Library (Lib)
messages: 245597
nosy: Jorge Herskovic
priority: normal
severity: normal
status: open
title: multiprocessing cleanup occasionally throws exception
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 22 11:41:28 2015
From: report at bugs.python.org (Malthe Borch)
Date: Mon, 22 Jun 2015 09:41:28 +0000
Subject: [New-bugs-announce] [issue24485] Function source inspection fails
	on closures
Message-ID: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za>


New submission from Malthe Borch:

Very simple to reproduce (see attachment).

----------
components: Library (Lib)
files: test.py
messages: 245621
nosy: malthe
priority: normal
severity: normal
status: open
title: Function source inspection fails on closures
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39768/test.py

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

From report at bugs.python.org  Mon Jun 22 15:15:11 2015
From: report at bugs.python.org (Julien Palard)
Date: Mon, 22 Jun 2015 13:15:11 +0000
Subject: [New-bugs-announce] [issue24486] http/client.py block indefinitely
 on line 308 in _read_status
Message-ID: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za>


New submission from Julien Palard:

Requesting HTTP using `requests`, which uses `http.client` which use `socket`, sometimes, my program get stuck like this:

```
File "/usr/lib/python3.2/socket.py", line 287 in readinto
File "/usr/lib/python3.2/http/client.py", line 308 in _read_status
File "/usr/lib/python3.2/http/client.py", line 346 in begin
File "/usr/lib/python3.2/http/client.py", line 1052 in getresponse
... in python requests ...
```

The line is the first of _read_status::

```
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
```

At a lower level, the program is stuck in a `recvfrom()` syscall.

So obviously, an error at the network level caused the server to not reply, but the client recvfrom() the network in a blocking socket without checking first if data is available, so it get stuck indefinitely :-(

----------
components: Library (Lib)
messages: 245626
nosy: Julien.Palard
priority: normal
severity: normal
status: open
title: http/client.py block indefinitely on line 308 in _read_status
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 22 16:24:29 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Jun 2015 14:24:29 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Ea?=
 =?utf-8?b?c3luYygpIOKGkiBlbnN1cmVfZnV0dXJlKCk=?=
Message-ID: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za>


New submission from Martin Panter:

The async() function is marked as deprecated in 3.4.4. This patch replaces most references to it with references to ensure_future(). The exception is <https://docs.python.org/3.4/library/asyncio-eventloop.html#asyncio.BaseEventLoop.create_task>, which suggests using it in Python < 3.4.2.

----------
assignee: docs at python
components: Documentation, asyncio
files: ensure_future.patch
keywords: patch
messages: 245631
nosy: docs at python, gvanrossum, haypo, vadmium, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Change asyncio.async() ? ensure_future()
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39771/ensure_future.patch

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

From report at bugs.python.org  Mon Jun 22 18:45:17 2015
From: report at bugs.python.org (Andreas Hilboll)
Date: Mon, 22 Jun 2015 16:45:17 +0000
Subject: [New-bugs-announce] [issue24488] ConfigParser.getboolean fails on
	boolean options
Message-ID: <1434991517.36.0.491167534114.issue24488@psf.upfronthosting.co.za>


New submission from Andreas Hilboll:

Not sure if this is by design (or if I'm doing something utterly stupid), but I often create a ConfigParser object for my application and then pass this around (or make it global).

So when I do something like

    cfg.set("input_filter", "include_filtered", True)

and then 

    cfg.getboolean("input_filter", "include_filtered")

I receive an error (AttributeError: 'bool' object has no attribute 'lower').

Wouldn't it be more sensible if getboolean would return the raw value in case the raw value is already a boolean?

If not, which would be the best way forward for me?

----------
components: Library (Lib)
messages: 245638
nosy: andreas-h
priority: normal
severity: normal
status: open
title: ConfigParser.getboolean fails on boolean options
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 23 14:15:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Jun 2015 12:15:08 +0000
Subject: [New-bugs-announce] [issue24489] cmath.polar() can raise due to
	pre-existing errno
Message-ID: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is a patch, with additional tests.

----------
components: Library (Lib)
files: polar_errno.patch
keywords: patch
messages: 245678
nosy: mark.dickinson, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: cmath.polar() can raise due to pre-existing errno
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39787/polar_errno.patch

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

From report at bugs.python.org  Tue Jun 23 16:12:09 2015
From: report at bugs.python.org (Jakub Mateusz Kowalski)
Date: Tue, 23 Jun 2015 14:12:09 +0000
Subject: [New-bugs-announce] [issue24490] DeprecationWarning hidden even
 after warnings.filterwarnings('always') called
Message-ID: <1435068729.87.0.403412824944.issue24490@psf.upfronthosting.co.za>


New submission from Jakub Mateusz Kowalski:

The error occurs when there was a warning before the call to filterwarnings():

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn('aa', DeprecationWarning)
>>> warnings.filterwarnings('always')
>>> warnings.warn('aa', DeprecationWarning)
>>>

When filterwarnings() is called before warnings, everything is working as expected:

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.filterwarnings('always')
>>> warnings.warn('aa', DeprecationWarning)
__main__:1: DeprecationWarning: aa
>>> warnings.warn('aa', DeprecationWarning)
__main__:1: DeprecationWarning: aa
>>>

----------
components: Interpreter Core
messages: 245691
nosy: Jakub.Mateusz.Kowalski
priority: normal
severity: normal
status: open
title: DeprecationWarning hidden even after warnings.filterwarnings('always') called
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 23 18:46:56 2015
From: report at bugs.python.org (Zorceta)
Date: Tue, 23 Jun 2015 16:46:56 +0000
Subject: [New-bugs-announce] [issue24491] inspect.getsource can't get source
 code if provided function isn't from a file
Message-ID: <1435078016.43.0.770185123709.issue24491@psf.upfronthosting.co.za>


New submission from Zorceta:

Both python.exe and IDLE can't. IPython is able to, as it inserts REPL input into linecache.

----------
messages: 245694
nosy: zorceta
priority: normal
severity: normal
status: open
title: inspect.getsource can't get source code if provided function isn't from a file
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jun 23 19:40:13 2015
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 23 Jun 2015 17:40:13 +0000
Subject: [New-bugs-announce] [issue24492] using custom objects as modules:
 AttributeErrors new in 3.5
Message-ID: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>


New submission from Armin Rigo:

A regression in 3.5: if we use custom objects as modules (like some projects do), then these custom objects may not have an attribute called "__name__".  There is new code in 3.5 added for issue #17636 which tries sometimes to read the "__name__" of a module when executing an import statement, and if this leads to an AttributeError, it will get propagated.

I imagine this could break real code using "try: except ImportError:".  It _does_ break the tests of the "cffi" project, which try to check that some import of a nonexisting name correctly gives ImportError.  Now it gives AttributeError("__name__") instead.

----------
components: Interpreter Core
keywords: 3.4regression
messages: 245696
nosy: arigo, larry
priority: normal
severity: normal
status: open
title: using custom objects as modules: AttributeErrors new in 3.5
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun 23 22:37:07 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Tue, 23 Jun 2015 20:37:07 +0000
Subject: [New-bugs-announce] [issue24493] subprocess with env=os.environ
 fails with "fatal python error" when calling 32-bit python from 64-bit one
 on Windows
Message-ID: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

Trying to call a 32bit Python via subprocess from a 64bit one works as expected:

    Python 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:16:31) [MSC v.1600 64 bit (AMD64)] on win32
    [...]
    >>> subprocess.check_call([r'C:\Python34_x32\python.exe', '-c', 'print("Hello World")'])
    Hello World

However, when passing the `env` parameter, even just as `env=os.environ`, things break:

    >>> subprocess.check_call([r'C:\Python34_x32\python.exe', '-c', 'print("Hello World")'], env=os.environ)
    Fatal Python error: Failed to initialize Windows random API (CryptoGen)

Starting a 64bit Python from the 64bit one works fine:

    >>> subprocess.check_call([r'C:\Python34\python.exe', '-c', 'print("Hello World")'], env=os.environ)
    Hello World

According to issue20614 the "Fatal Python error" happens when SYSTEMROOT is not set, but that's definitely set in the original environment.

Looking at the code, it just passes env to Windows' CreateProcess[1] - I guess this does *something* different in this scenario when None/NULL is given as compared to the os.environ dict?

This breaks virtualenv with --python for me:

    C:\Users\florian\tmp>C:\Python34\python.exe -m virtualenv --python=C:\Python34_x32\python.exe venv3
    Running virtualenv with interpreter C:\Python34_x32\python.exe
    Fatal Python error: Failed to initialize Windows random API (CryptoGen)

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

----------
components: Library (Lib), Windows
messages: 245700
nosy: The Compiler, astrand, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess with env=os.environ fails with "fatal python error" when calling 32-bit python from 64-bit one on Windows
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 24 05:47:29 2015
From: report at bugs.python.org (lilydjwg)
Date: Wed, 24 Jun 2015 03:47:29 +0000
Subject: [New-bugs-announce] [issue24494] Can't specify encoding with
	fileinput and inplace=True
Message-ID: <1435117649.09.0.218021607576.issue24494@psf.upfronthosting.co.za>


New submission from lilydjwg:

I want to use fileinput to modify files, but find no way to specify the file encoding. I tried to use "hook_encoded", but it says "FileInput cannot use an opening hook in inplace mode".

----------
components: Library (Lib)
messages: 245711
nosy: lilydjwg
priority: normal
severity: normal
status: open
title: Can't specify encoding with fileinput and inplace=True
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 24 10:35:28 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Jun 2015 08:35:28 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue24495=5D_asyncio=2Eensure?=
 =?utf-8?b?X2Z1dHVyZSgpIEF0dHJpYnV0ZUVycm9yIHdpdGgg4oCcYXN5bmMgZGVm4oCd?=
 =?utf-8?q?_coroutines?=
Message-ID: <1435134928.01.0.885019628037.issue24495@psf.upfronthosting.co.za>


New submission from Martin Panter:

While trying to port the example at <https://docs.python.org/3.5/library/asyncio-task.html#example-future-with-run-until-complete> to use ?async def?, I discovered the ensure_future() function does not like the coroutine field name changes introduced in Issue 24400:

>>> asyncio.ensure_future(slow_operation(future))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/proj/python/cpython/Lib/asyncio/futures.py", line 196, in __repr__
    info = self._repr_info()
  File "/home/proj/python/cpython/Lib/asyncio/tasks.py", line 105, in _repr_info
    coro = coroutines._format_coroutine(self._coro)
  File "/home/proj/python/cpython/Lib/asyncio/coroutines.py", line 242, in _format_coroutine
    filename = coro.gi_code.co_filename
AttributeError: 'coroutine' object has no attribute 'gi_code'

I understand the gi_ names all changed to cr_, so I guess this code has to adjust as well.

----------
components: asyncio
messages: 245727
nosy: gvanrossum, haypo, vadmium, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: asyncio.ensure_future() AttributeError with ?async def? coroutines
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun 24 12:17:13 2015
From: report at bugs.python.org (=?utf-8?b?SmFrdWIgS2FkbMSNw61r?=)
Date: Wed, 24 Jun 2015 10:17:13 +0000
Subject: [New-bugs-announce] [issue24496] Non-idiomatic examples in gzip docs
Message-ID: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za>


New submission from Jakub Kadl??k:

Hello, I think there are awesome example code snippets in gzip documentation. No doubt, they helped me a lot.

The only problem is that they are not idiomatic. They look like C more than Python.

I suggest following patch

----------
assignee: docs at python
components: Documentation
files: idiomatic-gzip.diff
keywords: patch
messages: 245729
nosy: FrostyX, docs at python
priority: normal
severity: normal
status: open
title: Non-idiomatic examples in gzip docs
type: enhancement
Added file: http://bugs.python.org/file39796/idiomatic-gzip.diff

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

From report at bugs.python.org  Wed Jun 24 14:36:04 2015
From: report at bugs.python.org (mattyw)
Date: Wed, 24 Jun 2015 12:36:04 +0000
Subject: [New-bugs-announce] [issue24497] test_decimal.py contains a dead
	link
Message-ID: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za>


New submission from mattyw:

The comments in test_decimal contain a url for downloading tests written by  Mike Cowlishaw:

Cowlishaw's tests can be downloaded from:                                       
                                                                               
    www2.hursley.ibm.com/decimal/dectest.zip

Python 3.4.3 contains an updated url:
http://speleotrove.com/decimal/dectest.zip

It seems like the url should be updated in 2.7 as well

----------
assignee: docs at python
components: Documentation
messages: 245734
nosy: docs at python, mattyw
priority: normal
severity: normal
status: open
title: test_decimal.py contains a dead link
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 24 16:26:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Jun 2015 14:26:30 +0000
Subject: [New-bugs-announce] [issue24498] Shoudl ptags and eptags be removed
	from repo?
Message-ID: <1435155990.35.0.688744790399.issue24498@psf.upfronthosting.co.za>


New submission from R. David Murray:

ctags directly supports python.  Is there any reason to keep the ptags and eptags scripts in Tools/scripts?

----------
messages: 245744
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Shoudl ptags and eptags be removed from repo?

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

From report at bugs.python.org  Wed Jun 24 17:59:31 2015
From: report at bugs.python.org (=?utf-8?b?WmFjaCDigJxUaGUgUXVhbnR1bSBNZWNoYW5pY+KAnSBX?=)
Date: Wed, 24 Jun 2015 15:59:31 +0000
Subject: [New-bugs-announce] [issue24499] Python Installer text piles up
 during installation process
Message-ID: <1435161571.8.0.161419365704.issue24499@psf.upfronthosting.co.za>


New submission from Zach ?The Quantum Mechanic? W:

A minor visual bug that causes text to "pile up" in the installer window. Installation finished, python seems to run fine.

Operating System: Windows 8.1 64x
Installer: Python 3.5.0b2

----------
components: Installation
files: python_installer_visual_error.png
messages: 245759
nosy: Zach ?The Quantum Mechanic? W
priority: normal
severity: normal
status: open
title: Python Installer text piles up during installation process
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39801/python_installer_visual_error.png

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

From report at bugs.python.org  Wed Jun 24 18:03:02 2015
From: report at bugs.python.org (Zahari Dim)
Date: Wed, 24 Jun 2015 16:03:02 +0000
Subject: [New-bugs-announce] [issue24500] xontextlib.redirect_stdout should
	redirect C output
Message-ID: <1435161782.93.0.989546707262.issue24500@psf.upfronthosting.co.za>


New submission from Zahari Dim:

It is common to have an inflexible C wrapper with lots of undesired output. However it is not so trivial to supress (or redirect) that output from Python in a selective way. contextlib.redirect_stdout doesn't help, since it only changes sys.sdout, without touching the actual file descriptor. The following worked for my use case, which I adapted from here http://eli.thegreenplace.net/2015/redirecting-all-kinds-of-stdout-in-python/:

import sys
import os
from contextlib import contextmanager, redirect_stdout

@contextmanager
def supress_stdout():
    devnull = open(os.devnull, 'wb')
    try:
        stdout_flieno = sys.stdout.fileno()
    except ValueError:
        redirect = False
    else:
        redirect = True
        sys.stdout.flush()
        #sys.stdout.close()
        devnull_fileno = devnull.fileno()
        saved_stdout_fd = os.dup(stdout_flieno)
        os.dup2(devnull_fileno, stdout_flieno)

    with redirect_stdout(devnull):
        yield
    if redirect:
        os.dup2(stdout_flieno, saved_stdout_fd)

----------
components: Extension Modules, Library (Lib)
messages: 245760
nosy: Zahari.Dim
priority: normal
severity: normal
status: open
title: xontextlib.redirect_stdout should redirect C output
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 24 18:19:02 2015
From: report at bugs.python.org (Pete Lancashire)
Date: Wed, 24 Jun 2015 16:19:02 +0000
Subject: [New-bugs-announce] [issue24501] configure does not find (n)curses
	in /usr/local/libs
Message-ID: <1435162742.72.0.811828390011.issue24501@psf.upfronthosting.co.za>


Changes by Pete Lancashire <pete at petelancashire.com>:


----------
components: Build
nosy: petepdx
priority: normal
severity: normal
status: open
title: configure does not find (n)curses in /usr/local/libs
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 24 21:12:01 2015
From: report at bugs.python.org (Jim Zajkowski)
Date: Wed, 24 Jun 2015 19:12:01 +0000
Subject: [New-bugs-announce] [issue24502] OS X 2.7 package has zeros for
 version numbers in sub-packages
Message-ID: <1435173121.58.0.153613185242.issue24502@psf.upfronthosting.co.za>


New submission from Jim Zajkowski:

The 2.7.0 download has zeros as version numbers on the .pkgs inside the metapackage, which leads to the package database showing an installed version of 0.

e.g.:

m-jamesez-darthpro:Downloads jamesez$ pkgutil --info org.python.Python.PythonApplications-2.7
package-id: org.python.Python.PythonApplications-2.7
version: 0
volume: /
location: Applications
install-time: 1435172997

This is from the Distribution file in your package:

    <pkg-ref id="org.python.Python.PythonFramework-2.7" version="0" auth="Root" onConclusion="none" installKBytes="49396">#Python_Framework.pkg</pkg-ref>
    <pkg-ref id="org.python.Python.PythonApplications-2.7" version="0" auth="Root" onConclusion="none" installKBytes="1859">#Python_Applications.pkg</pkg-ref>
    <pkg-ref id="org.python.Python.PythonUnixTools-2.7" version="0" auth="Root" onConclusion="none" installKBytes="14">#Python_Command_Line_Tools.pkg</pkg-ref>
    <pkg-ref id="org.python.Python.PythonDocumentation-2.7" version="0" auth="Root" onConclusion="none" installKBytes="31469">#Python_Documentation.pkg</pkg-ref>
    <pkg-ref id="org.python.Python.PythonProfileChanges-2.7" version="0" auth="Root" onConclusion="none" installKBytes="0">#Python_Shell_Profile_Updater.pkg</pkg-ref>
    <pkg-ref id="org.python.Python.PythonInstallPip-2.7" version="0" auth="Root" onConclusion="none" installKBytes="0">#Python_Install_Pip.pkg</pkg-ref>

----------
components: Installation, Macintosh
messages: 245769
nosy: Jim Zajkowski, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: OS X 2.7 package has zeros for version numbers in sub-packages
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 24 22:05:15 2015
From: report at bugs.python.org (Wolfgang E. Sanyer)
Date: Wed, 24 Jun 2015 20:05:15 +0000
Subject: [New-bugs-announce] [issue24503] csv.writer fails when within
	csv.reader
Message-ID: <1435176315.93.0.429947665214.issue24503@psf.upfronthosting.co.za>


New submission from Wolfgang E. Sanyer:

I have a use case where I am using a csv.reader to loop through one file and trying to use a csv.writer to output to another file. However, when I do this, the csv.writer instance does not write anything to the output file.

ex:

import csv

with open("input.csv", "rb") as input, open("output.csv", "wb") as output:
    reader = csv.reader(input)
    writer = csv.writer(output)

    for row in reader:
        writer.writerow("data") # this writes out nothing
    
    writer.writerow("more data") # this writes out something

----------
components: Library (Lib)
messages: 245772
nosy: ezzieyguywuf
priority: normal
severity: normal
status: open
title: csv.writer fails when within csv.reader
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 24 23:44:37 2015
From: report at bugs.python.org (Denis Gordeev)
Date: Wed, 24 Jun 2015 21:44:37 +0000
Subject: [New-bugs-announce] [issue24504] os.listdir() error if the last
 folder starts not with the capital letter
Message-ID: <1435182277.25.0.0494331055897.issue24504@psf.upfronthosting.co.za>


New submission from Denis Gordeev:

My code is:
mypath = 'Z:\Pr Files\norma'
file_list = [ f for f in listdir(mypath) if isfile(join(mypath,f))]

Error:
Traceback (most recent call last):
  File "C:\Documents and Settings\Administrator\Desktop\uni\click zhenilo workshop\noise.py", line 13, in <module>
    file_list = [ f for f in listdir(mypath) if isfile(join(mypath,f))]
WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: 'Z:\\Pr Files\norma/*.*'

It works all right, if the path is:
mypath = 'Z:\Pr Files\Norma'

----------
components: Windows
messages: 245777
nosy: Denis Gordeev, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.listdir() error if the last folder starts not with the capital letter
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 25 00:09:39 2015
From: report at bugs.python.org (Bob Alexander)
Date: Wed, 24 Jun 2015 22:09:39 +0000
Subject: [New-bugs-announce] [issue24505] shutil.which wrong result on
	Windows
Message-ID: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>


New submission from Bob Alexander:

Python session with 3.5b2

Showing existing error:
>>> from shutil import which

Works OK
>>> which("python")
'C:\\Python27\\python.EXE'

Also works OK
>>> which('C:\\Python27\\python.EXE')
'C:\\Python27\\python.EXE'

Fails
>>> which('C:\\Python27\\python')
>>>

Showing better results with my fix (attached):
>>> from which2 import which
>>> which("python")
'C:\\Python27\\python.exe'
>>> which('C:\\Python27\\python.exe')
'C:\\Python27\\python.exe'
>>> which('C:\\Python27\\python')
'C:\\Python27\\python.exe'

Problem is with the short-circuiting code near the beginning of the function. It fails to check the extensions for Windows when short-circuited.

My fix has a few other improvements -- efficiency and nicer output without those ugly upper-case extensions.

----------
components: Library (Lib)
files: which2.py
messages: 245780
nosy: bobjalex
priority: normal
severity: normal
status: open
title: shutil.which wrong result on Windows
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file39805/which2.py

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

From report at bugs.python.org  Thu Jun 25 00:13:04 2015
From: report at bugs.python.org (Karl Richter)
Date: Wed, 24 Jun 2015 22:13:04 +0000
Subject: [New-bugs-announce] [issue24506] make fails with gcc 4.9 due to
 fatal warning of unused variable and empty macro in Parser/pgen.c
Message-ID: <1435183984.12.0.342400171116.issue24506@psf.upfronthosting.co.za>


New submission from Karl Richter:

`gcc` 4.9 is more restictive and recognizes that the empty definition of the `REQN` macro doesn't use some variables. It's more suitable to wrap the usage of the macro in the same preprocessor conditionals like the macro definition.

experienced with 41fbc222af8c503e1659250a36f4e293d864a92b

Patch attached. Tests pass (see https://semaphoreci.com/krichter/cpython/branches/empty_macro/builds/1 for details).

----------
components: Build
files: 0001-removed-empty-definition-of-REQN-preprocessor-macro-.patch
keywords: patch
messages: 245781
nosy: krichter
priority: normal
severity: normal
status: open
title: make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c
versions: Python 2.7
Added file: http://bugs.python.org/file39806/0001-removed-empty-definition-of-REQN-preprocessor-macro-.patch

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

From report at bugs.python.org  Thu Jun 25 05:26:22 2015
From: report at bugs.python.org (Rusi)
Date: Thu, 25 Jun 2015 03:26:22 +0000
Subject: [New-bugs-announce] [issue24507] CRLF issues
Message-ID: <1435202782.41.0.930107926701.issue24507@psf.upfronthosting.co.za>


New submission from Rusi:

While trying to freshly setup a CPython repo, encountered the following
CRLF issues:

Mixed file -- both LF and CRLF (line 29 LF rest CRLF)
Lib/venv/scripts/nt/Activate.ps1

Lib/test/decimaltestdata is a directory with mixed up files -- ie some CRLF some LF files

PCbuild/readme.txt: CRLF (explicit)
This is fine. Many of the following should (ideally/IMHO) be likewise CRLF (not BIN)

*.sln: CRLF but marked as BIN in hgeol

PC/example_nt/example.vcproj
Emacs shows as Dos file; But not picked up by file; maybe other such

Missing BIN pattern from .hgeol
*.pdf
Note that Doc/library/turtle-star.pdf exists
This is most likely a bug

Existent file-types with non-existent files in hgeol; Probably harmless
*.vsprops
*.mk
*.dsp
*.dsw

These seem straightforward CRLF files to me; why BIN in hgeol?
Lib/test/test_email/data/msg_26.txt
Lib/test/coding20731.py

----------
components: Build
messages: 245793
nosy: RusiMody, zach.ware
priority: normal
severity: normal
status: open
title: CRLF issues
versions: Python 3.5

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

From report at bugs.python.org  Thu Jun 25 06:26:48 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 25 Jun 2015 04:26:48 +0000
Subject: [New-bugs-announce] [issue24508] Backport 3.5's Windows build
	project files to 2.7
Message-ID: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's the (enormous) patch backporting 3.5's project files to 2.7.  It also takes care of adjusting the old project files to their new home in PC/VS9.0, and makes a couple of small adjustments in distutils.command.build_ext, FixTk, regrtest, and the Tcl/Tk tests to keep the test suite running properly.  I've run a couple of builds on the custom buildbots, and at this point there are no failures that I can see any reason to blame this patch for.

I would greatly appreciate some review, or at least 'review by testing' to make sure this doesn't completely break anybody's workflow.

Terry, I'm particularly interested in your feedback since I'm pretty sure you generally build from the VS GUI, which I usually avoid doing.  PCbuild\pcbuild.sln *will not* work with the VS 2008 GUI, but it should work with any other VS, 2010 or newer.  If you'd prefer to continue using the 2008 GUI, PC\VS9.0\pcbuild.sln should continue to work.  When using the new project files, though, this should also take care of the headache of making Tcl/Tk play the game; you shouldn't have to do anything extra to be able to use Tkinter.

Steve, I did not make any changes to Tools\msi, but I'd be happy to if it makes your job any easier.

Looking forward to your feedback,
Zach

----------
assignee: zach.ware
components: Build, Windows
files: 2.7_project_files_backport.diff
keywords: patch
messages: 245795
nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Backport 3.5's Windows build project files to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file39811/2.7_project_files_backport.diff

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

From report at bugs.python.org  Thu Jun 25 09:37:50 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 25 Jun 2015 07:37:50 +0000
Subject: [New-bugs-announce] [issue24509] Undocumented features of asyncio:
	call_at, call_later
Message-ID: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za>


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

These function returns handle, so, registered callback can be cancelled.

----------
messages: 245803
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Undocumented features of asyncio: call_at, call_later
versions: Python 3.6

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

From report at bugs.python.org  Thu Jun 25 17:35:58 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jun 2015 15:35:58 +0000
Subject: [New-bugs-announce] [issue24510] Make _PyCoro_GetAwaitableIter a
	public API
Message-ID: <1435246558.17.0.296607565259.issue24510@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

We should consider making _PyCoro_GetAwaitableIter(o) a public API.

Its implementation isn't trivial because it's not around simply accessing 'tp_as_async->am_await'.  You also need to check is 'o' is a generator with a CO_ITERABLE_COROUTINE or a CoroObject, etc.

----------
assignee: yselivanov
components: Interpreter Core
messages: 245812
nosy: gvanrossum, haypo, ncoghlan, scoder, yselivanov
priority: normal
severity: normal
status: open
title: Make _PyCoro_GetAwaitableIter a public API
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jun 25 17:42:28 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jun 2015 15:42:28 +0000
Subject: [New-bugs-announce] [issue24511] Add methods for async protocols
Message-ID: <1435246948.22.0.255546128718.issue24511@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Let's consider adding C API functions for working with new tp_as_async:

PyAwait_Check for checking tp_as_async->am_await || PyCoro_Check || PyGen & CO_ITERABLE_COROUTINE

PyAwait_AsyncIterCheck for checking tp_as_async->am_iter
PyAwait_GetAsyncIter for calling tp_as_async->am_iter
PyAwait_AsyncIterNext for calling tp_as_async->am_next

Please also see issue24510 for opening up _PyCoro_GetAwaitableIter; we can call it PyAwait_Get

----------
assignee: yselivanov
components: Interpreter Core
messages: 245814
nosy: gvanrossum, haypo, ncoghlan, scoder, yselivanov
priority: normal
severity: normal
status: open
title: Add methods for async protocols
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jun 25 20:19:54 2015
From: report at bugs.python.org (Timothy Cardenas)
Date: Thu, 25 Jun 2015 18:19:54 +0000
Subject: [New-bugs-announce] [issue24512] multiprocessing should log a
 warning when forking multithreaded process
Message-ID: <1435256394.21.0.131332757316.issue24512@psf.upfronthosting.co.za>


New submission from Timothy Cardenas:

We were tracking down a bug the other day that was rather hard to find involving a forking a process that had both a primary thread and a logging thread. The docs clearly state that forking a multithreaded process is "problematic" https://docs.python.org/3.4/library/multiprocessing.html#contexts-and-start-methods

However given that it is very simple to check if the process currently has multiple threads at the time of the forking operation and that its almost never safe to do so with multiple running threads I was wondering if it made sense to add a message that warned that a unsafe operation (forking a multithreaded process without the forkserver option) was occurring.

----------
components: Library (Lib)
messages: 245825
nosy: trcarden
priority: normal
severity: normal
status: open
title: multiprocessing should log a warning when forking multithreaded process
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jun 26 06:04:12 2015
From: report at bugs.python.org (Rusi)
Date: Fri, 26 Jun 2015 04:04:12 +0000
Subject: [New-bugs-announce] [issue24513] decimal test version mismatch
Message-ID: <1435291452.99.0.632352537758.issue24513@psf.upfronthosting.co.za>


New submission from Rusi:

In http://bugs.python.org/issue24507
there was an apprehension about changing the decimal test versions.

Poking around I find that the versions in headers of files in
Lib/test/decimaltestdata refer to version 2.59 and the IBM link
http://www2.hursley.ibm.com/decimal which is dead

Whereas help(decimal) points to
http://speleotrove.com/decimal/decarith.html -- version 1.70 

http://speleotrove.com/decimal/ contains dectest.zip which is
at version 2.62

----------
messages: 245835
nosy: RusiMody, eric.smith, zach.ware
priority: normal
severity: normal
status: open
title: decimal test version mismatch
versions: Python 3.5

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

From report at bugs.python.org  Fri Jun 26 11:18:57 2015
From: report at bugs.python.org (Philippe)
Date: Fri, 26 Jun 2015 09:18:57 +0000
Subject: [New-bugs-announce] [issue24514] tarfile fails to extract archive
 (handled fine by gnu tar and bsdtar)
Message-ID: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za>


New submission from Philippe:

The extraction fails when calling tarfile.open using this archive: http://archive.apache.org/dist/commons/logging/source/commons-logging-1.1.2-src.tar.gz

After some investigation, the file can be extracted with gnu tar and bsdtar and the gzip compression is not the issue: if I gunzip the tar.gz to a tar and call tarfile on plain tar, the problem is the same.

Also this archive was created most likely on Windows (based on the `file` command output) using some Java tools per http://commons.apache.org/proper/commons-logging/building.html from these original files: http://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2/ ... that's all I could find out.


The error trace is slightly different on 2.7 and 3.4 but similar. 
The problem has been verified on Linux 64 with Python 2.7 and 3.4 and on Windows with Python 2.7.

On 2.7:

>>> TarFile.taropen(name)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/tarfile.py", line 1705, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python2.7/tarfile.py", line 1574, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python2.7/tarfile.py", line 2335, in next
    raise ReadError(str(e))
tarfile.ReadError: invalid header


On 3.4:

>>> TarFile.taropen(name)
Traceback (most recent call last):
  File "/usr/lib/python3.4/tarfile.py", line 180, in nti
    n = int(nts(s, "ascii", "strict") or "0", 8)
ValueError: invalid literal for int() with base 8: '       '

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/tarfile.py", line 2248, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.4/tarfile.py", line 1083, in fromtarfile
    obj = cls.frombuf(buf, tarfile.encoding, tarfile.errors)
  File "/usr/lib/python3.4/tarfile.py", line 1032, in frombuf
    obj.uid = nti(buf[108:116])
  File "/usr/lib/python3.4/tarfile.py", line 182, in nti
    raise InvalidHeaderError("invalid header")
tarfile.InvalidHeaderError: invalid header

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/tarfile.py", line 1595, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.4/tarfile.py", line 1469, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python3.4/tarfile.py", line 2260, in next
    raise ReadError(str(e))
tarfile.ReadError: invalid header

----------
components: Library (Lib)
files: commons-logging-1.1.2-src.tar.gz
messages: 245839
nosy: lars.gustaebel, pombreda
priority: normal
severity: normal
status: open
title: tarfile fails to extract archive (handled fine by gnu tar and bsdtar)
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file39814/commons-logging-1.1.2-src.tar.gz

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

From report at bugs.python.org  Fri Jun 26 11:49:10 2015
From: report at bugs.python.org (Luc Saffre)
Date: Fri, 26 Jun 2015 09:49:10 +0000
Subject: [New-bugs-announce] [issue24515] docstring of isinstance
Message-ID: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za>


New submission from Luc Saffre:

The docstring of built-in function 'isinstance' should explain that if the classinfo is a tuple, the object must be instance of *any* (not *all*) of the class objects.

----------
assignee: docs at python
components: Documentation
messages: 245841
nosy: Luc Saffre, docs at python
priority: normal
severity: normal
status: open
title: docstring of isinstance
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 26 15:05:40 2015
From: report at bugs.python.org (Petr Messner)
Date: Fri, 26 Jun 2015 13:05:40 +0000
Subject: [New-bugs-announce] [issue24516] SSL create_default_socket purpose
 insufficiently documented
Message-ID: <1435323940.35.0.0347196481189.issue24516@psf.upfronthosting.co.za>


New submission from Petr Messner:

Please, is it possible to put more information about the purpose parameter to the documentation of ssl.create_default_context()? It's not obvious that SERVER_AUTH should be used for client sockets and not server sockets. It took me a while to discover this, while all I was getting was only "SSLEOFError: EOF occurred in violation of protocol" (which is also not helpful).

This is especially confusing, because OpenSSL uses serverAuth and clientAuth (for extendedKeyUsage configuration) in the exactly opposite meaning.

----------
assignee: docs at python
components: Documentation
messages: 245852
nosy: docs at python, messa
priority: normal
severity: normal
status: open
title: SSL create_default_socket purpose insufficiently documented
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun 26 21:13:45 2015
From: report at bugs.python.org (dendory)
Date: Fri, 26 Jun 2015 19:13:45 +0000
Subject: [New-bugs-announce] [issue24517] %z does not work in time.strftime()
Message-ID: <1435346025.05.0.415032825862.issue24517@psf.upfronthosting.co.za>


New submission from dendory:

Using `%z` gives the same result as using `%Z` in `time.strftime()`:

    Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import time
    >>> time.strftime("%z")
    'Eastern Daylight Time'
    >>> time.strftime("%Z")
    'Eastern Daylight Time'

Instead it's supposed to give a +0000 or -0000 result.

----------
messages: 245860
nosy: dendory
priority: normal
severity: normal
status: open
title: %z does not work in time.strftime()
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 27 00:59:43 2015
From: report at bugs.python.org (Catherine Devlin)
Date: Fri, 26 Jun 2015 22:59:43 +0000
Subject: [New-bugs-announce] [issue24518] json.dumps should accept key
	function for ``sort_keys``
Message-ID: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za>


New submission from Catherine Devlin:

Right now, json.dumps can be called with True or False, but it would be easy to also support accepting a key function, which then could be used to control the order of keys arbitrarily in the serialized JSON output.

----------
components: Library (Lib)
messages: 245874
nosy: catherinedevlin
priority: normal
severity: normal
status: open
title: json.dumps should accept key function for ``sort_keys``
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 27 11:22:06 2015
From: report at bugs.python.org (Zahari Dim)
Date: Sat, 27 Jun 2015 09:22:06 +0000
Subject: [New-bugs-announce] [issue24519] multiprocessing.Pool with
 maxtasksperchild starts too many processes
Message-ID: <1435396926.55.0.634788943007.issue24519@psf.upfronthosting.co.za>


New submission from Zahari Dim:

The following example should start two processes, but instead it starts three, even though only two do_work(). A third process is incorrectly started after the first one finishes.

import os
import time
from multiprocessing import Pool

def initprocess():
    print("Starting PID: %d" % os.getpid())

def do_work(x):
    print("Doing work in %d" % os.getpid())
    time.sleep(x**2)

if __name__ == '__main__':
    p = Pool(2, initializer=initprocess,maxtasksperchild=1)
    results = p.map(do_work, (1,2), chunksize=1)

----------
components: Library (Lib)
messages: 245878
nosy: Zahari.Dim
priority: normal
severity: normal
status: open
title: multiprocessing.Pool with maxtasksperchild starts too many processes
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 27 17:08:23 2015
From: report at bugs.python.org (Andrew Turner)
Date: Sat, 27 Jun 2015 15:08:23 +0000
Subject: [New-bugs-announce] [issue24520] Stop using deprecated
 floating-point environment functions on FreeBSD
Message-ID: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>


New submission from Andrew Turner:

The attached patch moves to use the fenv functions on FreeBSD to control the floating-point environment. This will be needed as I don't expect FreeBSD will have these functions on arm64.

I would expect a similar change should be applied to any supported development branch.

----------
components: Interpreter Core
files: use_fenv_freebsd.diff
keywords: patch
messages: 245879
nosy: Andrew Turner
priority: normal
severity: normal
status: open
title: Stop using deprecated floating-point environment functions on FreeBSD
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file39822/use_fenv_freebsd.diff

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

From report at bugs.python.org  Sat Jun 27 21:24:48 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Jun 2015 19:24:48 +0000
Subject: [New-bugs-announce] [issue24521] Integer overflow in _pickle.c
Message-ID: <1435433088.12.0.599666977394.issue24521@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Reported by Kurucsai Istvan on the security list:

I. Summary

There is an integer overflow in the _Unpickler_ResizeMemoList function in _pickle.c. It is reachable e.g. via the LONG_BINPUT opcode.


II. Source code

The functions in question:
static int
load_long_binput(UnpicklerObject *self)
{
    PyObject *value;
    Py_ssize_t idx;
    char *s;

    if (_Unpickler_Read(self, &s, 4) < 0)
        return -1;
    <<SNIP>>
    idx = calc_binsize(s, 4);
1.  if (idx < 0) {
        PyErr_SetString(PyExc_ValueError,
                        "negative LONG_BINPUT argument");
        return -1;
    }
    
    return _Unpickler_MemoPut(self, idx, value);
}

static int
_Unpickler_MemoPut(UnpicklerObject *self, Py_ssize_t idx, PyObject *value)
{
    PyObject *old_item;

    if (idx >= self->memo_size) {
2.      if (_Unpickler_ResizeMemoList(self, idx * 2) < 0)
            return -1;
        assert(idx < self->memo_size);
    }
    <<SNIP>>
}

static int
_Unpickler_ResizeMemoList(UnpicklerObject *self, Py_ssize_t new_size)
{
    <<SNIP>>
3.  memo = PyMem_REALLOC(self->memo, new_size * sizeof(PyObject *));
    if (memo == NULL) {
        PyErr_NoMemory();
        return -1;
    }
    self->memo = memo;
4.  for (i = self->memo_size; i < new_size; i++)
        self->memo[i] = NULL;
    self->memo_size = new_size;
    return 0;
}

1. 0 < idx < PY_SSIZE_T_MAX, we choose idx = 0x20000000
2. and 3. together multiply idx by 8 on a 32 bit arch, 0x20000000 * 8 wraps to 0.
4. buffer overflow


III. Proof of concept

The bug can be triggered using the following pickle:
d:\Python34\python.exe -m pickletools G:\dump\python\memo1
    0: I    INT        1
    3: r    LONG_BINPUT 536870912
    8: .    STOP
highest protocol among opcodes = 1

Running the following causes the crash below (also tested on 3.5.0b2).
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> pickle.loads(b'I1\nr\x00\x00\x00\x20\x2e')

(1600.2664): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0000d3c4 ebx=1d84d1d0 ecx=778c28ac edx=01e700f0 esi=001f8a48 edi=40000000
eip=1d5ce5d3 esp=0057f65c ebp=0057f668 iopl=0         nv up ei ng nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010283
python34!_Unpickler_ResizeMemoList+0x33:
1d5ce5d3 c7048200000000  mov     dword ptr [edx+eax*4],0 ds:002b:01ea5000=????????
0:000> kb
ChildEBP RetAddr  Args to Child              
0057f658 1d5ce627 00301ff4 00000004 0057f684 python34!_Unpickler_ResizeMemoList+0x33 [c:\users\martin\34\python\modules\_pickle.c @ 1275]
0057f668 1d5d3503 20000000 00301ff3 001f8a48 python34!_Unpickler_MemoPut+0x17 [c:\users\martin\34\python\modules\_pickle.c @ 1298]
0057f684 1d5d4027 001f8a48 0059b440 001f8a48 python34!load_long_binput+0x73 [c:\users\martin\34\python\modules\_pickle.c @ 5653]
0057f6a0 1d5d4e44 0059b440 00000000 0057f6dc python34!load+0x2c7 [c:\users\martin\34\python\modules\_pickle.c @ 6134]
0057f6b0 1d5d5461 00301fe0 00000001 1d6ff9d0 python34!_pickle_loads_impl+0x54 [c:\users\martin\34\python\modules\_pickle.c @ 7060]
0057f6dc 1d674f15 00597780 002cf6b0 00000000 python34!_pickle_loads+0x61 [c:\users\martin\34\python\modules\clinic\_pickle.c.h @ 540]
0057f6fc 1d6c591f 0059b440 002cf6b0 00000000 python34!PyCFunction_Call+0x65 [c:\users\martin\34\python\objects\methodobject.c @ 99]
0057f72c 1d6c79d9 0057f760 00000000 002d1d40 python34!call_function+0x28f [c:\users\martin\34\python\python\ceval.c @ 4237]
0057f7a0 1d6c89fd 002ff7b0 00000000 01e55958 python34!PyEval_EvalFrameEx+0x1ff9 [c:\users\martin\34\python\python\ceval.c @ 2840]
0057f7dc 1d6c8b64 002d1d40 002ff7b0 002960f8 python34!PyEval_EvalCodeEx+0x55d [c:\users\martin\34\python\python\ceval.c @ 3588]
0057f810 1d6f1f7d 002d1d40 002960f8 002960f8 python34!PyEval_EvalCode+0x24 [c:\users\martin\34\python\python\ceval.c @ 780]
0057f82c 1d6f39fd 01e5e098 002960f8 002960f8 python34!run_mod+0x2d [c:\users\martin\34\python\python\pythonrun.c @ 2180]
0057f868 1d6f4520 703c3008 0030a728 0057f8f4 python34!PyRun_InteractiveOneObject+0x25d [c:\users\martin\34\python\python\pythonrun.c @ 1446]
0057f88c 1d6f459d 703c3008 1d706acc 0057f8f4 python34!PyRun_InteractiveLoopFlags+0xc0 [c:\users\martin\34\python\python\pythonrun.c @ 1324]
0057f8a8 1d5fdc75 703c3008 1d706acc 00000000 python34!PyRun_AnyFileExFlags+0x2d [c:\users\martin\34\python\python\pythonrun.c @ 1286]
0057f8c8 1d5fe336 703c3008 0057f8f4 1cd73378 python34!run_file+0x95 [c:\users\martin\34\python\modules\main.c @ 319]
0057f940 1cd71184 00000001 01fd1420 01fd5be8 python34!Py_Main+0x696 [c:\users\martin\34\python\modules\main.c @ 751]
0057f984 7621337a 7efde000 0057f9d0 778b92e2 python!__tmainCRTStartup+0x122 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 552]
0057f990 778b92e2 7efde000 2345c114 00000000 kernel32!BaseThreadInitThunk+0xe
0057f9d0 778b92b5 1cd712ec 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0057f9e8 00000000 1cd712ec 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b

----------
components: Extension Modules
messages: 245888
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Integer overflow in _pickle.c
type: crash
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jun 27 22:00:12 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Jun 2015 20:00:12 +0000
Subject: [New-bugs-announce] [issue24522] Integer overflow in
 _json_encode_unicode leads to crash (heap-buffer-overflow)
Message-ID: <1435435212.2.0.881179193959.issue24522@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Reported by Brendon Tiszka on the security list:

# static PyObject *
# escape_unicode(PyObject *pystr)
# {
#     /* Take a PyUnicode pystr and return a new escaped PyUnicode */
#     Py_ssize_t i;
#     Py_ssize_t input_chars;
#     Py_ssize_t output_size;
#     Py_ssize_t chars;
#     PyObject *rval;
#     void *input;
#     int kind;
#     Py_UCS4 maxchar;
# 
#     if (PyUnicode_READY(pystr) == -1)
#         return NULL;
# 
#     maxchar = PyUnicode_MAX_CHAR_VALUE(pystr);
#     input_chars = PyUnicode_GET_LENGTH(pystr);
#     input = PyUnicode_DATA(pystr);
#     kind = PyUnicode_KIND(pystr);
# 
#     /* Compute the output size */
#     for (i = 0, output_size = 2; i < input_chars; i++) {
#         Py_UCS4 c = PyUnicode_READ(kind, input, i);
#         switch (c) {
#         case '\\': case '"': case '\b': case '\f':
#         case '\n': case '\r': case '\t':
#             output_size += 2;
#             break;
#         default:
#             if (c <= 0x1f)
#                 output_size += 6;
#             else
#                 output_size++;
#         }
#     }
#
#     rval = PyUnicode_New(output_size, maxchar);
#
# 1.) if c is <= 0x1f then output_size += 6. There are no overflow checks on this variable.
# 2.) rval buffer is too small to hold results
#
# Crash:
# ------
#
# Program received signal SIGSEGV, Segmentation fault.
# 0xb7a2e9be in escape_unicode (pystr=pystr at entry=0x8cf81018)
#     at /home/pail/cpython/Modules/_json.c:306
# 306	       ENCODE_OUTPUT;
#
# OS info
# --------
#  %./python -V
#  > Python 3.6.0a0
# % uname -a
# Linux Pail0verflow 3.13.0-52-generic #85-Ubuntu SMP Wed Apr 29 16:44:56 UTC 2015 i686 i686 i686 GNU/Linux
#
# ASAN Info (details in other file)
# =================================================================
# ==6512== ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb5c00000 at pc 0xb5f17356 bp 0xbfaa0eb8 sp 0xbfaa0eac
# WRITE of size 1 at 0xb5c00000 thread T0

import json

sp = "\x13"*715827883 #((2**32)/6 + 1)
json.dumps([sp], ensure_ascii=False)

----------
components: Extension Modules
messages: 245891
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Integer overflow in _json_encode_unicode leads to crash (heap-buffer-overflow)
type: security
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Jun 28 08:30:54 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 28 Jun 2015 06:30:54 +0000
Subject: [New-bugs-announce] [issue24523] coroutine asyncio.wait() does not
 preserve order of elements
Message-ID: <1435473054.25.0.727716281024.issue24523@psf.upfronthosting.co.za>


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

If I pass an list of futures/coroutines as (done, _) = asyncio.wait([...]), order of elements in `done` does NOT match order of elements in `wait`'s argument. This is not documented, and I don't know if that is a bug or not.

Also, documentation say:

Wait for the Futures and coroutine objects given by the SEQUENCE futures to complete.

Really, this should be SET, since order is not preserved. Or, sources should be patched to preserve the order. I think, it is not hard to preserve order [in asyncio code].


P.S.

For example, in Tornado, it is guaranteed (and documented) that order is preserved, so I can write

[res1, res2] = yield [fut1(), fut2()]

and it is guaranteed, that res1 - is a result of fut1()

----------
components: asyncio
messages: 245899
nosy: gvanrossum, haypo, mmarkk, yselivanov
priority: normal
severity: normal
status: open
title: coroutine asyncio.wait() does not preserve order of elements
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 29 00:01:27 2015
From: report at bugs.python.org (Tomas Nordin)
Date: Sun, 28 Jun 2015 22:01:27 +0000
Subject: [New-bugs-announce] [issue24524] python crash using Tkinter
Message-ID: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za>


New submission from Tomas Nordin:

$ python
Python 2.7.9 (default, Mar  1 2015, 18:22:53) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
The readline tab completion thing should be loaded. (pythonstartup.py @home)
>>> import Tkinter as tk
>>> import tkFileDialog as tfd
>>> tk.Tk()
<Tkinter.Tk instance at 0xb72206ec>
>>> tk.Tk()
<Tkinter.Tk instance at 0xb7117a8c>
>>> tfd.askopenfilename()
u'/home/tomas/.emacs'
>>> # closing the root window
... 
>>> alloc: invalid block: 0x99ddcd8: 88 9
Aborted
$

$ uname -a
Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u1 i686 GNU/Linux

See also #22810

----------
components: Tkinter
messages: 245917
nosy: tomnor
priority: normal
severity: normal
status: open
title: python crash using Tkinter
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 29 10:48:31 2015
From: report at bugs.python.org (Vincent Legoll)
Date: Mon, 29 Jun 2015 08:48:31 +0000
Subject: [New-bugs-announce] [issue24525] [doc] missing word
Message-ID: <1435567711.2.0.215374180363.issue24525@psf.upfronthosting.co.za>


New submission from Vincent Legoll:

Here is a patch to fix a missing word in the urllib doc

----------
assignee: docs at python
components: Documentation
files: python-doc-fix.hgpatch
messages: 245927
nosy: docs at python, vincent-legoll
priority: normal
severity: normal
status: open
title: [doc] missing word
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file39828/python-doc-fix.hgpatch

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

From report at bugs.python.org  Mon Jun 29 12:19:03 2015
From: report at bugs.python.org (bhaskar)
Date: Mon, 29 Jun 2015 10:19:03 +0000
Subject: [New-bugs-announce] [issue24526] Exponent function bug
Message-ID: <1435573143.55.0.102498891735.issue24526@psf.upfronthosting.co.za>


New submission from bhaskar:

the value of a -ve number when raised by a power of even number always results in a +ve number. I tried it with -1**10 , -1**2, -9**4

these all are resulting in -ve numbers which is mathematically incorrect.

ps. the same example is in the attachment

----------
components: IDLE
files: pythonabc.png
messages: 245928
nosy: bhaskar
priority: normal
severity: normal
status: open
title: Exponent function bug
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file39829/pythonabc.png

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

From report at bugs.python.org  Mon Jun 29 13:11:47 2015
From: report at bugs.python.org (Sebastian Noack)
Date: Mon, 29 Jun 2015 11:11:47 +0000
Subject: [New-bugs-announce] [issue24527] The MimeTypes class cannot ignore
 global files per instance
Message-ID: <1435576307.84.0.535097012645.issue24527@psf.upfronthosting.co.za>


New submission from Sebastian Noack:

In order to prevent the mimetypes module from considering global files and registry entries, you have to call mimetypes.init([]). However, this will enforce that behavior globally, and only works if the module wasn't initialized yet.

There is also a similar argument in the mimetypes.MimeTypes() constructor, however the list of files passed there are considered additionally. But there is no way to prevent an individual MinmeTypes instance to consider global files.

Adding a "ignore_global_types" option would be trivial too add to the MimeTypes constructor, and would be extremely useful.

----------
components: Library (Lib)
messages: 245930
nosy: Sebastian Noack
priority: normal
severity: normal
status: open
title: The MimeTypes class cannot ignore global files per instance
type: behavior

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

From report at bugs.python.org  Mon Jun 29 13:28:43 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jun 2015 11:28:43 +0000
Subject: [New-bugs-announce] [issue24528] Misleading exeption for await in
	comprehensions.
Message-ID: <1435577323.48.0.769775989737.issue24528@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

The following code:

async def foo():
    lst = [await coro(i) for i in range(10)]
    return lst

gives

SyntaxError: 'await' outside async function

I understand that this is because the comprehensions are implemented using a function scope (see also #10544), but such behavior is unintuitive.

IMO there are two possibilities here:
1) make comprehensions behave more like a for loop;
2) change the exception text to something like "SyntaxError: 'await's in comprehensions are not supported".

I understand that the first option is probably not for 3.5 (it is beta already), but I will be happy if the second option will be implemented in 3.5

----------
components: Interpreter Core, asyncio
messages: 245931
nosy: gvanrossum, haypo, levkivskyi, yselivanov
priority: normal
severity: normal
status: open
title: Misleading exeption for await in comprehensions.
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun 29 16:42:55 2015
From: report at bugs.python.org (SylvainDe)
Date: Mon, 29 Jun 2015 14:42:55 +0000
Subject: [New-bugs-announce] [issue24529] Same MemoryError object gets
 thrown from different places.
Message-ID: <1435588975.99.0.915406015973.issue24529@psf.upfronthosting.co.za>


New submission from SylvainDe:

Disclaimer: This is very minor, impacts only Python 2 and is maybe not even a bug.

Context: I was "randomly" changing attribute of Exception objects when I discovered something I did not expect : sometimes when an exception occurs, a new object is raised (which is what I expected), sometimes a previously thrown exception is re-thrown (which surprised me).

More specifically, MemoryError objects seem to be reused while most of the other exceptions I've played with where newly created.

One can easily see this happening in the following piece of code :
 - first a NameError is caught and updated
 - then, we run the same code and print the re-caught exception : it is a new one
 - then, a MemoryError is caught and updated
 - then, we run the same code and print the re-caught exception : it is the same as previously.


<pre>
from __future__ import print_function

old_e = None
try:
    foobar
except NameError as old_e:
    print("old_e:", old_e)
    old_e.args = tuple(['NEW VALUE'])
    print("old_e:", old_e)
try:
    foobar
except NameError as new_e:
    print("new_e:", new_e)
    print(old_e is new_e)

old_e = None
try:
    l = [0] * 999999999999999999
except MemoryError as old_e:
    print("old_e:", old_e)
    old_e.args = tuple(['NEW VALUE'])
    print("old_e:", old_e)
try:
    l = [0] * 999999999999999999
except MemoryError as new_e:
    print("new_e:", new_e)
    print(old_e is new_e)
</pre>



For the record, I am quite aware that this shouldn't impact anyone using Python normally. I was just messing around as part of a toy project where I try to enhance exception messages for a better user experience (  https://github.com/SylvainDe/DidYouMean-Python ).

----------
components: Interpreter Core
messages: 245940
nosy: SylvainDe
priority: normal
severity: normal
status: open
title: Same MemoryError object gets thrown from different places.
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 29 16:49:34 2015
From: report at bugs.python.org (Dustin J. Mitchell)
Date: Mon, 29 Jun 2015 14:49:34 +0000
Subject: [New-bugs-announce] [issue24530] `import..as` fails where `import`
	does not
Message-ID: <1435589374.69.0.0263102389919.issue24530@psf.upfronthosting.co.za>


New submission from Dustin J. Mitchell:

Reproduction:

# main.py
import foo.bar

# foo/__init__.py
# (empty)

# foo/bar/__init__.py
import foo.bar.bing as bing

# foo/bar/bing.py
# (empty)

Result:

dustin at euclid ~/tmp $ python3.3 main.py 
Traceback (most recent call last):
  File "main.py", line 1, in <module>
    import foo.bar
  File "/home/dustin/tmp/foo/bar/__init__.py", line 1, in <module>
    import foo.bar.bing as bing
AttributeError: 'module' object has no attribute 'bar'

dustin at euclid ~/tmp $ python2.7 main.py 
Traceback (most recent call last):
  File "main.py", line 1, in <module>
    import foo.bar
  File "/home/dustin/tmp/foo/bar/__init__.py", line 1, in <module>
    import foo.bar.bing as bing
AttributeError: 'module' object has no attribute 'bar'

If you remove the `as bing` from `foo/bar/__init__.py`, all is well.  Similarly, `from foo.bar import bing` works fine, as does `from foo.bar import bing as bing`.

I don't see anything in https://docs.python.org/3/reference/simple_stmts.html#import that suggests this is expected behavior.

----------
components: Interpreter Core
messages: 245941
nosy: djmitche
priority: normal
severity: normal
status: open
title: `import..as` fails where `import` does not
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Jun 29 17:42:25 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 29 Jun 2015 15:42:25 +0000
Subject: [New-bugs-announce] [issue24531] please document that no code
 preceding encoding declaration is allowed
Message-ID: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

If the encoding is declared on the second line, the first line must not contain anything except comments. However, this fact is not documented.

The Python Language reference says only that "the encoding declaration must appear on a line of its own";
and PEP 263 says only that "there must not be any Python statement on the line that contains the encoding declaration".

For example, Python ignores this encoding declaration:

spam = True
# encoding=ISO-8859-2

despite the fact that it appears on a line of its own.

----------
assignee: docs at python
components: Documentation
messages: 245946
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: please document that no code preceding encoding declaration is allowed

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

From report at bugs.python.org  Mon Jun 29 19:25:51 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 29 Jun 2015 17:25:51 +0000
Subject: [New-bugs-announce] [issue24532] asyncio.sock_recv() blocks normal
	ioloop actions.
Message-ID: <1435598751.58.0.199860778997.issue24532@psf.upfronthosting.co.za>


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

Suppose that program:

====================================
import asyncio
import socket
def receiver(loop):
    (a, b) = socket.socketpair()
    loop.call_later(1, lambda: print('Should be called inside the loop'))
    end = loop.time() + 3
    print('Starting busy receiver')
    while loop.time() < end:
        a.send(b'test')
        yield from loop.sock_recv(b, 65536)
        # yield from asyncio.sleep(0) # <=====================
    print('Busy receiver complete')
    # just not to stop ioloop immediatelly
    yield from asyncio.sleep(0.5)
def main():
    loop = asyncio.get_event_loop()
    loop.run_until_complete(receiver(loop))
    loop.close()
if __name__ == '__main__':
    main()
====================================

Without asyncio.sleep(0) it will not fire time-delayed calls! If I add asyncio.sleep(0), everything work right. As I think, It is because recv() syscall is always succeeded, and we never return to ioloop (to epoll() I mean).

In other words, it is classical `reader starvation` as mentioned in "man epoll".

It is not documented, that this function may block event loop, in spite of it returns coroutine! I thought that this function will setup EPOLLIN event for socket's FD + call recv() after that. I spent many time to debug program.

----------
components: asyncio
messages: 245952
nosy: gvanrossum, haypo, mmarkk, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.sock_recv() blocks normal ioloop actions.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 29 20:34:47 2015
From: report at bugs.python.org (Charles Nodell)
Date: Mon, 29 Jun 2015 18:34:47 +0000
Subject: [New-bugs-announce] [issue24533] Increased Test Coverage for
	Lib/random.py
Message-ID: <1435602887.43.0.963223854079.issue24533@psf.upfronthosting.co.za>


New submission from Charles Nodell:

This patch just extends test coverage on the random library by a few lines.

----------
components: Tests
files: mywork.patch
keywords: patch
messages: 245956
nosy: Charles Nodell
priority: normal
severity: normal
status: open
title: Increased Test Coverage for Lib/random.py
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file39835/mywork.patch

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

From report at bugs.python.org  Mon Jun 29 21:30:39 2015
From: report at bugs.python.org (Min RK)
Date: Mon, 29 Jun 2015 19:30:39 +0000
Subject: [New-bugs-announce] [issue24534] disable executing code in .pth
	files
Message-ID: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za>


New submission from Min RK:

.pth files currently allow execution of arbitrary code, triggered by lines starting with `import`. This is a rarely understood, and often misbehaving feature. easy_install has used this feature to ensure that its packages are highest priority (even higher than stdlib). This is one of the unfortunate behaviors that pip undoes from easy_install, in part due to the problems it can cause. There is currently a proposal in setuptools to stop using this, even for easy_install.

The attached patch removes support for executing code in .pth files, throwing an ImportWarning if any such attempts at import are seen.

General question that might result in rejecting this patch:

Are there any good/valid use cases for .pth files being able to execute arbitrary code at interpreter start time?

If this is accepted, some implementation questions:

1. if the feature is removed in 3.6, should a DeprecationWarning be added to 3.5?
2. Is ImportWarning the right warning class (or should there even be a warning)?

----------
components: Installation
files: 0001-disable-executing-code-in-.pth-files.patch
keywords: patch
messages: 245959
nosy: minrk
priority: normal
severity: normal
status: open
title: disable executing code in .pth files
versions: Python 3.6
Added file: http://bugs.python.org/file39836/0001-disable-executing-code-in-.pth-files.patch

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

From report at bugs.python.org  Tue Jun 30 05:56:36 2015
From: report at bugs.python.org (Nick Levinson)
Date: Tue, 30 Jun 2015 03:56:36 +0000
Subject: [New-bugs-announce] [issue24535] SELinux reporting writes, executes,
	and dac_overwrites
Message-ID: <1435636596.24.0.22907134947.issue24535@psf.upfronthosting.co.za>


New submission from Nick Levinson:

Suddenly, SELinux in my Fedora 20 Linux laptop is reporting many problems with /usr/bin/python2.7 and I don't know if there's a bug in python2.7 or if something else is going on. File/s or directory/ies on which writes were attempted were on unspecified file/s or drectory/ies. Thirteen alerts occurred within the same minute soon after a cold boot, although I at first thought it was only one alert until I clicked buttons. Each alert apparently represents multiple alert-worthy events. Following are the data reported by SELinux, separated by rows of equals signs.

=====

Occurred "12" & later occurred "7" (I assume 12 and 7 times, respectively, unless the numbers mean something else):

=====

SELinux is preventing /usr/bin/python2.7 from using the dac_override capability.

*****  Plugin dac_override (91.4 confidence) suggests   **********************

If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending file and generate the error again.
Do

Turn on full auditing
# auditctl -w /etc/shadow -p w
Try to recreate AVC. Then execute
# ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it, 
otherwise report as a bugzilla.

*****  Plugin catchall (9.59 confidence) suggests   **************************

If you believe that python2.7 should have the dac_override capability by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep python /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:blueman_t:s0-s0:c0.c1023
Target Context                system_u:system_r:blueman_t:s0-s0:c0.c1023
Target Objects                 [ capability ]
Source                        python
Source Path                   /usr/bin/python2.7
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           python-2.7.5-16.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-197.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.19.8-100.fc20.x86_64
                              #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64
Alert Count                   12
First Seen                    2015-06-28 11:16:53 EDT
Last Seen                     2015-06-28 17:04:49 EDT
Local ID                      146e4bfb-abdf-44a1-86da-3b538f53fac8

Raw Audit Messages
type=AVC msg=audit(1435525489.77:442): avc:  denied  { dac_override } for  pid=2232 comm="python" capability=1  scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tclass=capability permissive=0


type=SYSCALL msg=audit(1435525489.77:442): arch=x86_64 syscall=access success=no exit=EACCES a0=7ffcd4229aba a1=2 a2=0 a3=79 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null)

Hash: python,blueman_t,blueman_t,capability,dac_override

=====

Occurred "7":

=====

SELinux is preventing /usr/bin/python2.7 from execute access on the file .

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that python2.7 should be allowed execute access on the  file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep python /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:blueman_t:s0-s0:c0.c1023
Target Context                system_u:object_r:blueman_var_run_t:s0
Target Objects                 [ file ]
Source                        python
Source Path                   /usr/bin/python2.7
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           python-2.7.5-16.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-197.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.19.8-100.fc20.x86_64
                              #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64
Alert Count                   7
First Seen                    2015-06-28 11:16:53 EDT
Last Seen                     2015-06-28 17:04:49 EDT
Local ID                      76953ff5-42e6-4c2b-a057-cd59b586dd12

Raw Audit Messages
type=AVC msg=audit(1435525489.78:445): avc:  denied  { execute } for  pid=2232 comm="python" path=2F72756E2F66666971584B4A3755202864656C6574656429 dev="tmpfs" ino=32567 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:blueman_var_run_t:s0 tclass=file permissive=0


type=SYSCALL msg=audit(1435525489.78:445): arch=x86_64 syscall=mmap success=no exit=EACCES a0=0 a1=1000 a2=5 a3=1 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null)

Hash: python,blueman_t,blueman_var_run_t,file,execute

=====

Occurred "7":

=====

SELinux is preventing /usr/bin/python2.7 from write access on the directory .

*****  Plugin setenforce (91.4 confidence) suggests   ************************

If you believe /usr/bin/python2.7 tried to disable SELinux.
Then you may be under attack by a hacker, since confined applications should never need this access.
Do
contact your security administrator and report this issue.

*****  Plugin catchall (9.59 confidence) suggests   **************************

If you believe that python2.7 should be allowed write access on the  directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep python /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:blueman_t:s0-s0:c0.c1023
Target Context                system_u:object_r:security_t:s0
Target Objects                 [ dir ]
Source                        python
Source Path                   /usr/bin/python2.7
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           python-2.7.5-16.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-197.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.19.8-100.fc20.x86_64
                              #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64
Alert Count                   7
First Seen                    2015-06-28 11:16:53 EDT
Last Seen                     2015-06-28 17:04:49 EDT
Local ID                      09c40fd9-63ae-4dcb-8ff7-e7e496102bde

Raw Audit Messages
type=AVC msg=audit(1435525489.79:448): avc:  denied  { write } for  pid=2232 comm="python" name="/" dev="selinuxfs" ino=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=dir permissive=0


type=SYSCALL msg=audit(1435525489.79:448): arch=x86_64 syscall=access success=no exit=EACCES a0=7ffcd4229aba a1=2 a2=0 a3=0 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null)

Hash: python,blueman_t,security_t,dir,write

=====

Occurred "8" and, if that's a count of occurrences, 69 more times (77 total):

=====

SELinux is preventing /usr/bin/python2.7 from write access on the directory .

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that python2.7 should be allowed write access on the  directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep python /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:blueman_t:s0-s0:c0.c1023
Target Context                system_u:object_r:debugfs_t:s0
Target Objects                 [ dir ]
Source                        python
Source Path                   /usr/bin/python2.7
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           python-2.7.5-16.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-197.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.19.8-100.fc20.x86_64
                              #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64
Alert Count                   8
First Seen                    2015-06-28 11:16:53 EDT
Last Seen                     2015-06-28 17:04:49 EDT
Local ID                      afd472d0-9c1a-4b15-bd94-3eaefd0382d4

Raw Audit Messages
type=AVC msg=audit(1435525489.80:451): avc:  denied  { write } for  pid=2232 comm="python" name="/" dev="debugfs" ino=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:debugfs_t:s0 tclass=dir permissive=0


type=SYSCALL msg=audit(1435525489.80:451): arch=x86_64 syscall=access success=no exit=EACCES a0=7ffcd4229ab8 a1=2 a2=0 a3=0 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null)

Hash: python,blueman_t,debugfs_t,dir,write

=====

----------
messages: 245975
nosy: Nick
priority: normal
severity: normal
status: open
title: SELinux reporting writes, executes, and dac_overwrites
type: security
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 30 09:19:17 2015
From: report at bugs.python.org (Jonathan Slenders)
Date: Tue, 30 Jun 2015 07:19:17 +0000
Subject: [New-bugs-announce] [issue24536] os.pipe() should return a
	structsequence (or namedtuple.)
Message-ID: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za>


New submission from Jonathan Slenders:

As discussed on python-ideas, os.pipe should return a structsequence instead of a plain tuple.

To be decided is the naming for the read and write end.
Personally, I'm in favour of using readfd/writefd.

> our_pipe = pipe()
> os.write(our_pipe.writefd, b'data')
> os.read(our_pipe.readfd, 1024)

----------
components: IO
messages: 245980
nosy: jonathan.slenders
priority: normal
severity: normal
status: open
title: os.pipe() should return a structsequence (or namedtuple.)
versions: Python 3.6

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

From report at bugs.python.org  Tue Jun 30 12:04:31 2015
From: report at bugs.python.org (Dana Christen)
Date: Tue, 30 Jun 2015 10:04:31 +0000
Subject: [New-bugs-announce] [issue24537] Py_Initialize unable to load the
	file system codec
Message-ID: <1435658671.67.0.0806508765667.issue24537@psf.upfronthosting.co.za>


New submission from Dana Christen:

I'm using the C API to embed the Python interpreter (see the attached example). Everything works fine until I try to run the resulting executable on a machine without a Python installation. In that case, the call to Py_Initialize fails with the following message:

Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

This was on Windows 7 64 bit, and the program was compiled using MS Visual Studio 2010 in x64 Release mode, using the official Python 3.4.3 64 bit release (v3.4.3:9b73f1c3e601).

----------
components: Extension Modules
files: python_api_hello.c
messages: 245984
nosy: Dana Christen
priority: normal
severity: normal
status: open
title: Py_Initialize unable to load the file system codec
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file39838/python_api_hello.c

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

From report at bugs.python.org  Tue Jun 30 14:07:21 2015
From: report at bugs.python.org (Gerrit Holl)
Date: Tue, 30 Jun 2015 12:07:21 +0000
Subject: [New-bugs-announce] [issue24538] os.setxattr PermissionError on
 panfs propagates up causing `copystat`, `copytree`,
 and `pip install .` to fail unhepfully
Message-ID: <1435666041.75.0.103684760482.issue24538@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

`shutil.copystat` fails on [panfs](https://en.wikipedia.org/wiki/Panasas#PanFS) if the source file lacks u+w, because setting extended attributes results in a `PermissionError`.  This leads to higher end functions such as `shutil.copytree` to fail.  More seriously, it leads to `pip install .` to fail, as I [reported here](https://github.com/pypa/pip/issues/2941):

    In [55]: shutil.copystat("/src/on/panfs", "/tmp/fubar")
    ---------------------------------------------------------------------------
    PermissionError                           Traceback (most recent call last)
    <ipython-input-55-139c9fc77184> in <module>()
    ----> 1 shutil.copystat("/home/users/gholl/checkouts/pyatmlab/.git/objects/pack/pack-c1449559ec4287b3830efe2913608dddf2f21391.pack", "/tmp/fubar")
    
    /home/users/gholl/lib/python3.4/shutil.py in copystat(src, dst, follow_symlinks)
        211             else:
        212                 raise
    --> 213     _copyxattr(src, dst, follow_symlinks=follow)
        214
        215 def copy(src, dst, *, follow_symlinks=True):
    
    /home/users/gholl/lib/python3.4/shutil.py in _copyxattr(src, dst, follow_symlinks)
        151             try:
        152                 value = os.getxattr(src, name, follow_symlinks=follow_symlinks)
    --> 153                 os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
        154             except OSError as e:
        155                 if e.errno not in (errno.EPERM, errno.ENOTSUP, errno.ENODATA):
    
    PermissionError: [Errno 13] Permission denied: '/tmp/fubar'

This occurs for any source file where the user write bit is not set.

Now, I'm not sure if this should be addressed in `pip`, `shutil.copytree`, `shutil.copystat`, `setxattr`, `panfs`, or in none of the above.  I'm reporting it in different places; please close this issue if this is the wrong place.

----------
components: Library (Lib)
messages: 245985
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jun 30 14:54:46 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 30 Jun 2015 12:54:46 +0000
Subject: [New-bugs-announce] [issue24539]
 StreamReaderProtocol.eof_received() should return True to keep the
 transport open
Message-ID: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

See https://github.com/python/asyncio/issues/251. I'm on vacation and may or may not find the time to actually fix this (it needs a unittest written).

----------
components: asyncio
messages: 245986
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: StreamReaderProtocol.eof_received() should return True to keep the transport open
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jun 30 22:16:22 2015
From: report at bugs.python.org (Matthew Havard)
Date: Tue, 30 Jun 2015 20:16:22 +0000
Subject: [New-bugs-announce] [issue24540] Documentation about skipkeys
 parameter for json.dumps is incorrect
Message-ID: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za>


New submission from Matthew Havard:

The documentation from json.dumps says this about skipkeys:

    If ``skipkeys`` is false then ``dict`` keys that are not basic types
    (``str``, ``int``, ``float``, ``bool``, ``None``) will be skipped
    instead of raising a ``TypeError``.

However, that contradicts the docstrings for JSONEncoder in the encoder.py file, and json.dump in the same file, __init__.py:

json.dump:
    If ``skipkeys`` is true then ``dict`` keys that are not basic types
    (``str``, ``int``, ``float``, ``bool``, ``None``) will be skipped
    instead of raising a ``TypeError``.

JSONEncoder:
        If skipkeys is false, then it is a TypeError to attempt
        encoding of keys that are not str, int, long, float or None.  If
        skipkeys is True, such items are simply skipped.

So the fix is just that the word "false" to "true".

----------
messages: 245997
nosy: Matthew Havard
priority: normal
severity: normal
status: open
title: Documentation about skipkeys parameter for json.dumps is incorrect
versions: Python 2.7

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