From report at bugs.python.org  Sun Nov  1 04:49:58 2015
From: report at bugs.python.org (Antony Lee)
Date: Sun, 01 Nov 2015 09:49:58 +0000
Subject: [New-bugs-announce] [issue25527] Invalid (... and confusing)
 warning raised by 2to3 regarding repeat
Message-ID: <1446371398.34.0.43007110205.issue25527@psf.upfronthosting.co.za>


New submission from Antony Lee:

$ echo 'from numpy import repeat\nrepeat(2, 3)' | 2to3 -
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: No files need to be modified.
RefactoringTool: Warnings/messages while refactoring:
RefactoringTool: ### In file <stdin> ###
RefactoringTool: Line 2: You should use 'operator.mul(2, 3)' here.

numpy.repeat(2, 3) returns np.array([2, 2, 2]) but 2to3 confuses it with the old operator.repeat.  It may be impossible to resolve in general which function the author wanted to call but perhaps the warning should only be raised if the operator module is imported at some point?  (or clarify the error message)

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 253835
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Invalid (... and confusing) warning raised by 2to3 regarding repeat
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Nov  1 04:57:43 2015
From: report at bugs.python.org (Rohit Mediratta)
Date: Sun, 01 Nov 2015 09:57:43 +0000
Subject: [New-bugs-announce] [issue25528] Attempt to further increase test
 coverage of calendar module
Message-ID: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za>


New submission from Rohit Mediratta:

Opened to submit a patch.

- make patchcheck succeeded
- full testsuite succeeded
- Old coverage 
   Lib/calendar.py     375     54    86%   511, 519, 541, 608-699, 703
- New coverage
   Lib/calendar.py     375     51    86%   608-699, 703

----------
components: Tests
files: mywork.patch
keywords: patch
messages: 253836
nosy: Rohit Mediratta
priority: normal
severity: normal
status: open
title: Attempt to further increase test coverage of calendar module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40916/mywork.patch

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

From report at bugs.python.org  Sun Nov  1 13:39:40 2015
From: report at bugs.python.org (Cory Benfield)
Date: Sun, 01 Nov 2015 18:39:40 +0000
Subject: [New-bugs-announce] [issue25529] Provide access to the validated
 certificate chain in ssl module
Message-ID: <1446403180.28.0.269111083171.issue25529@psf.upfronthosting.co.za>


New submission from Cory Benfield:

I?m currently working on adding support for HPKP to the Requests and urllib3 modules. HPKP (HTTP Public Key Pinning), specified in RFC 7469, is an extension to HTTP that allows a web server to specify a whitelist of public keys that are valid for TLS certificates on that domain. This prevents a rogue certificate authority from issuing a certificate that would be trusted by a browser and would allow a man-in-the-middle attack on a domain (as happened to Google in 2013[0]).

Right now, the draft version of the support I have will only work when you use PyOpenSSL for your TLS needs, not the standard library. This is because to get HPKP to work I need access to the validated certificate chain: that is, the certificate chain that OpenSSL has built and validated for the TLS connection. I also need to be able to work with those certificates in order to extract their public keys. The standard library?s ssl module does not expose any of this functionality.

To get this to work with the standard library, I would require the following things from the standard library:

1. The ability to access the validated certificate chain. This requires saving off the certificate each time the OpenSSL verify callback is called. This is an easy enough change to make.
2. The ability to extract the public key from the saved certificates. This could be done by extending the logic used for getpeercert() to provide a DER-encoded ASN.1 representation of the public key in the dictionary, and then using that representation for each cert in the peer cert chain.

The motivation for making this available in the standard library would be pip. Right now python.org and all its subdomains (including pypi.python.org) are HPKP-enabled. Making this support available in the standard library would ensure that all pip installations are safe from man-in-the-middle attacks on its packaging infrastructure. Without it, a number of third-party packages would be required to add this security. In particular, pip could distribute a HPKP preload value for pypi.python.org, which would ensure that pip is truly invulnerable to MITM TLS attacks via malicious attackers coercing a CA to provide TLS certificates for *.python.org.

I?m happy to do the work required to provide this functionality, but I?d only like to start work if people believe there?s a likelihood of getting it merged.

[0]: https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ssl-certificate-fiasco-what-happened-and-what-happens-next/

----------
components: Library (Lib)
messages: 253864
nosy: Lukasa
priority: normal
severity: normal
status: open
title: Provide access to the validated certificate chain in ssl module
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Nov  1 14:10:54 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 01 Nov 2015 19:10:54 +0000
Subject: [New-bugs-announce] [issue25530] ssl: OP_NO_SSLv3 should always be
 set unless a user specifically asks for it
Message-ID: <1446405054.12.0.603454420685.issue25530@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

SSLv3 is broken, both _create_unverified_context and create_default_context turn it off, but we should make all contexts turn it off, like we do for SSLv2.

A patch is attached.

----------
components: Library (Lib)
files: sslv3.diff
keywords: needs review, patch, security_issue
messages: 253868
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: ssl: OP_NO_SSLv3 should always be set unless a user specifically asks for it
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40920/sslv3.diff

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

From report at bugs.python.org  Sun Nov  1 14:49:43 2015
From: report at bugs.python.org (kracekumar ramaraju)
Date: Sun, 01 Nov 2015 19:49:43 +0000
Subject: [New-bugs-announce] [issue25531] greenlet header file is missing
 inside virtualenv
Message-ID: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za>


New submission from kracekumar ramaraju:

I am using OSX 10.10.5 (14F27) and Python 3.5. Python 3.5 was installed via brew.
When greenlet is installed inside virtualenv using py3.5 header files are
missing inside /path/to/venv/include/python3.5m. As a result uwsgi is unable to build with asyncio support

~  brew info python3
python3: stable 3.5.0 (bottled), HEAD
Interpreted, interactive, object-oriented programming language
https://www.python.org/
/usr/local/Cellar/python3/3.4.3 (4721 files, 82M)
Poured from bottle
/usr/local/Cellar/python3/3.4.3_2 (5948 files, 98M)
Built from source
/usr/local/Cellar/python3/3.5.0 (3573 files, 61M) *
Poured from bottle
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/python3.rb
==> Dependencies
Build: xz , pkg-config 
Required: openssl 
Recommended: readline , sqlite , gdbm , xz 
Optional: homebrew/dupes/tcl-tk


Steps to reproduce
------------------
1. Create a venv

$/tmp  python3.5 -m virtualenv venv_bug

2. Install greenlet
$/tmp  . venv_bug/bin/activate
(venv_bug)$/tmp  pip install greenlet
Collecting greenlet
  Using cached greenlet-0.4.9.tar.gz
Building wheels for collected packages: greenlet
  Running setup.py bdist_wheel for greenlet
  Complete output from command /private/tmp/venv_bug/bin/python3.5 -c "import setuptools;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-sxtdlufe/greenlet/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/tmpf6g8rwt_pip-wheel-:
  running bdist_wheel
  running build
  running build_ext
  building 'greenlet' extension
  creating build
  creating build/temp.macosx-10.10-x86_64-3.5
  clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/include/python3.5m -c greenlet.c -o build/temp.macosx-10.10-x86_64-3.5/greenlet.o
  creating build/lib.macosx-10.10-x86_64-3.5
  clang -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.5/greenlet.o -o build/lib.macosx-10.10-x86_64-3.5/greenlet.cpython-35m-darwin.so
  installing to build/bdist.macosx-10.10-x86_64/wheel
  running install
  running install_lib
  creating build/bdist.macosx-10.10-x86_64
  creating build/bdist.macosx-10.10-x86_64/wheel
  copying build/lib.macosx-10.10-x86_64-3.5/greenlet.cpython-35m-darwin.so -> build/bdist.macosx-10.10-x86_64/wheel
  running install_headers
  creating build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9.data
  creating build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9.data/headers
  copying greenlet.h -> build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9.data/headers
  running install_egg_info
  running egg_info
  creating greenlet.egg-info
  writing top-level names to greenlet.egg-info/top_level.txt
  writing greenlet.egg-info/PKG-INFO
  writing dependency_links to greenlet.egg-info/dependency_links.txt
  writing manifest file 'greenlet.egg-info/SOURCES.txt'
  warning: manifest_maker: standard file '-c' not found

  reading manifest file 'greenlet.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  writing manifest file 'greenlet.egg-info/SOURCES.txt'
  Copying greenlet.egg-info to build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9-py3.5.egg-info
  running install_scripts
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-sxtdlufe/greenlet/setup.py", line 101, in <module>
      **setuptools_args)
    File "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/distutils/core.py", line 148, in setup
      dist.run_commands()
    File "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/distutils/dist.py", line 955, in run_commands
      self.run_command(cmd)
    File "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/distutils/dist.py", line 974, in run_command
      cmd_obj.run()
    File "/private/tmp/venv_bug/lib/python3.5/site-packages/wheel/bdist_wheel.py", line 213, in run
      archive_basename = self.get_archive_basename()
    File "/private/tmp/venv_bug/lib/python3.5/site-packages/wheel/bdist_wheel.py", line 161, in get_archive_basename
      impl_tag, abi_tag, plat_tag = self.get_tag()
    File "/private/tmp/venv_bug/lib/python3.5/site-packages/wheel/bdist_wheel.py", line 155, in get_tag
      assert tag == supported_tags[0]
  AssertionError

  ----------------------------------------
  Failed building wheel for greenlet
Failed to build greenlet
Installing collected packages: greenlet
  Running setup.py install for greenlet
Successfully installed greenlet-0.4.9

3. Install uWSGI
(venv_bug)$  /tmp  CFLAGS="-I/tmp/venv_bug/include/python3.5m" UWSGI_PROFILE="asyncio" pip install uwsgi
Collecting uwsgi
  Using cached uwsgi-2.0.11.2.tar.gz
Building wheels for collected packages: uwsgi
  Running setup.py bdist_wheel for uwsgi
  Complete output from command /private/tmp/venv_bug/bin/python3.5 -c "import setuptools;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/tmpwoq08qywpip-wheel-:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib
  copying uwsgidecorators.py -> build/lib
  installing to build/bdist.macosx-10.10-x86_64/wheel
  running install
  plugins/greenlet/greenlet.c:2:10: fatal error: 'greenlet/greenlet.h' file not found
  #include <greenlet/greenlet.h>
           ^
  1 error generated.

  ----------------------------------------
  Failed building wheel for uwsgi
Failed to build uwsgi
Installing collected packages: uwsgi
  Running setup.py install for uwsgi
    Complete output from command /private/tmp/venv_bug/bin/python3.5 -c "import setuptools, tokenize;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-69gibzr6-record/install-record.txt --single-version-externally-managed --compile --install-headers /private/tmp/venv_bug/bin/../include/site/python3.5/uwsgi:
    running install
    plugins/greenlet/greenlet.c:2:10: fatal error: 'greenlet/greenlet.h' file not found
    #include <greenlet/greenlet.h>
             ^
    1 error generated.

    ----------------------------------------
Command "/private/tmp/venv_bug/bin/python3.5 -c "import setuptools, tokenize;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-69gibzr6-record/install-record.txt --single-version-externally-managed --compile --install-headers /private/tmp/venv_bug/bin/../include/site/python3.5/uwsgi" failed with error code 1 in /private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi
Also setuptools is at latest version 18.2.

Installing uwsgi site wide succeeds. greenlet directory is present inside `python3.5m`.

(venv_bug)$  /tmp  ls -la /usr/local/include/python3.5m | grep greenlet
drwxr-xr-x   3 root   admin   102 Nov  1 20:40 greenlet

Links:
uWSGI asyncio: https://uwsgi-docs.readthedocs.org/en/latest/asyncio.html#building-uwsgi-with-asyncio-support
Greenlet issue thread: https://github.com/python-greenlet/greenlet/issues/96

----------
components: Macintosh
messages: 253870
nosy: kracekumar, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: greenlet header file is missing inside virtualenv
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Nov  1 18:50:17 2015
From: report at bugs.python.org (Chris Withers)
Date: Sun, 01 Nov 2015 23:50:17 +0000
Subject: [New-bugs-announce] [issue25532] infinite loop when running
 inspect.unwrap over unittest.mock.call
Message-ID: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za>


New submission from Chris Withers:

The following results in an infinite loop:

>>> from inspect import unwrap
>>> from unittest.mock import call
>>> unwrap(call)

This can occur when you use doctest.DocTestSuite to load doc tests from a module where unittest.mock.call has been imported.

----------
components: Library (Lib)
keywords: 3.5regression
messages: 253885
nosy: cjw296, michael.foord, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: infinite loop when running inspect.unwrap over unittest.mock.call
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov  2 06:14:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 Nov 2015 11:14:13 +0000
Subject: [New-bugs-announce] [issue25533] Make pkgutil.iter_modules() yield
 built-in modules
Message-ID: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za>


New submission from Martin Panter:

When no specific list of paths are given, pkgutil.iter_modules() and walk_packages() will list modules found on sys.path. But they don?t list built-in modules, which don?t live in a particular directory. So many users of these APIs (such as the ModuleScanner class in pydoc) have to separately iterate over sys.builtin_module_names.

I think it would be good to change the pkgutil module to also yield the builtin modules. Attached is a patch which does this.

However I had second thoughts on blindly changing the existing function to yield the extra modules, because this will hurt backward compatibility for people already working around the problem. For example, if I didn?t also update pydoc in my patch, a module search would list the built-in modules twice. Perhaps we could overcome this with an opt-in flag like iter_modules(builtins=True)? I?m interested if anyone else has an opinion on this.

Adding support for builtins could also help with proposals such as listing the entire library (Issue 20506) and autocompletion of module names (Issue 25419).

----------
components: Library (Lib)
files: iter-builtin.patch
keywords: patch
messages: 253905
nosy: martin.panter
priority: normal
severity: normal
status: open
title: Make pkgutil.iter_modules() yield built-in modules
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40926/iter-builtin.patch

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

From report at bugs.python.org  Mon Nov  2 10:35:17 2015
From: report at bugs.python.org (Sean Wang)
Date: Mon, 02 Nov 2015 15:35:17 +0000
Subject: [New-bugs-announce] [issue25534] SimpleHTTPServer throwed an
 exception due to negtive st_mtime attr in file
Message-ID: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za>


New submission from Sean Wang:

I transfered a file from remote Debian host to my local Windows 10 host using SecureFX.
I found that the file's last modifed date was ?1900?/?1?/1????0:00:00 on Windows.

I tried to serve this file to be downloaded, and it crashed as follows:
Exception happened during processing of request from ('192.168.1.102', 50978)

Traceback (most recent call last):
  File "C:\Python27\lib\SocketServer.py", line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "C:\Python27\lib\SocketServer.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "C:\Python27\lib\SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Python27\lib\SocketServer.py", line 655, in __init__
    self.handle()
  File "C:\Python27\lib\BaseHTTPServer.py", line 340, in handle
    self.handle_one_request()
  File "C:\Python27\lib\BaseHTTPServer.py", line 328, in handle_one_request
    method()
  File "C:\Python27\lib\SimpleHTTPServer.py", line 45, in do_GET
    f = self.send_head()
  File "C:\Python27\lib\SimpleHTTPServer.py", line 103, in send_head
    self.send_header("Last-Modified", self.date_time_string(fs.st_mtime))
  File "C:\Python27\lib\BaseHTTPServer.py", line 468, in date_time_string
    year, month, day, hh, mm, ss, wd, y, z = time.gmtime(timestamp)
ValueError: (22, 'Invalid argument')

I have checked the source code, and found it was because of the last modifed date of the file, I got this in console:

>>> os.fstat(f.fileno())
nt.stat_result(st_mode=33206, st_ino=4785074604093500L, st_dev=0L, st_nlink=1, st_uid=0, st_gid=0, st_size=3406L, st_atime=1446477520L, st_mtime=-2209017600L, st_ctime=1446370767L)

-2209017600L cannot be handled by "time.gmtime()" method and it throwed 
error

----------
components: Library (Lib)
messages: 253926
nosy: Sean.Wang
priority: normal
severity: normal
status: open
title: SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  2 11:35:19 2015
From: report at bugs.python.org (Rob Malouf)
Date: Mon, 02 Nov 2015 16:35:19 +0000
Subject: [New-bugs-announce] [issue25535] collections.Counter methods return
 Counter objects
Message-ID: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za>


New submission from Rob Malouf:

Several collections.Counter methods return Counter objects, which is leads to wrong or at least confusing behavior when Counter is subclassed.  For example, nltk.FreqDist is a subclass of Counter:

>>> x = nltk.FreqDist(['a','a','b','b','b'])
>>> y = nltk.FreqDist(['b','b','b','b','b'])
>>> z = x + y
>>> z.__class__
<class 'collections.Counter'>

This applies to __add__(), __sub__(), __or__(), __and__(), __pos__(), and __neg__().  

In contrast, the copy() method does (what I think is) the right thing:

>>> x.copy().__class__
<class 'nltk.probability.FreqDist'>

----------
components: Library (Lib)
messages: 253930
nosy: rmalouf
priority: normal
severity: normal
status: open
title: collections.Counter methods return Counter objects
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov  2 11:55:19 2015
From: report at bugs.python.org (Akira Li)
Date: Mon, 02 Nov 2015 16:55:19 +0000
Subject: [New-bugs-announce] [issue25536] use sys.platform instead of
 os.name in asyncio docs consistently
Message-ID: <1446483319.57.0.76121078527.issue25536@psf.upfronthosting.co.za>


New submission from Akira Li:

asyncio code uses "sys.platform == 'win32'" to detect OS.
asyncio docs use both os.name and sys.platform.

As far as I can tell there is no *practical* difference
between "os.name == 'nt" and "sys.platform == 'win32'"
for choosing asyncio.ProactorEventLoop()

I've attached a patch that replaces all os.name occurrences
in asyncio docs with sys.platform.

----------
components: asyncio
files: doc-asyncio-os.name->sys.platform.patch
keywords: patch
messages: 253931
nosy: akira, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: use sys.platform instead of os.name in asyncio docs consistently
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40930/doc-asyncio-os.name->sys.platform.patch

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

From report at bugs.python.org  Mon Nov  2 16:10:26 2015
From: report at bugs.python.org (Sjoerd Job Postmus)
Date: Mon, 02 Nov 2015 21:10:26 +0000
Subject: [New-bugs-announce] [issue25537] Call `isinstance` instead of
 `issubclass` during exception handling
Message-ID: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za>


New submission from Sjoerd Job Postmus:

Currently Python2.7 calls `PyObject_IsSubclass` during exception handling. This allows some virtual-base-class machinery to make Python believe a certain class should match an exception while it in reality does not.

However, this does not necessarily give one really enough granularity when dealing with base libraries which are not as granular in raising exceptions as one would like (the Python base library before PEP3151 comes to mind).

Currently I used the trick of calling `isinstance(sys.exc_info()[1], cls)` in the `__subclasscheck__`, which is sort-of a great work-around.[*].

This method is great for sort-of emulating PEP3151 in Python2.7, and similar work can be done for other libraries: making the exception classes appear more granular based on properties of the instance of the exception.

My belief is that by calling the `isinstance` during exception handling, one can use virtual base classes (or should I say virtual base instances) to their fullest potential in writing cleaner code.

I think this is important because exception-handling is already a place where messy code is likely to occur, and we need all the support we can get in making it just a tad less messy.[**]

Note: Python3.5 calls `PyType_IsSubtype`, which has #12029 open for a change towards `PyObject_IsSubclass`. As soon as (or before) that's implemented, I'd like to propose a similar change for Python3.5+: call `PyObject_IsInstance` when the raised exception is an instance.

[*] See https://github.com/sjoerdjob/exhacktion/ for how I use the described hack to somewhat emulate PEP3151 in Python2.7.
[**] One question that comes to mind is: why not just write a wrapper around the offending library. (1): If it's the base library, almost nobody is going to bother. (2): even if it's not the base library, the wrapper will likely be even more function calls, which may cost performance in both the good and the bad cases, instead of just the bad cases.

----------
components: Interpreter Core
messages: 253946
nosy: sjoerdjob
priority: normal
severity: normal
status: open
title: Call `isinstance` instead of `issubclass` during exception handling
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov  2 18:08:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Nov 2015 23:08:03 +0000
Subject: [New-bugs-announce] [issue25538] Traceback from __exit__ method is
 misleading
Message-ID: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za>


New submission from R. David Murray:

This is at least the second time that I've wasted a bunch of debugging time being mislead by the traceback from __exit__.  Perhaps I will remember from now on, but...I wonder if it would be possible/practical to improve the situation.  The problem is that in the traceback printed when __exit__ throws an error, the source line printed before the source line from inside the __exit__ is the last line of the 'with' block.  I kept staring at that line trying to figure out how the exception could possibly be getting raised from that line...which of course it wasn't really, it was the "line" in between that one and the next one, a psuedo-line representing the exit from the block.

I don't know if it would be worth the effort that would be required to somehow clarify this in the traceback (I'm not even sure what that would *look* like...maybe the first line of the with block instead?), but I thought I'd raise the issue to see if anyone had any clever ideas.

(Hopefully I haven't done this before...I tried searching for similar issues and didn't find anything.)

----------
messages: 253949
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Traceback from __exit__ method is misleading

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

From report at bugs.python.org  Tue Nov  3 01:38:03 2015
From: report at bugs.python.org (=?utf-8?b?7Iug64+Z7JuQ?=)
Date: Tue, 03 Nov 2015 06:38:03 +0000
Subject: [New-bugs-announce] [issue25539] python3 fail on parsing http header
Message-ID: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za>


New submission from ???:

I tried to login some website using requests session, but it failed because of parsing header.
This is header data of problem. It contains two line of continuous CRLF between the data.

Date: Mon, 02 Nov 2015 08:45:48 GMT
Server: Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8e-fips-rhel5 DAV/2 PHP/5.2.16 mod_fastcgi/2.4.6
X-Powered-By: PHP/5.2.16
P3P: CP="NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM PRE"

P3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC"
Set-Cookie: PHPSESSID=**; path=/
Set-Cookie: PHPSESSID=**; path=/
Content-Length: 81
Connection: close
Content-Type: text/html

function parse_headers in http.client, parsing exits when it meet CRLF. (https://hg.python.org/cpython/file/tip/Lib/http/client.py#l197)
Is it standard? Same code works well in python2, or even similar code in ruby.

----------
components: Library (Lib)
messages: 253966
nosy: ???
priority: normal
severity: normal
status: open
title: python3 fail on parsing http header
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Nov  3 01:58:31 2015
From: report at bugs.python.org (tanbro)
Date: Tue, 03 Nov 2015 06:58:31 +0000
Subject: [New-bugs-announce] [issue25540] virtual conf file encoding error
 on windows
Message-ID: <1446533911.62.0.714179099115.issue25540@psf.upfronthosting.co.za>


New submission from tanbro:

When create a new `venv` on windows, sometimes an `UnicodeDecodeError` occurred.

It seems that, it is caused by the system module `site`.

In `Lib/site.py`, line 468::

        with open(virtual_conf) as f:
            for line in f:
                line = line.strip()

The file `virtual_conf` was open with encoding `gbk` which is my windows default encoding, but in fact, the file is an `utf-8` one, so i think it should be::

        with open(virtual_conf, encoding='utf-8') as f:
            for line in f:
                line = line.strip()

----------
messages: 253968
nosy: tanbro
priority: normal
severity: normal
status: open
title: virtual conf file encoding error on windows
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  3 06:08:21 2015
From: report at bugs.python.org (PrzemeK)
Date: Tue, 03 Nov 2015 11:08:21 +0000
Subject: [New-bugs-announce] [issue25541] Wrong usage of sockaddr_un struct
 for abstract namespace unix sockets
Message-ID: <1446548901.72.0.800156558453.issue25541@psf.upfronthosting.co.za>


Changes by PrzemeK <soutys at o2.pl>:


----------
components: IO, Library (Lib)
nosy: soutys
priority: normal
severity: normal
status: open
title: Wrong usage of sockaddr_un struct for abstract namespace unix sockets
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Nov  3 07:30:08 2015
From: report at bugs.python.org (Mario Wenzel)
Date: Tue, 03 Nov 2015 12:30:08 +0000
Subject: [New-bugs-announce] [issue25542] tuple unpacking on assignment
 should be lazy for unpacked generators
Message-ID: <1446553808.55.0.885073556118.issue25542@psf.upfronthosting.co.za>


New submission from Mario Wenzel:

if I have an assignment
a = <some_generator> then a is the generator. 

But if I do any kind of unpacking
*a, = <some_generator> # a list of all items
a, *aa = <some_generator> # first item in a, list of rest in as

If the right-hand side is a generator expression, I would expect that 
a, *aa unpacks the first element into a and puts the whole generator (having yielded the first element) back into aa.

So the star-operator of tuple unpacking with the right-hand-side having a generator should be lazy and not exhaust the whole generator.

----------
components: Interpreter Core
messages: 253985
nosy: Mario Wenzel
priority: normal
severity: normal
status: open
title: tuple unpacking on assignment should be lazy for unpacked generators
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov  3 08:30:18 2015
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Tue, 03 Nov 2015 13:30:18 +0000
Subject: [New-bugs-announce] [issue25543] locale.atof keep '.' even if not
 part of the localeconv
Message-ID: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za>


New submission from C?dric Krier:

If a value containing '.' is passed to locale.atof, but '.' is not the locale decimal_point (and not the thousands_sep), it is anyway parsed as the decimal_point.
For me, it should raise a ValueError

----------
components: Library (Lib)
messages: 253989
nosy: ced
priority: normal
severity: normal
status: open
title: locale.atof keep '.' even if not part of the localeconv
type: behavior

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

From report at bugs.python.org  Tue Nov  3 09:15:46 2015
From: report at bugs.python.org (Min RK)
Date: Tue, 03 Nov 2015 14:15:46 +0000
Subject: [New-bugs-announce] [issue25544] cleanup temporary files in
 distutils.has_function
Message-ID: <1446560146.63.0.814875607484.issue25544@psf.upfronthosting.co.za>


New submission from Min RK:

One of the nits noted in http://bugs.python.org/issue717152, which introduced ccompiler.has_function, was that it does not clean up after itself.

This patch uses a TemporaryDirectory context to ensure that the files created during has_function are cleaned up.

----------
components: Distutils
files: 0001-cleanup-temporary-files-in-ccompiler.has_function.patch
keywords: patch
messages: 253993
nosy: dstufft, eric.araujo, minrk
priority: normal
severity: normal
status: open
title: cleanup temporary files in distutils.has_function
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40933/0001-cleanup-temporary-files-in-ccompiler.has_function.patch

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

From report at bugs.python.org  Tue Nov  3 09:43:30 2015
From: report at bugs.python.org (Christian Tanzer)
Date: Tue, 03 Nov 2015 14:43:30 +0000
Subject: [New-bugs-announce] [issue25545] email.message.get_payload returns
 wrong encoding
Message-ID: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za>


New submission from Christian Tanzer:

For an email message with `Content-type: text/plain; charset=utf-8`, in Python 3.5, get_payload returns a bytes object encoded with `latin-1`. Python 2.7 returns a str object encoded with `utf-8` as expected.

Running the attached test script `email_get_payload__test.py`  with Python 2.7 and 3.5 shows the difference.

Python 2.7::

    2.7.10.final.0 *** utf8 ***
    From: Christian Tanzer <tanzer at swing.co.at>
    To: Christian Tanzer <tanzer at swing.co.at>
    Content-type: text/plain; charset=utf-8


    Sehr geehrte Damen und Herren,

    ...

    Danke und mit freundlichen Gr?ssen,

    --
    Christian Tanzer                                    http://www.c-tanzer.at/

Python 3.5::

    3.5.0.final.0 *** latin-1 ***
    From: Christian Tanzer <tanzer at swing.co.at>
    To: Christian Tanzer <tanzer at swing.co.at>
    Content-type: text/plain; charset=utf-8


    Sehr geehrte Damen und Herren,

    ...

    Danke und mit freundlichen Gr?ssen,

    --
    Christian Tanzer                                    http://www.c-tanzer.at/

In both Python versions, `msg.get_content_charset()` returns None, which is not correct, either.

----------
components: Library (Lib)
files: email_get_payload__test.py
messages: 253994
nosy: tanzer at swing.co.at
priority: normal
severity: normal
status: open
title: email.message.get_payload returns wrong encoding
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40934/email_get_payload__test.py

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

From report at bugs.python.org  Tue Nov  3 10:41:13 2015
From: report at bugs.python.org (Ryan Franklin)
Date: Tue, 03 Nov 2015 15:41:13 +0000
Subject: [New-bugs-announce] [issue25546] python 3.5 installation problem;
 Error 0x80240017: Failed to execute MSU package
Message-ID: <1446565273.63.0.514880871574.issue25546@psf.upfronthosting.co.za>


New submission from Ryan Franklin:

Python 3.5 will not install on my Windows 7 Pro machine. The observed failure is : Error 0x80240017: Failed to execute MSU package.

This appears to be an open problem with Python 3.5. The same does not have any problems with the Python 3.4.1 installations.

----------
files: Python 3.5.0 (64-bit)_20151103101640.log
messages: 253998
nosy: rfrank1234
priority: normal
severity: normal
status: open
title: python 3.5 installation problem; Error 0x80240017: Failed to execute MSU package
type: behavior
Added file: http://bugs.python.org/file40935/Python 3.5.0 (64-bit)_20151103101640.log

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

From report at bugs.python.org  Tue Nov  3 12:49:00 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Nov 2015 17:49:00 +0000
Subject: [New-bugs-announce] [issue25547] Improve repr for files to show
 whether the file is open or closed.
Message-ID: <1446572940.81.0.863832720658.issue25547@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Good news in Python 3.5, the __repr__ for locks now indicates whether the lock is in a locked state.   Bad news for Python 3.x, the __repr__ for files lost the indication of the file's open/closed status:

Python 3:
---------
  $ python3.5
  Python 3.5.0 (v3.5.0:374f501f4567, Sep 12 2015, 11:00:19) 
  [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> open('hamlet.txt')
  <_io.TextIOWrapper name='hamlet.txt' mode='r' encoding='UTF-8'>

Python 2:
---------
  # python2.7
  Python 2.7.10 (v2.7.10:15c95b7d81dc, May 23 2015, 09:33:12) 
  [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> open('hamlet.txt')
  <open file 'hamlet.txt', mode 'r' at 0x1006a0660>

    ^----- status

----------
assignee: pitrou
messages: 254007
nosy: pitrou, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve repr for files to show whether the file is open or closed.
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov  3 13:40:11 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Nov 2015 18:40:11 +0000
Subject: [New-bugs-announce] [issue25548] Show the address in the repr for
 class objects
Message-ID: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

In old-style classes, the memory address of the class object is shown for both the class and for the instance.  In new-style classes, only the instance shows the address.  I and other Python instructors have found the memory address display to be useful and I think it should be added back:

Old-style
=========
 
  >>> class A:
  	pass

  >>> a = A()
  >>> A
  <class __main__.A at 0x10061e328>
  >>> a
  <__main__.A instance at 0x105292cb0> 


New-style
=========

  >>> class A(object):
  	pass

  >>> a = A()
  >>> A
  <class '__main__.A'>
  >>> a
  <__main__.A object at 0x105332cd0>

----------
messages: 254012
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Show the address in the repr for class objects
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov  3 23:11:46 2015
From: report at bugs.python.org (Kevin Jing Qiu)
Date: Wed, 04 Nov 2015 04:11:46 +0000
Subject: [New-bugs-announce] [issue25549] call sum on list of timedelta
 throws TypeError
Message-ID: <1446610306.98.0.69863764968.issue25549@psf.upfronthosting.co.za>


New submission from Kevin Jing Qiu:

Calling sum() on a list of timedelta objects results in TypeError: unsupported operand type(s) for +: 'int' and 'datetime.timedelta'

Here's a script that illustrates this behaviour:  (also attached)

import datetime

x = [datetime.timedelta(1), datetime.timedelta(2)]
print(x[0] + x[1])  # datetime.timedelta(3)
print(sum(x))  # TypeError: unsupported operand type(s) for +: 'int' and 'datetime.timedelta'


The bug is present in all version of Python 2 and Python 3

----------
components: Library (Lib)
files: demo.py
messages: 254038
nosy: kevinjqiu
priority: normal
severity: normal
status: open
title: call sum on list of timedelta throws TypeError
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/file40938/demo.py

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

From report at bugs.python.org  Wed Nov  4 04:02:56 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Wed, 04 Nov 2015 09:02:56 +0000
Subject: [New-bugs-announce] [issue25550] RecursionError in re with '(' * 500
Message-ID: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

I just found this thanks to Hypothesis[1]:

    >>> import re
    >>> re.compile('(' * 500)
    Traceback (most recent call last): 
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3.5/re.py", line 224, in compile
        return _compile(pattern, flags)
      File "/usr/lib/python3.5/re.py", line 293, in _compile
        p = sre_compile.compile(pattern, flags)
      File "/usr/lib/python3.5/sre_compile.py", line 536, in compile
        p = sre_parse.parse(p, flags)
      File "/usr/lib/python3.5/sre_parse.py", line 829, in parse
        p = _parse_sub(source, pattern, 0)
      File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub
        itemsappend(_parse(source, state))
      File "/usr/lib/python3.5/sre_parse.py", line 778, in _parse
        p = _parse_sub(source, state)
      File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub
        itemsappend(_parse(source, state))
      File "/usr/lib/python3.5/sre_parse.py", line 778, in _parse
        p = _parse_sub(source, state)
      File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub
        itemsappend(_parse(source, state))
      [...]
      File "/usr/lib/python3.5/sre_parse.py", line 493, in _parse
        subpattern = SubPattern(state)
    RecursionError: maximum recursion depth exceeded

It seems a maximum recursion error has been treated as a bug before (like in issue401612), so I'm guessing this isn't intended here either.

[1] https://hypothesis.readthedocs.org/

----------
components: Library (Lib)
messages: 254040
nosy: The Compiler, effbot, ezio.melotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: RecursionError in re with '(' * 500
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov  4 17:45:50 2015
From: report at bugs.python.org (Nir Soffer)
Date: Wed, 04 Nov 2015 22:45:50 +0000
Subject: [New-bugs-announce] [issue25551] Event's test_reset_internal_locks
 too fragile
Message-ID: <1446677150.66.0.649715763686.issue25551@psf.upfronthosting.co.za>


New submission from Nir Soffer:

test_reset_internal_locks is looking at Event's _cond._lock - this make it harder to change internal details of the Condition object and make the test fragile.

We should test the condition behavior instead.

----------
components: Tests
messages: 254074
nosy: nirs
priority: normal
severity: normal
status: open
title: Event's test_reset_internal_locks too fragile
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Nov  4 21:00:19 2015
From: report at bugs.python.org (Anthony C)
Date: Thu, 05 Nov 2015 02:00:19 +0000
Subject: [New-bugs-announce] [issue25552] python turtle page does not run
Message-ID: <1446688819.99.0.0895353718927.issue25552@psf.upfronthosting.co.za>


New submission from Anthony C:

Making this simple code to mess with turtle well it seems like after awhile I have encountered the window = turtle.Screen() doesnt seem to even open it up only the shell window and does nothing afterwards. Its quite annoying especially trying to practice with it and it doesnt work.

import turtle

def draw_square(some_turtle) :
        for i in range(1,5) :
            some_turtle.forward(100)
            some_turtle.right(90)

def draw_art() :
    window = turtle.Screen()
    window.bgcolor("red")
    brad = turtle.Turtle()
    brad.shape("turtle")
    brad.color("blue")
    brad.speed(2)
    for i in range (1,4) :
        draw_square(brad)
        brad.right(10)

    window.exitonclick()

----------
files: movies.py
messages: 254078
nosy: Anthony C
priority: normal
severity: normal
status: open
title: python turtle page does not run
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40942/movies.py

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

From report at bugs.python.org  Thu Nov  5 01:51:55 2015
From: report at bugs.python.org (Deli Zhang)
Date: Thu, 05 Nov 2015 06:51:55 +0000
Subject: [New-bugs-announce] [issue25553] SMTP.data(msg) function may cause
 the last CRLF of msg lost if msg is quoted-printable encoding.
Message-ID: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za>


New submission from Deli Zhang:

It's well known that in quoted-printable encoding the "CRLF" can be encoded to "=CRLF".
For example, in attachment file test.eml, the last line is "test message.=CRLF"
But after the mail is sent via SMTP and received by mail server (e.g. postfix), the last line will become "test message.=", 
then after decoding, you will see the unnecessary char "=" shown following "test message.".

The problem is caused by below code:
------------------------------------------------
class SMTP:
    ...
    def data(self, msg):
        ...
            q = quotedata(msg)
            if q[-2:] != CRLF:
                q = q + CRLF
            q = q + "." + CRLF
            self.send(q)
        ...
------------------------------------------------
Before it sends the message q, it will try to append the end-of-data sequence "<CRLF>.<CRLF>". 
As the implement, it checks whether there is "<CRLF>" in the message end, if yes then just need to append ".<CRLF>".
It looks rigorous and efficient, but it does not consider how mail server handle it.
As we know mail server will remove end-of-data sequence directly, and the left message is treat as mail data.

Thus the corresponding action should be taken on SMTP client side,
it's to say no need to check and just append end-of-data sequence here:
------------------------------------------------
class SMTP:
    ...
    def data(self, msg):
        ...
            q = quotedata(msg)
            q = q + CRLF + "." + CRLF
            self.send(q)
        ...
------------------------------------------------

----------
components: Library (Lib)
files: test.eml
messages: 254086
nosy: Deli Zhang
priority: normal
severity: normal
status: open
title: SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file40944/test.eml

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

From report at bugs.python.org  Thu Nov  5 03:27:44 2015
From: report at bugs.python.org (Jeroen van der Heijden)
Date: Thu, 05 Nov 2015 08:27:44 +0000
Subject: [New-bugs-announce] [issue25554] memory leak (reference cycles)
 using re
Message-ID: <1446712064.78.0.0396170354874.issue25554@psf.upfronthosting.co.za>


New submission from Jeroen van der Heijden:

When compiling a regular expression with groups (subpatterns), 
circular references are created.
Here is an example to illustrate the problem:

>>> import gc
>>> import re
>>> gc.disable() # disable garbage collector
>>> gc.collect() # make sure we start with 0
0
>>> re.compile('(a|b)') # compile something with groups
re.compile('(a|b)')
>>> gc.collect() # collects x objects depending on the compiled string
11


To fix the issue a weakref object for p is used.

----------
components: Library (Lib)
files: fix_mem_sre_parse.patch
keywords: patch
messages: 254092
nosy: joente
priority: normal
severity: normal
status: open
title: memory leak (reference cycles) using re
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file40948/fix_mem_sre_parse.patch

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

From report at bugs.python.org  Thu Nov  5 04:42:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Nov 2015 09:42:04 +0000
Subject: [New-bugs-announce] [issue25555] Fix parser and AST: fill lineno
 and col_offset when compiling AST from Python objects
Message-ID: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I wrote an AST optimizer which build AST from source code using ast.parse(), modify AST in place, and then compile the AST to bytecode.

The problem is that the lineno and col_offset attributes of the "arg" AST node are uninitialized when AST is rebuild from Python objects: compile(ast_tree, ...). As a consequence, the compilation may fail because lineno or col_offset values are invalid.

Attached patch enhances Parser/asdl_c.py to take "arg" attributes in account. It also updates the generated files Include/Python-ast.h and Python/Python-ast.c, and fix usage of the arg() function in Python/ast.c.

It looks like only the "arg" AST node had attributes which were initialized (other AST nodes are handled with a different code path which already filled attributes).

See Parser/Python.asdl for the definition of the "arg" AST node.

Note: Python 2.7 is not affected. In Python 2, function arguments are simple expressions, they don't have a dedicated type with lineno and col_offset attributes. "arg" was introduced in Python 3 with the PEP 3107 (function annotations).

----------
files: ast.patch
keywords: patch
messages: 254093
nosy: benjamin.peterson, haypo, matrixise, yselivanov
priority: normal
severity: normal
status: open
title: Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40949/ast.patch

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

From report at bugs.python.org  Thu Nov  5 04:52:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Nov 2015 09:52:03 +0000
Subject: [New-bugs-announce] [issue25556] Fixes for PyObject_GetItem()
Message-ID: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds assertions to PyObject_GetItem() to ensure that an exception is raised if the function failed. _Py_CheckFunctionResult() could be used to implement such check, but it might adds a little overhead, whereas I really don't think that such bug occurs in the wild. The assertion only helps when you develop a new custom type implementing the mapping API.

The patch also simplifies Python/ceval.c: it now considers that an exception is raised if PyObject_GetItem() returns NULL.

Finally, the patch also fixes a bug in the LOAD_NAME bytecode, when globals are not a dict but a custom type and the name doesn't exist in globals: clear the exception before calling PyObject_GetItem() on builtins.

----------
components: Interpreter Core
messages: 254094
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fixes for PyObject_GetItem()
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov  5 05:11:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Nov 2015 10:11:19 +0000
Subject: [New-bugs-announce] [issue25557] Optimize LOAD_NAME bytecode
Message-ID: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The LOAD_GLOBAL bytecode has a fast-path when globals and builtins have exactly the type 'dict'. It calls the _PyDict_LoadGlobal() function.

I propose to implement a similar optimization for LOAD_NAME, see attached patch.

The patch also fixes LOAD_GLOBAL and LOAD_NAME bytecodes when locals, globals or builtins are not exactly the type 'dict'. It clears the KeyError before trying the next PyObject_GetItem().

The patch changes also _PyDict_LoadGlobal() to call PyObject_Hash() if the hash was not computed yet. It might make it a little bit faster.

----------
components: Interpreter Core
files: pydict_loadname.patch
keywords: patch
messages: 254097
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize LOAD_NAME bytecode
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40950/pydict_loadname.patch

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

From report at bugs.python.org  Thu Nov  5 11:46:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Nov 2015 16:46:40 +0000
Subject: [New-bugs-announce] [issue25558] Use static asserts in C code
Message-ID: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch converts some dynamic assert to static asserts (Py_BUILD_ASSERT_EXPR). This allows to check static invariants at compile time.

----------
components: Extension Modules, Interpreter Core
files: use_Py_BUILD_ASSERT_EXPR.patch
keywords: patch
messages: 254117
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use static asserts in C code
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40955/use_Py_BUILD_ASSERT_EXPR.patch

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

From report at bugs.python.org  Thu Nov  5 11:54:37 2015
From: report at bugs.python.org (Tom Meagher)
Date: Thu, 05 Nov 2015 16:54:37 +0000
Subject: [New-bugs-announce] [issue25559] signal.siginterrupt description
 has typo
Message-ID: <1446742477.79.0.638926215917.issue25559@psf.upfronthosting.co.za>


New submission from Tom Meagher:

"if flag is False, system calls will be restarted when interrupted by signal signalnum, otherwise system calls will be interrupted."

This sentence doesn't make any sense as written.  I assume there should be a "not" in there somewhere, but I'm unclear if signal calls are not interrupted when the flag is false, or not interrupted when they are true.

----------
assignee: docs at python
components: Documentation
messages: 254121
nosy: Tom Meagher, docs at python
priority: normal
severity: normal
status: open
title: signal.siginterrupt description has typo
type: enhancement

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

From report at bugs.python.org  Thu Nov  5 13:31:58 2015
From: report at bugs.python.org (ppperry)
Date: Thu, 05 Nov 2015 18:31:58 +0000
Subject: [New-bugs-announce] [issue25560] Unhandled warning in
 test_unicode_file
Message-ID: <1446748318.85.0.363249133538.issue25560@psf.upfronthosting.co.za>


New submission from ppperry:

>python -Wall -m test.regrtest test_unicode_file
[1/1] test_unicode_file
C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  os.path.normcase(os.path.abspath(dst)))
C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  os.path.normcase(os.path.abspath(dst)))
C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  os.path.normcase(os.path.abspath(dst)))
C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  os.path.normcase(os.path.abspath(dst)))
1 test OK.

----------
components: Tests
messages: 254133
nosy: ppperry
priority: normal
severity: normal
status: open
title: Unhandled warning in test_unicode_file
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  5 14:57:36 2015
From: report at bugs.python.org (Ivan Bykov)
Date: Thu, 05 Nov 2015 19:57:36 +0000
Subject: [New-bugs-announce] [issue25561] unstable result of time.monotonic
Message-ID: <1446753456.41.0.00863124653173.issue25561@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.
>>> import platform
>>> platform.win32_ver()
('7', '6.1.7601', 'SP1', 'Multiprocessor Free')
>>> 
Result of test.py:
C:\1>"test.py"
0.000000 0.001000
C:\1>"test.py"
0.000000 0.001001
C:\1>"test.py"
0.000000 0.001000
C:\1>"test.py"
0.016000 0.001000
C:\1>"test.py"
0.000000 0.001000
C:\1>"test.py"
0.016000 0.001000
C:\1>"test.py"
0.000000 0.001000
C:\1>"test.py"
0.000000 0.001000
C:\1>"test.py"
0.016000 0.001000

----------
components: Windows
files: test.py
messages: 254136
nosy: haypo, ivb, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: unstable result of time.monotonic
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40957/test.py

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

From report at bugs.python.org  Thu Nov  5 16:49:02 2015
From: report at bugs.python.org (tzickel)
Date: Thu, 05 Nov 2015 21:49:02 +0000
Subject: [New-bugs-announce] [issue25562] Python 2 & 3 don't allow the user
 to disable ctypes SEH in windows
Message-ID: <1446760142.46.0.74280732074.issue25562@psf.upfronthosting.co.za>


New submission from tzickel:

In Windows, there is a mechanizm called SEH that allows C/C++ programs to catch OS Exceptions (such as divide by zero, page faults, etc..).

Python's ctypes module for some reason forces the user to wrap all ctypes FFI calls with a special SEH wrapper that converts those exceptions to Python exceptions.

For the UNIX people think about it that python installs a signal handler without you asking (or being able to remove it) when calling FFI functions.

The main issue with this, is that when you want to debug why a DLL behaves badly and you want a process dump (or catch the stack trace in the DLL) you can't without attaching a debugger and catching first-chance exceptions (because the ctypes SEH handling masks the issue).

My proposal is to have both in python 2 and in python 3 an option to call an FFI function with selectively using or not SEH.

Here is the SEH wrap (as you can see it's not optional in runtime):
https://github.com/python/cpython/blob/master/Modules/_ctypes/callproc.c#L806

----------
components: ctypes
messages: 254143
nosy: amaury.forgeotdarc, belopolsky, meador.inge, tzickel
priority: normal
severity: normal
status: open
title: Python 2 & 3 don't allow the user to disable ctypes SEH in windows
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Thu Nov  5 17:28:29 2015
From: report at bugs.python.org (Lester Veenstra)
Date: Thu, 05 Nov 2015 22:28:29 +0000
Subject: [New-bugs-announce] [issue25563] Windows 10 IDLE /Tniker startup
 problem
Message-ID: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za>


New submission from Lester Veenstra:

C:\Users\lbv>python
Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "d:\python27\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "d:\python27\lib\lib-tk\FixTk.py", line 65, in <module>
    import _tkinter
ImportError: DLL load failed: %1 is not a valid Win32 application.

----------
components: Tkinter
messages: 254144
nosy: veensl
priority: normal
severity: normal
status: open
title: Windows 10 IDLE /Tniker  startup problem
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  5 18:26:04 2015
From: report at bugs.python.org (ppperry)
Date: Thu, 05 Nov 2015 23:26:04 +0000
Subject: [New-bugs-announce] [issue25564] IDLE behaves differently that the
 standard interpreter when someone types `del __builtins__`
Message-ID: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za>


New submission from ppperry:

In IDLE the following code silently works:
>>> del __builtins__
>>> min
<built-in function min>

In the standard interpreter, it produces an error:
>>> del __builtins__
>>> min
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'min' is not defined

Note that saying `__builtins__ = 7` fails in idle as well.

----------
components: IDLE, Interpreter Core
messages: 254149
nosy: ppperry
priority: normal
severity: normal
status: open
title: IDLE behaves differently that the standard interpreter when someone types `del __builtins__`

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

From report at bugs.python.org  Fri Nov  6 00:22:27 2015
From: report at bugs.python.org (Jack O'Connor)
Date: Fri, 06 Nov 2015 05:22:27 +0000
Subject: [New-bugs-announce] [issue25565] subprocess.Popen creates
 inheritable file descriptors on Windows, can leak to other child processes
Message-ID: <1446787347.51.0.846654506724.issue25565@psf.upfronthosting.co.za>


New submission from Jack O'Connor:

The Windows implementation of Popen calls _make_inheritable(), which creates inheritable copies of Popen's file descriptors. If two Popen calls happen at the same time on different threads, these descriptors can leak to both child processes. Here's a demonstration of a deadlock caused by this bug:

https://gist.github.com/oconnor663/b1d39d58b232fc627d84

Victor Stinner also wrote up a summary of the security issues associated with leaking file descriptors in PEP 0446.

A workaround for this issue is to protect all Popen calls with a lock. Calls to wait() and communicate() don't need to be protected, so you can release the lock before you make those blocking calls. I don't see a way to safely use run() or the other convenience functions, if you're using pipes and multiple threads. Unfortunately close_fds=True is not allowed on Windows when any of stdin/stdout/stderr are set, which is going the be the case here.

Would it be feasible for Popen.__init__() to automatically protect the inheritable copies it creates, with a lock around that section? We already have the _waitpid_lock for POSIX, so it seems like thread safety is a goal.

----------
components: Library (Lib)
messages: 254168
nosy: oconnor663
priority: normal
severity: normal
status: open
title: subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes
type: security
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  6 06:43:35 2015
From: report at bugs.python.org (Jeroen van der Heijden)
Date: Fri, 06 Nov 2015 11:43:35 +0000
Subject: [New-bugs-announce] [issue25566] asyncio reference cycles after
 ConnectionResetError
Message-ID: <1446810215.4.0.896282956786.issue25566@psf.upfronthosting.co.za>


New submission from Jeroen van der Heijden:

When a ConnectionResetError occurs, reference cycles are created due to __traceback__. As far as I can see there's no way to prevent this to happen since the event loop exception handler is not called for the following events: BrokenPipeError, ConnectionResetError and ConnectionAbortedError. (selector_events.py, line 579)

In this case the connection is probably lost so '_protocol.connection_lost()' will not be called either. (at least we can't rely on this)

Maybe it's possible to just call the exception handler? Or, in case we want to ignore these errors set __traceback__ to None?

----------
components: asyncio
messages: 254184
nosy: gvanrossum, haypo, joente, yselivanov
priority: normal
severity: normal
status: open
title: asyncio reference cycles after ConnectionResetError
type: resource usage
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  6 07:52:23 2015
From: report at bugs.python.org (Jonas Thiem)
Date: Fri, 06 Nov 2015 12:52:23 +0000
Subject: [New-bugs-announce] [issue25567] shlex.quote doesn't work on
 bytestrings
Message-ID: <1446814343.82.0.823951892686.issue25567@psf.upfronthosting.co.za>


New submission from Jonas Thiem:

Demonstration:

>>> import shlex
>>> shlex.quote(b"abc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.4/shlex.py", line 285, in quote
    if _find_unsafe(s) is None:
TypeError: can't use a string pattern on a bytes-like object
>>>

Your question is now probably, why would anyone not want to use unicode strings here?

The reason is that for some operations (e.g. file access to some known paths) decoding and encoding from/to any sort of unicode interpretation can be lossy, specifically when the file path on the filesystem has broken/mixed encoding characters. In such a case, the shell command might need to be supplied as bytestring to ensure it is sent exactly as-is so such broken files can still be dealt with, without the Unicode interpretation possibly deforming the path in some bytes.

Since shlex.quote seems targeted at shell usage, it should therefore support this.

----------
components: Library (Lib)
messages: 254186
nosy: Jonas Thiem, The Compiler
priority: normal
severity: normal
status: open
title: shlex.quote doesn't work on bytestrings
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  6 09:56:13 2015
From: report at bugs.python.org (nicolas33)
Date: Fri, 06 Nov 2015 14:56:13 +0000
Subject: [New-bugs-announce] [issue25568] typing backport: AttributeError:
 'module' object has no attribute 'GeneratorType'
Message-ID: <1446821773.07.0.324057164116.issue25568@psf.upfronthosting.co.za>


New submission from nicolas33:

$ pip3 install typing
$ python3
>>> import typing
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nicolas/.local/lib64/python3.4/site-packages/typing.py", line 1449, in <module>
    _G_base = types.GeneratorType
AttributeError: 'module' object has no attribute 'GeneratorType'
>>>

----------
messages: 254198
nosy: nicolas33
priority: normal
severity: normal
status: open
title: typing backport: AttributeError: 'module' object has no attribute 'GeneratorType'
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  6 15:08:01 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 06 Nov 2015 20:08:01 +0000
Subject: [New-bugs-announce] [issue25569] Memory leak in
 SSLSocket.getpeercert()
Message-ID: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Run the following code:

import socket
import ssl
import sys


def main():
    ctx = ssl.create_default_context()
    s = socket.create_connection(('www.bing.com', 443))
    s = ctx.wrap_socket(s, server_hostname='www.bing.com')
    while True:
        s.getpeercert()

        sys.stderr.write('.')
        sys.stderr.flush()


if __name__ == '__main__':
    main()



and observe memory usage, you'll see it increases by a MB/s or so.

----------
messages: 254210
nosy: alex
priority: normal
severity: normal
status: open
title: Memory leak in SSLSocket.getpeercert()
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Nov  6 15:39:12 2015
From: report at bugs.python.org (Christian Rickert)
Date: Fri, 06 Nov 2015 20:39:12 +0000
Subject: [New-bugs-announce] [issue25570] urllib.request >
 Request.add_header("abcd",
 "efgh") fails with character ":" in first parameter string
Message-ID: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za>


New submission from Christian Rickert:

A piece of software stopped working after the update from Python 3.4.x to 3.5 (both Linux and Windows).

I found the cause in the  Request.add_header("abcd","efgh")  function:
If the first parameter string "abcd" contains a colon (":") character, a ValueError is raised and the execution stops.

This is an example code:

>>> import urllib.request
>>> import urllib.parse
>>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
>>> data = data.encode('utf-8')
>>> request = urllib.request.Request("http://requestb.in/xrbl82xr")
>>> # adding charset parameter to the Content-Type header.
>>> request.add_header("Content-Type:","application/x-www-form-urlencoded;charset=utf-8")
>>> with urllib.request.urlopen(request, data) as f:
...     print(f.read().decode('utf-8'))
...

This is the error:

Traceback (most recent call last):
  File "C:\Users\user\Desktop\example.py", line 9, in <module>
    with urllib.request.urlopen(request, data) as f:
  File "C:\python\lib\urllib\request.py", line 162, in urlopen
    return opener.open(url, data, timeout)
  File "C:\python\lib\urllib\request.py", line 465, in open
    response = self._open(req, data)
  File "C:\python\lib\urllib\request.py", line 483, in _open
    '_open', req)
  File "C:\python\lib\urllib\request.py", line 443, in _call_chain
    result = func(*args)
  File "C:\python\lib\urllib\request.py", line 1268, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "C:\python\lib\urllib\request.py", line 1240, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "C:\python\lib\http\client.py", line 1083, in request
    self._send_request(method, url, body, headers)
  File "C:\python\lib\http\client.py", line 1123, in _send_request
    self.putheader(hdr, value)
  File "C:\python\lib\http\client.py", line 1050, in putheader
    raise ValueError('Invalid header name %r' % (header,))
ValueError: Invalid header name b'Content-Type:'

Steps to reproduce:

Add a colon character anywhere into the first parameter of the  Request.add_header()  function and execute the code using Python 3.5.x.

----------
components: Library (Lib)
messages: 254214
nosy: crickert
priority: normal
severity: normal
status: open
title: urllib.request > Request.add_header("abcd","efgh") fails with character ":" in first parameter string
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  6 16:13:46 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 06 Nov 2015 21:13:46 +0000
Subject: [New-bugs-announce] [issue25571] Improve the lltrace feature with
 the Py_Debug mode
Message-ID: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

When we use the Py_Debug flag for the compilation, we can see the Bytecodes and the opcode arguments.

Here is a small patch, it will show the label of the opcode in the ceval.c file.

----------
messages: 254218
nosy: matrixise
priority: normal
severity: normal
status: open
title: Improve the lltrace feature with the Py_Debug mode

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

From report at bugs.python.org  Fri Nov  6 16:29:59 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 06 Nov 2015 21:29:59 +0000
Subject: [New-bugs-announce] [issue25572] _ssl doesn't build on OSX 10.11
Message-ID: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

On OSX 10.11, if you don't use Homebrew or MacPorts, the _ssl module is not built with Makefile.

Homebrew supports OpenSSL and LibreSSL, but OpenSSL is in /usr/local/opt/openssl and not in /usr/local/ssl (see setup.py)

So, the next point, I am not sure, but the headers of OpenSSL has not provided with OSX 10.11

----------
messages: 254222
nosy: matrixise
priority: normal
severity: normal
status: open
title: _ssl doesn't build on OSX 10.11

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

From report at bugs.python.org  Fri Nov  6 16:34:26 2015
From: report at bugs.python.org (Alexandre Macabies)
Date: Fri, 06 Nov 2015 21:34:26 +0000
Subject: [New-bugs-announce] [issue25573] traceback documentation example is
 lying about FrameSummary repr()
Message-ID: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>


New submission from Alexandre Macabies:

https://docs.python.org/3.5/library/traceback.html#traceback-examples
See second code sample and its sample output. According to the docs, the call:

  print(repr(traceback.extract_tb(exc_traceback)))

is supposed to print something that looks like an array with only strings; that is what the doc sample output states:

  [('<doctest...>', 10, '<module>', 'lumberjack()'),

But actually, in 3.5+, this call outputs the repr() of a list of FrameSummary instances that do not go further in repr()esenting their state:

  [<FrameSummary file <ipython-input-61-3e63d7daea82>, line 10 in <module>>,

By looking at the docs I thought I was able to get a nice string representation of a FrameSummary. I actually have to format it myself. It should be reflected in the doc sample output.

----------
assignee: docs at python
components: Documentation
messages: 254224
nosy: Alexandre Macabies, docs at python
priority: normal
severity: normal
status: open
title: traceback documentation example is lying about FrameSummary repr()
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Nov  6 17:35:05 2015
From: report at bugs.python.org (wim glenn)
Date: Fri, 06 Nov 2015 22:35:05 +0000
Subject: [New-bugs-announce] [issue25574] 2.7 incorrectly documents objects
 hash as equal to id
Message-ID: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za>


New submission from wim glenn:

The 2.7 glossary still incorrectly mentions instances of user-defined classes hash equal to their id.  
https://docs.python.org/2/glossary.html#term-hashable

Just a minor documentation bug that was unfortunately missed by http://bugs.python.org/issue21782

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 254237
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: 2.7 incorrectly documents objects hash as equal to id
versions: Python 2.7
Added file: http://bugs.python.org/file40966/mywork.patch

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

From report at bugs.python.org  Fri Nov  6 18:46:50 2015
From: report at bugs.python.org (G)
Date: Fri, 06 Nov 2015 23:46:50 +0000
Subject: [New-bugs-announce] [issue25575] idle not working
Message-ID: <1446853610.68.0.999917057538.issue25575@psf.upfronthosting.co.za>


New submission from G:

I'm teaching Python in a computer lab with 28, new this Sept., Mac Minis. 
One of the machines will run from the command line in Terminal but will not run using IDLE. I'm using the turtle module for graphics. I've attached a screen snap of the code and error message. The top part of the image shows error message using IDLE. The bottom part of the image shows the same code runs from the command line. I just updated the OS to OSX 11.11.1 and it still did not fix the issue. 
Any ideas on how to fix it?

----------
components: IDLE
files: Python idle problem.png
messages: 254242
nosy: ccgm
priority: normal
severity: normal
status: open
title: idle not working
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file40967/Python idle problem.png

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

From report at bugs.python.org  Sat Nov  7 03:43:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Nov 2015 08:43:40 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CCo?=
 =?utf-8?q?ntent-Type=3A_application/x-www-form-urlencoded=3B_charset?=
 =?utf-8?q?=E2=80=9D_advice?=
Message-ID: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>


New submission from Martin Panter:

I understand using a ?charset? parameter with ?Content-Type: application/x-www-form-urlencoded? is not standardized. Since Issue 11082, the documentation advises to use it, but I propose to remove this advice.

HTML 5 mentions setting a _charset_ parameter, and mentions decoding with a default of UTF-8 (not Latin-1!), but does not mention any Content-Type parameters.

There seems to be confusion about what encoding it actually represents. According to <https://bugzilla.mozilla.org/show_bug.cgi?id=7533>, Mozilla briefly set this ?charset? parameter a long time ago, but it would have corresponded to the urlencode(encoding=...) argument. The Python documentation currently suggests calling data.encode("utf-8"), which is misleading, because the urlencode() output is already guaranteed to be ASCII text. Any non-ASCII characters and bytes will already be character-encoded and percent-encoded by urlencode(). So I also propose to change the examples to data.encode("ascii").

----------
assignee: docs at python
components: Documentation
files: urlencoded-charset.patch
keywords: patch
messages: 254263
nosy: docs at python, martin.panter, orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: Remove ?Content-Type: application/x-www-form-urlencoded; charset? advice
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40970/urlencoded-charset.patch

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

From report at bugs.python.org  Sat Nov  7 10:02:51 2015
From: report at bugs.python.org (Raffaele Mancuso)
Date: Sat, 07 Nov 2015 15:02:51 +0000
Subject: [New-bugs-announce] [issue25577] os.path.dirname leave left quote
 and remove right one
Message-ID: <1446908571.56.0.283810738924.issue25577@psf.upfronthosting.co.za>


New submission from Raffaele Mancuso:

Python 3.4.3 (default, Jun 29 2015, 12:16:01) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> dir = "\"ciao/come/stai/ciao.pdf\""
>>> dir
'"ciao/come/stai/ciao.pdf"'
>>> os.path.dirname(dir)
'"ciao/come/stai'

As you can see, dirname has removed the right quote, but not the left one.
The correct behaviour should be
'ciao/come/stai' (no quotes)
OR
'"ciao/come/stai"' (both quotes)
but never
'"ciao/come/stai' (only one quote)

This breaks other bash tools

----------
components: Library (Lib)
messages: 254273
nosy: Raffaele Mancuso
priority: normal
severity: normal
status: open
title: os.path.dirname leave left quote and remove right one
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov  7 10:28:36 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 07 Nov 2015 15:28:36 +0000
Subject: [New-bugs-announce] [issue25578] Memory leak in
 SSLSocket.getpeercert() with 0-length AIA extension
Message-ID: <1446910116.69.0.509897683055.issue25578@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Test.

Put this certificate in a file:

-----BEGIN CERTIFICATE-----
MIICjTCCAXWgAwIBAgIBADANBgkqhkiG9w0BAQsFADAAMB4XDTE1MTEwNzE1MTAw
NVoXDTE1MTEwNzE1MTAwNVowADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKiZ3rzOM1m6toThRtkwgZzjuVVdapwU63yoXmp91f14pfO1z5XIkVAP1Sz/
nK5Ti95LRmgPOzbIQHyNv2k2IOIbHL52y4AwWTa2G1EF3NvD9Tp6Zs85GFf7T5/N
WnlqHHPZhAHpgHL2xjBWnnhVojDm6fgxE6OI0aFarLlO0FBs3PLgIoxY4RRPVYaz
toP9G8ezbdGWGhaCqKO+ZjrCoQ2JNIdk4WsuGrZbCnGvGzFm+uhvs68IbJM4Mfm6
mAO85UfjdHsyacs5MYYsb7GyzrkGnLwWNcK5NdZiJwzwxBYpbchj5hYIsYjIVAL6
0BE4qG7wnJcHq1rvBeNgp7fP06kCAwEAAaMSMBAwDgYIKwYBBQUHAQEEAjAAMA0G
CSqGSIb3DQEBCwUAA4IBAQBS+2YG56erPLavJ3PvP+DekHOuIakT3l6GCiDGsufO
owdPxqsUZcCHlYjn6E50dLoKN0N6ECoKB0bIsA2EuwY08MSgtD4dA93jTXsdvWcX
2QMIM11LIGLyJIZRgUeMdHAbsb9qdpWFXX6smDGLBBKHCIFwu/4qSXU+Gf5d2DMl
edMDMkbgv3B8Q+7pCi7AgUOaZXPTbpHCdYnT2t+z3gNgyiXBH5wJNkrkK5tmawNb
88+Kxa00mbYoSEPaz7E/zBB/W1NpoZCOgEq4t9Uuk7hm10htbKoyM7FxVpBEJkPE
XpUdSNdClrHN36j1iB1NeFuOlxNVbD5FtMXx/wgX0B28
-----END CERTIFICATE-----


And run this script:

import _ssl

def main():
    while True:
        _ssl._test_decode_cert("/path/to/cert.pem")

main()


Patch is attached

----------
files: aia.diff
keywords: needs review, patch
messages: 254275
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: Memory leak in SSLSocket.getpeercert() with 0-length AIA extension
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40973/aia.diff

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

From report at bugs.python.org  Sat Nov  7 10:36:37 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 07 Nov 2015 15:36:37 +0000
Subject: [New-bugs-announce] [issue25579] def is not a keyword with
 tokenize.py
Message-ID: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

For tokenize.py, 'def' is not a keyword but just a simple identifier.

>>> tokens = tokenize.generate_tokens(io.StringIO('async def foo(): pass').readline)
>>> pprint.pprint(list(tokens))
[TokenInfo(type=55 (ASYNC), string='async', start=(1, 0), end=(1, 5), line='async def foo(): pass'),
 TokenInfo(type=1 (NAME), string='def', start=(1, 6), end=(1, 9), line='async def foo(): pass'),
 TokenInfo(type=1 (NAME), string='foo', start=(1, 10), end=(1, 13), line='async def foo(): pass'),
 TokenInfo(type=53 (OP), string='(', start=(1, 13), end=(1, 14), line='async def foo(): pass'),
 TokenInfo(type=53 (OP), string=')', start=(1, 14), end=(1, 15), line='async def foo(): pass'),
 TokenInfo(type=53 (OP), string=':', start=(1, 15), end=(1, 16), line='async def foo(): pass'),
 TokenInfo(type=1 (NAME), string='pass', start=(1, 17), end=(1, 21), line='async def foo(): pass'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]
>>> 'def' in keyword.kwlist
True
>>> tokens = tokenize.generate_tokens(io.StringIO('def foo(): pass').readline)
>>> pprint.pprint(list(tokens))
[TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3), line='def foo(): pass'),
 TokenInfo(type=1 (NAME), string='foo', start=(1, 4), end=(1, 7), line='def foo(): pass'),
 TokenInfo(type=53 (OP), string='(', start=(1, 7), end=(1, 8), line='def foo(): pass'),
 TokenInfo(type=53 (OP), string=')', start=(1, 8), end=(1, 9), line='def foo(): pass'),
 TokenInfo(type=53 (OP), string=':', start=(1, 9), end=(1, 10), line='def foo(): pass'),
 TokenInfo(type=1 (NAME), string='pass', start=(1, 11), end=(1, 15), line='def foo(): pass'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]
>>>

Is it normal ?

----------
messages: 254277
nosy: matrixise
priority: normal
severity: normal
status: open
title: def is not a keyword with tokenize.py

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

From report at bugs.python.org  Sat Nov  7 11:02:19 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 07 Nov 2015 16:02:19 +0000
Subject: [New-bugs-announce] [issue25580] async and await missing from token
 list
Message-ID: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>


New submission from SilentGhost:

With introduction of async and await tokens in 3.5 the token documentation needs updating.

----------
assignee: docs at python
components: Documentation
files: token.diff
keywords: patch
messages: 254281
nosy: SilentGhost, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: async and await missing from token list
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40974/token.diff

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

From report at bugs.python.org  Sat Nov  7 13:53:50 2015
From: report at bugs.python.org (ppperry)
Date: Sat, 07 Nov 2015 18:53:50 +0000
Subject: [New-bugs-announce] [issue25581] Python -U fails with traceback
Message-ID: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za>


New submission from ppperry:

C:\Documents and Settings\Perry>python -U
Traceback (most recent call last):
  File "C:\Python27\lib\site.py", line 548, in <module>
    main()
  File "C:\Python27\lib\site.py", line 537, in main
    aliasmbcs()
  File "C:\Python27\lib\site.py", line 465, in aliasmbcs
    import locale, codecs
  File "C:\Python27\lib\locale.py", line 182, in <module>
    _percent_re = re.compile(r'%(?:\((?P<key>.*?)\))?'
  File "C:\Python27\lib\re.py", line 194, in compile
    return _compile(pattern, flags)
  File "C:\Python27\lib\re.py", line 249, in _compile
    p = sre_compile.compile(pattern, flags)
  File "C:\Python27\lib\sre_compile.py", line 576, in compile
    code = _code(p, flags)
  File "C:\Python27\lib\sre_compile.py", line 561, in _code
    _compile(code, p.data, flags)
  File "C:\Python27\lib\sre_compile.py", line 151, in _compile
    _compile(code, av[1], flags)
  File "C:\Python27\lib\sre_compile.py", line 132, in _compile
    _compile(code, av[2], flags)
  File "C:\Python27\lib\sre_compile.py", line 107, in _compile
    _compile_charset(av, flags, code, fixup, fixes)
  File "C:\Python27\lib\sre_compile.py", line 232, in _compile_charset
    flags & SRE_FLAG_UNICODE):
  File "C:\Python27\lib\sre_compile.py", line 316, in _optimize_charset
    p = charmap.find(b'\1', q)
TypeError: Type unicode doesn't support the buffer API

----------
messages: 254293
nosy: ppperry
priority: normal
severity: normal
status: open
title: Python -U fails with traceback

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

From report at bugs.python.org  Sat Nov  7 15:18:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Nov 2015 20:18:20 +0000
Subject: [New-bugs-announce] [issue25582] Fixed memory leaks in test_ctypes
Message-ID: <1446927500.57.0.889992318056.issue25582@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

POINTER() saves its result in internal cache. test_pointer_type_name and test_pointer_type_str_name use large names and resulting types consume much memory. This can be one of the causes of tests failure on the AIX buildbot with very limited memory.

If run tests repeatedly, the cache grows and can consume all memory even on the machine with enough memory.

Proposed patch fixes leaks.

----------
components: Tests, ctypes
messages: 254295
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fixed memory leaks in test_ctypes
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Nov  8 09:34:33 2015
From: report at bugs.python.org (Daniel Plachotich)
Date: Sun, 08 Nov 2015 14:34:33 +0000
Subject: [New-bugs-announce] [issue25583] os.makedirs with exist_ok=True
 raises PermissionError on Windows 7^
Message-ID: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za>


New submission from Daniel Plachotich:

Since Windows 7 (or even Vista), Windows gives permission error(5, ERROR_ACCESS_DENIED
if you try to create a directory in a drive root with the same name as a drive itself,
even if you have administrative permissions. This behavior is not mentioned in Microsoft docs.

Here is an example session (Windows 7, admin):
d:\>IF EXIST . echo True
True
d:\>mkdir .
Access is denied.
d:\>mkdir dir
d:\>cd dir
d:\dir>mkdir .
A subdirectory or file . already exists.
d:\dir>cd ..
d:\>
d:\>py -3
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (In
tel)] on win32
>>> import os
>>> os.path.isdir('.')
True
>>> os.makedirs('.', exist_ok=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\os.py", line 237, in makedirs
    mkdir(name, mode)
PermissionError: [WinError 5] ...
>>> try:
...   os.mkdir('.')
... except OSError as e:
...   print(e.errno)
...
13

This means that if you want to write portable code, you still need to write like in Python 2:
    if not os.path.isdir(path):
        os.makedirs(path)
Which makes exist_ok useless.

The actual problem is in this line (Lib/os.py#l243):
    if not exist_ok or e.errno != errno.EEXIST or not path.isdir(name):

Due the reasons described above, makedirs shouldn't rely on e.errno, so the right code will be:
    if not (exist_ok and path.isdir(name)):

I think the issue is pretty serious to be backported.

----------
components: Library (Lib)
messages: 254339
nosy: Daniel Plachotich
priority: normal
severity: normal
status: open
title: os.makedirs with exist_ok=True raises PermissionError on Windows 7^
type: behavior
versions: 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/issue25583>
_______________________________________

From report at bugs.python.org  Sun Nov  8 10:54:35 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 08 Nov 2015 15:54:35 +0000
Subject: [New-bugs-announce] [issue25584] a recursive glob pattern fails to
 list files in the current directory
Message-ID: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

On archlinux during an upgrade, the package manager backups some files in /etc with a .pacnew extension. On my system there are 20 such files, 9 .pacnew files located in /etc and 11 .pacnew files in subdirectories of /etc. The following commands are run from /etc:

    $ shopt -s globstar
    $ ls **/*.pacnew | wc -w
    20
    $ ls *.pacnew | wc -w
    9

With python:

    $ python
    Python 3.6.0a0 (default:72cca30f4707, Nov  2 2015, 14:17:31) 
    [GCC 5.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import glob
    >>> len(glob.glob('./**/*.pacnew', recursive=True))
    20
    >>> len(glob.glob('*.pacnew'))
    9
    >>> len(glob.glob('**/*.pacnew', recursive=True))
    11

The '**/*.pacnew' pattern does not list the files in /etc, only those located in the subdirectories of /etc.

----------
components: Library (Lib)
messages: 254344
nosy: serhiy.storchaka, xdegaye
priority: normal
severity: normal
status: open
title: a recursive glob pattern fails to list files in the current directory
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Nov  8 12:36:01 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sun, 08 Nov 2015 17:36:01 +0000
Subject: [New-bugs-announce] [issue25585] Bad path leads to: ImportError:
 DLL load failed: %1 is not a valid Win32 application.
Message-ID: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za>


New submission from Laura Creighton:

Somebody reported this today:

File "C:/Python27/kivyhello.py", line 4, in <module>
     from kivy.app import App
   File "C:/Python27\kivy\app.py", line 316, in <module>
     from kivy.base import runTouchApp, stopTouchApp
   File "C:/Python27\kivy\base.py", line 30, in <module>
     from kivy.event import EventDispatcher
   File "C:/Python27\kivy\event.py", line 8, in <module>
     import kivy._event
 ImportError: DLL load failed: %1 is not a valid Win32 application.

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

The problem was that they needed to set their PATH properly so kivy could be found.

Couldn't we generate a more informative error message here?
Is the %1 even correct?

----------
messages: 254349
nosy: lac
priority: normal
severity: normal
status: open
title: Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application.
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  8 16:47:35 2015
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Nov 2015 21:47:35 +0000
Subject: [New-bugs-announce] [issue25586] socket.sendall broken when a
 socket has a timeout
Message-ID: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>


New submission from Jakub Stasiak:

It is my understanding that socket.sendall effectively calls the underlying socket.send's implementation in a retry loop, possibly multiple times.

It is also my understanding that each one of those low level send calls can timeout on its own if a socket timeout is set.

Considering the above I believe it's undesired to ever call socket.sendall with a socket that has a timeout set because if:

1. At least one send call succeeds
2. A send call after that times out

then a socket timeout error will be raised and the information about the sent data will be lost.

Granted, the documentation says that "On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent". I believe, however, that such API is very easy to misuse (I've seen it used with sockets with timeout set, because of small payload sizes and other circumstances it would appear to work fine most of the time and only fail every N hours or days).

Possible improvements I see:

1. Explicitly mention interaction between socket's timeout and sendall's behavior in the documentation
2. Make sendall raise an error when the socket it's called with has a timeout set (I can see the backwards compatibility being a concern here but I can't think of any reason to remain compatible with behavior I believe to be broken anyway)
3. Both of the above

I'm happy to procure an appropriate patch for any of the above. Please correct me if my understanding of this is off.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 254357
nosy: docs at python, jstasiak
priority: normal
severity: normal
status: open
title: socket.sendall broken when a socket has a timeout
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/issue25586>
_______________________________________

From report at bugs.python.org  Mon Nov  9 00:44:35 2015
From: report at bugs.python.org (Jim Nasby)
Date: Mon, 09 Nov 2015 05:44:35 +0000
Subject: [New-bugs-announce] [issue25587] Useless addition in PyTuple_New
Message-ID: <1447047875.1.0.253447135487.issue25587@psf.upfronthosting.co.za>


New submission from Jim Nasby:

In PyTuple_New, if the new tuple won't go on the free_list:

		/* Check for overflow */
		if (nbytes / sizeof(PyObject *) != (size_t)size ||
		    (nbytes > PY_SSIZE_T_MAX - sizeof(PyTupleObject) - sizeof(PyObject *)))
		{
			return PyErr_NoMemory();
		}
		nbytes += sizeof(PyTupleObject) - sizeof(PyObject *);

nbytes is never used after the overflow check, so the last addition is a waste.

----------
messages: 254367
nosy: Jim Nasby
priority: normal
severity: normal
status: open
title: Useless addition in PyTuple_New
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Mon Nov  9 03:04:43 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Nov 2015 08:04:43 +0000
Subject: [New-bugs-announce] [issue25588] Run test suite from IDLE
 idlelib.run subprocess
Message-ID: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This issue proposes stress testing idlelib.run by running code that already reports whether results are as expected or not -- the test_suite.  Since this one test will take at least as long as the test suite, and will probably need human intervention anyway, it would not be part of test_idle, but would be run separately manually, like htest.

IDLE runs user code in a user process started with subprocess.POpen(executable + 'path/to/idlelib/run.py' + args + user_code_path) (with user_code_path omitted for shell restarts).  When run from the editor, the intent is to imitate 'python -i user_code_path'.

On python list, someone reported that running a program using pyqt5 (and qt5) hung on exit while running with python3 (on Ubuntu, no -i) worked.  I have asked for more details, including whether it works with -i included.  In the meanwhile, I wondered ...

While the run module might not be able to run programs with certain 3rd party imports, can it at least run programs restricted to stdlib imports and well enough behaved to run with python -i.  (A programs that, for instance, disables standard i/o streams would fail both in IDLE and with python.)  A test would be to at least run all stdlib tests, with the same result, as run otherwise on the same system.  The tests should be run in the user process itself and not in additional processes.  They could be run either all in one process or each in a new run process.

If successful, I will put code and instructions in a new idlelib/idle_test/rtest.py/txt.

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 254371
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Run test suite from IDLE idlelib.run subprocess
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/issue25588>
_______________________________________

From report at bugs.python.org  Mon Nov  9 13:30:53 2015
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 09 Nov 2015 18:30:53 +0000
Subject: [New-bugs-announce] [issue25589] test_ascii_formatd fails on Mac
 when built with Intel compiler
Message-ID: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za>


New submission from Chris Hogan:

I successfully built Python on OS X 10.10 with the Intel compiler v15.  However, running the regression tests gives me a "segmentation fault: 11" on test_ascii_formated.  I think this has to do with libffi, because when I build with the --use-system-ffi flag (using a libffi that I built) all the regression tests pass, but I get a seg fault when I try to import ctypes.  Using python's libffi I can import ctypes, but I get seg faults in the tests.  Looking at libffi's homepage, it looks like x86-64 Mac OS X isn't on the list of officially supported platforms.  I tried contacting the libffi-discuss mailing list about this but have received no response in a month.  Please let me know what other information I can provide.

----------
components: Macintosh, Tests
messages: 254398
nosy: christopher.hogan, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_ascii_formatd fails on Mac when built with Intel compiler
type: crash
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Nov  9 17:15:43 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 Nov 2015 22:15:43 +0000
Subject: [New-bugs-announce] [issue25590] tab-completition on instances
 repeatedly accesses attribute/descriptors values
Message-ID: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

Pressing <tab> to invoke autocompletition on instances repeatedly accesses attributes/descriptors values:

>>> # <tab> is used to indicate when/where I press <tab>
>>> class Foo:
...   @property
...   def bar(self): print('Foo.bar called')
... 
>>> f = Foo()
>>> f.<tab>Foo.bar called 
Foo.bar called
Foo.bar called
Foo.bar called
<tab>Foo.bar called
Foo.bar called
Foo.bar called
Foo.bar called
<tab>
f.__class__(         f.__doc__            f.__getattribute__(  f.__le__(            f.__new__(           f.__setattr__(       f.__weakref__
f.__delattr__(       f.__eq__(            f.__gt__(            f.__lt__(            f.__reduce__(        f.__sizeof__(        f.bar
f.__dict__           f.__format__(        f.__hash__(          f.__module__         f.__reduce_ex__(     f.__str__(           
f.__dir__(           f.__ge__(            f.__init__(          f.__ne__(            f.__repr__(          f.__subclasshook__(  
>>> f.b<tab>Foo.bar called
Foo.bar called
Foo.bar called
Foo.bar called
ar<enter>
Foo.bar called

Each time I press <tab>, the property is called 4 times.  I'm not sure why the value is accessed at all, but even if there was a valid reason to do so, doing it once should be enough.

----------
messages: 254415
nosy: ezio.melotti
priority: normal
severity: normal
stage: test needed
status: open
title: tab-completition on instances repeatedly accesses attribute/descriptors values
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov  9 17:16:47 2015
From: report at bugs.python.org (Maciej Szulik)
Date: Mon, 09 Nov 2015 22:16:47 +0000
Subject: [New-bugs-announce] [issue25591] improve test coverage for the
 imaplib
Message-ID: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>


New submission from Maciej Szulik:

Our current imaplib implementation lacks quite a few of tests and the ones present are written in different styles. I'd like to propose rewriting the test case with this new style I've developed during PyCon sprints along with David. Once we'll have the entire test suite in place it'll be safer to introduce any changes I'd like to cover, including updating the implementation to newest RFC 3501 version.

----------
components: email
files: new_imap_tests.diff
hgrepos: 322
keywords: patch
messages: 254417
nosy: barry, maciej.szulik, r.david.murray
priority: normal
severity: normal
status: open
title: improve test coverage for the imaplib
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40991/new_imap_tests.diff

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

From report at bugs.python.org  Tue Nov 10 01:06:12 2015
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 10 Nov 2015 06:06:12 +0000
Subject: [New-bugs-announce] [issue25592] distutils docs: data_files always
 uses sys.prefix
Message-ID: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer:

The documentation for distutils claims that sys.exec_prefix is used in certain cases to install data_files, but this is simply not true (maybe it was true in the past or this sentence was copy/pasted from somewhere else?)

----------
assignee: docs at python
components: Documentation
files: data_files_doc.patch
keywords: patch
messages: 254432
nosy: docs at python, jdemeyer
priority: normal
severity: normal
status: open
title: distutils docs: data_files always uses sys.prefix
versions: Python 2.7
Added file: http://bugs.python.org/file40993/data_files_doc.patch

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

From report at bugs.python.org  Tue Nov 10 02:16:34 2015
From: report at bugs.python.org (Alexander Mohr)
Date: Tue, 10 Nov 2015 07:16:34 +0000
Subject: [New-bugs-announce] [issue25593] _sock_connect_cb can be called
 twice resulting in InvalidStateError
Message-ID: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za>


New submission from Alexander Mohr:

asyncio.selector_events.BaseSelectorEventLoop._sock_connect_cb is a callback based on the selector for a socket. There are certain situations when the selector triggers twice calling this callback twice, resulting in an InvalidStateError when it sets the Future to None.  The way I triggered this was by having several parallel connections to the same host in a multiprocessing script. I suggest analyzing why this callback can be called twice and figuring out what the correct fix is.  I monkey patched it by adding a fut.done() check at the top.  If this information is not enough I can try to provide a sample script. Its currently reproducing in a fairly involved multiprocessing script.

----------
components: asyncio
messages: 254433
nosy: gvanrossum, haypo, thehesiod, yselivanov
priority: normal
severity: normal
status: open
title: _sock_connect_cb can be called twice resulting in InvalidStateError
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov 10 03:27:47 2015
From: report at bugs.python.org (SilentGhost)
Date: Tue, 10 Nov 2015 08:27:47 +0000
Subject: [New-bugs-announce] [issue25594] enum docs outdated re attribute
 access
Message-ID: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>


New submission from SilentGhost:

In enum docs[0], there is a suggestion that the attribute access on members should raise an AttributeError:

>>> Color.red.blue
Traceback (most recent call last):
...
AttributeError: 'Color' object has no attribute 'blue'

which is demonstrably wrong in either 3.5 or 3.6. I presume that's a doc issue and I'd be glad to propose the patch as soon as someone more familiar with the module could confirm that.

[0] https://docs.python.org/3.6/library/enum.html#finer-points

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 254436
nosy: SilentGhost, barry, docs at python, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: enum docs outdated re attribute access
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Nov 10 06:03:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Nov 2015 11:03:12 +0000
Subject: [New-bugs-announce] [issue25595] test_deleted_cwd in test_importlib
 is failed on AIX
Message-ID: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

test_deleted_cwd in test_importlib is failed on AIX.

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4318/steps/test/logs/stdio
======================================================================
ERROR: test_deleted_cwd (test.test_importlib.import_.test_path.Source_FinderTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_importlib/import_/test_path.py", line 169, in test_deleted_cwd
    os.chdir(path)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/tempfile.py", line 807, in __exit__
    self.cleanup()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/tempfile.py", line 811, in cleanup
    _shutil.rmtree(self.name)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/shutil.py", line 478, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/shutil.py", line 476, in rmtree
    os.rmdir(path)
OSError: [Errno 16] Device busy: '/tmp/tmp2xdxtq6x'

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

Proposed patch fixes the test. It also uses more verbose wording to create and remove temporary directory to be sure that caught exception was written by removing the directory, not by creating or changing CWD.

See also issue22834.

----------
components: Tests
files: test_deleted_cwd_aix.patch
keywords: patch
messages: 254438
nosy: David.Edelsohn, brett.cannon, martin.panter, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: test_deleted_cwd in test_importlib is failed on AIX
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40995/test_deleted_cwd_aix.patch

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

From report at bugs.python.org  Tue Nov 10 06:18:07 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Nov 2015 11:18:07 +0000
Subject: [New-bugs-announce] [issue25596] regular files handled as
 directories in the glob module
Message-ID: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The glob module happily joins names of regular files together with os.path.join() or attempts to list the files contained into a regular file (sic). The same 'except os.error' statement is used to handle both these cases and the case of a non readable directory.

The attached patch makes the code more correct and easier to understand.

----------
components: Library (Lib)
files: glob_isdir.patch
keywords: patch
messages: 254440
nosy: xdegaye
priority: normal
severity: normal
status: open
title: regular files handled as directories in the glob module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40996/glob_isdir.patch

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

From report at bugs.python.org  Tue Nov 10 12:02:38 2015
From: report at bugs.python.org (Darragh Bailey)
Date: Tue, 10 Nov 2015 17:02:38 +0000
Subject: [New-bugs-announce] [issue25597] unittest.mock does not wrap dict
 objects correctly
Message-ID: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>


New submission from Darragh Bailey:

Both unittest.mock and the backported release for earlier pythons don't appear to support mocking of dictionary objects.

Specifically I'm expecting that any of the methods used to test for membership, or get items from a mock object wrapping a dictionary should succeed. However it appears that MagicMock doesn't appear to support this.

Attached file shows an attempt to use different methods with a wrapped dictionary object where only the '.get()' method appears to work as expected.

----------
files: test-mock-wraps-dict.py
messages: 254453
nosy: Darragh Bailey
priority: normal
severity: normal
status: open
title: unittest.mock does not wrap dict objects correctly
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41001/test-mock-wraps-dict.py

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

From report at bugs.python.org  Tue Nov 10 12:02:55 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 10 Nov 2015 17:02:55 +0000
Subject: [New-bugs-announce] [issue25598] Fix memory_hex (#9951) for
 non-contiguous buffers
Message-ID: <1447174975.72.0.408489689517.issue25598@psf.upfronthosting.co.za>


New submission from Stefan Krah:

memory_hex from #9951 fails for non-contiguous buffers.

----------
assignee: skrah
files: memhex.diff
keywords: patch
messages: 254454
nosy: skrah
priority: normal
severity: normal
status: open
title: Fix memory_hex (#9951) for non-contiguous buffers
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41002/memhex.diff

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

From report at bugs.python.org  Tue Nov 10 12:26:22 2015
From: report at bugs.python.org (Theron Luhn)
Date: Tue, 10 Nov 2015 17:26:22 +0000
Subject: [New-bugs-announce] [issue25599] asyncio.iscoroutinefunction
 returns unexpected results when presented with unittest.mock.Mock
Message-ID: <1447176382.09.0.498269327302.issue25599@psf.upfronthosting.co.za>


New submission from Theron Luhn:

>>> asyncio.iscoroutinefunction(unittest.mock.Mock())
<Mock name='mock._is_coroutine' id='4544068072'>

This is an unexpected response, both in type (Mock rather than boolean) and value (truthy).

inspect.iscoroutinefunction behaves as expected.

Workaround:

>>> m = unittest.mock.Mock()
>>> m._is_coroutine = False
>>> asyncio.iscoroutinefunction(m)
False

----------
components: asyncio
messages: 254457
nosy: Theron Luhn, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock
type: behavior
versions: 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/issue25599>
_______________________________________

From report at bugs.python.org  Wed Nov 11 02:30:12 2015
From: report at bugs.python.org (mcer45)
Date: Wed, 11 Nov 2015 07:30:12 +0000
Subject: [New-bugs-announce] [issue25600] argparse,
 argument_default=argparse.SUPPRESS seems to have no effect
Message-ID: <1447227012.01.0.302996872959.issue25600@psf.upfronthosting.co.za>


New submission from mcer45:

The parameter argument_default=argparse.SUPPRESS seems to have no effect.
Example:

=====================================================================

help_dirs='ahoy

parser = argparse.ArgumentParser(
           formatter_class=argparse.RawDescriptionHelpFormatter,
           description='Makes the calendar for the "year"',
           epilog=textwrap.dedent(help_dirs))
parser.add_argument("user",  help='the user directory with the required
structure in ./')
parser.add_argument("year",  type=int,  help='the year for this calendar
and also the directory for the output')
parser.add_argument("-acc","--acc",
default='no',nargs='?',choices=['yes','no'],const='yes',
                                    help='accomodate ratio according to the
cover photo, default=no')
parser.add_argument("--color",default='gold', choices=['gold'],
help='default color: gold')
args = parser.parse_args(['mc', '2015'])
print(args)
del parser
del args



parser = argparse.ArgumentParser(argument_default=argparse.SUPPRESS,
           formatter_class=argparse.RawDescriptionHelpFormatter,
           description='Makes the calendar for the "year"',
           epilog=textwrap.dedent(help_dirs))
parser.add_argument("user",  help='the user directory with the required
structure in ./')
parser.add_argument("year",  type=int,  help='the year for this calendar
and also the directory for the output')
parser.add_argument("-acc","--acc",
default='no',nargs='?',choices=['yes','no'],const='yes',
                                    help='accomodate ratio according to the
cover photo, default=no')
parser.add_argument("--color",default='gold', choices=['gold'],
help='default color: gold')
args = parser.parse_args(['mc', '2015'])


===================================

The results in both cases are the  same:
Namespace(acc='no', color='gold', user='mc', year=2015)

I hoped the defaults will be suppressed.

----------
components: Library (Lib)
messages: 254478
nosy: bethard, mcer45
priority: normal
severity: normal
status: open
title: argparse, argument_default=argparse.SUPPRESS seems to have no effect
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Nov 11 03:31:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Nov 2015 08:31:35 +0000
Subject: [New-bugs-announce] [issue25601] test_cpickle failure on the
 ware-gentoo-x86 builbot
Message-ID: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%202.7/builds/100/steps/test/logs/stdio

There are a lot of failures, all look as:
======================================================================
ERROR: test_simple_newobj (test.test_cpickle.FileIOCPicklerFastTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/2.7.ware-gentoo-x86/build/Lib/test/pickletester.py", line 1145, in test_simple_newobj
    s = self.dumps(x, proto)
  File "/buildbot/buildarea/2.7.ware-gentoo-x86/build/Lib/test/test_cpickle.py", line 141, in dumps
    p.dump(arg)
AttributeError: 'module' object has no attribute '_reduce_ex'

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

It looks as the _reduce_ex() function is missed in the copy_reg module. Have no ideas how it is possible.

----------
messages: 254483
nosy: serhiy.storchaka, zach.ware
priority: normal
severity: normal
status: open
title: test_cpickle failure on the ware-gentoo-x86 builbot

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

From report at bugs.python.org  Wed Nov 11 06:46:08 2015
From: report at bugs.python.org (Jakub Klama)
Date: Wed, 11 Nov 2015 11:46:08 +0000
Subject: [New-bugs-announce] [issue25602] Add support for EVFILT_USER kqueue
 filter
Message-ID: <1447242368.46.0.687277732517.issue25602@psf.upfronthosting.co.za>


New submission from Jakub Klama:

It's useful for doing signaling between threads (especially I/O-bound threads).

Related github pull request: https://github.com/python/cpython/pull/23

----------
components: Library (Lib)
files: 0001-Add-support-for-EVFILT_USER-kqueue-filter.patch
keywords: patch
messages: 254485
nosy: jceel
priority: normal
severity: normal
status: open
title: Add support for EVFILT_USER kqueue filter
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41014/0001-Add-support-for-EVFILT_USER-kqueue-filter.patch

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

From report at bugs.python.org  Wed Nov 11 21:52:55 2015
From: report at bugs.python.org (Matthias welp)
Date: Thu, 12 Nov 2015 02:52:55 +0000
Subject: [New-bugs-announce] [issue25603] spelling mistake - 26.1 typing
Message-ID: <1447296775.39.0.293549670767.issue25603@psf.upfronthosting.co.za>


New submission from Matthias welp:

Almost at the end of the page, under Usage of Typing.NamedTuple(...), this code snippet occurs: `Employee = typing.NamedTuple('Employee', [('name', str), 'id', int)])`. Unfortunately, this has an error in its parenthesis. 

This can easily be fixed by adding an opening bracket before the `'id'`-part, as seen here: `Employee = typing.NamedTuple('Employee', [('name', str), ('id', int)])`.

----------
assignee: docs at python
components: Documentation
messages: 254511
nosy: Matthias welp, docs at python
priority: normal
severity: normal
status: open
title: spelling mistake - 26.1 typing
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 12 03:44:45 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 12 Nov 2015 08:44:45 +0000
Subject: [New-bugs-announce] [issue25604] [Minor] bug in integer true
 division algorithm
Message-ID: <1447317885.13.0.151238733995.issue25604@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

There's a harmless but annoying (for code readers) bug in the code for true division of (long) integers.  In `long_true_divide` in `Objects/longobject.c`, we have the following code for manipulating the bits of a 55- or 56-bit long to get something that will be exactly representable as a float:

    /* The number of extra bits that have to be rounded away. */
    extra_bits = MAX(x_bits, DBL_MIN_EXP - shift) - DBL_MANT_DIG;
    assert(extra_bits == 2 || extra_bits == 3);

    /* Round by directly modifying the low digit of x. */
    mask = (digit)1 << (extra_bits - 1);
    low = x->ob_digit[0] | inexact;
    if (low & mask && low & (3*mask-1))
        low += mask;
    x->ob_digit[0] = low & ~(mask-1U);

    /* Convert x to a double dx; the conversion is exact. */
    [...]

The last code line above is supposed to be masking out all the bits that we don't want to keep. Instead, it's masking out all but one of those bits.  The line

    x->ob_digit[0] = low & ~(mask-1U);

should be replaced with

    x->ob_digit[0] = low & ~(2*mask-1U);

As it stands, the comment about the conversion to double being exact is false. (I've verified this by converting x both to a 64-bit unsigned integer and to a double and checking that the integer and double don't always match in value; with the fix above, they do.)

I don't *think* this bug actually affects the output on any platform whose arithmetic and ldexp functions do correct rounding with round-ties-to-even: the extra bit will always get rounded away (in the correct direction) by either the conversion to float (for the non-subnormal case) or by the ldexp operation (for the subnormal case). Still, the bug makes the code a bit more susceptible to platform arithmetic quirks.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 254523
nosy: mark.dickinson
priority: low
severity: normal
status: open
title: [Minor] bug in integer true division algorithm
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Nov 12 04:29:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Nov 2015 09:29:02 +0000
Subject: [New-bugs-announce] [issue25605] fcntl doc: document exceptions
 raised on error for ioctl() and flock()
Message-ID: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch documents the exception raised when ioctl() or flock() functions fail.

Note: flock() can also raises a ValueError if the second parameter (op) is unknown.

If the patch is approved, I will write a similar patch for Python 3 (just replace IOError with OSError in Python 3 doc).

Python 2 online doc:
https://docs.python.org/2/library/fcntl.html

Python 3 online doc:
https://docs.python.org/dev/library/fcntl.html

----------
assignee: docs at python
components: Documentation
files: fcntl_doc.patch
keywords: patch
messages: 254524
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: fcntl doc: document exceptions raised on error for ioctl() and flock()
versions: Python 2.7
Added file: http://bugs.python.org/file41020/fcntl_doc.patch

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

From report at bugs.python.org  Thu Nov 12 04:55:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Nov 2015 09:55:28 +0000
Subject: [New-bugs-announce] [issue25606] asyncio doc: 'socket' transport
 extra info is not mandatory
Message-ID: <1447322128.43.0.475707567423.issue25606@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Not all implementations of asyncio event loops can provide the "socket" transport extra info. See for example this discussion on libuv:
https://github.com/python/asyncio/issues/286

The information should be marked as "optional", or at least we should document that it can miss depending on the event loop.

I guess that other info should be marked as optional.

----------
components: asyncio
messages: 254527
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio doc: 'socket' transport extra info is not mandatory
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Nov 12 07:34:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Nov 2015 12:34:45 +0000
Subject: [New-bugs-announce] [issue25607] test_distutils provokes unexpected
 output in test_shutil
Message-ID: <1447331685.01.0.00514668944728.issue25607@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

test_distutils changes global logging level for distutils. This affects test_shutil.

In Python 2.7:

$ ./python -m test.regrtest test_distutils test_shutil
[1/2] test_distutils
[2/2] test_shutil
test test_shutil produced unexpected output:
**********************************************************************
zip -q -r archive2.zip dist

**********************************************************************
1 test OK.
1 test failed:
    test_shutil

Python 3 testing is more lenient, but produces unexpected output too.

The global logging level is changed in Distribution.parse_command_line() by calling log.set_verbosity().

Proposed patch restores the value of the global logging level in tests that change it.

----------
components: Distutils, Tests
files: test_distutils_restore_log_level.patch
keywords: patch
messages: 254529
nosy: dstufft, eric.araujo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: test_distutils provokes unexpected output in test_shutil
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41021/test_distutils_restore_log_level.patch

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

From report at bugs.python.org  Thu Nov 12 14:11:15 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 12 Nov 2015 19:11:15 +0000
Subject: [New-bugs-announce] [issue25608] ascynio readexactly() should raise
 ValueError if passed length <= 0 in argument
Message-ID: <1447355475.79.0.931064144901.issue25608@psf.upfronthosting.co.za>


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

ascynio readexactly() should raise ValueError if passed length <= 0 in argument.

Now, it return empty string, which is just error hiding. Why not to raise ValueError ? 

Returning empty string is error prone. This behaviour was not changed since initial commit of asyncio, so probably was not done intentionally.

----------
components: asyncio
messages: 254545
nosy: gvanrossum, haypo, mmarkk, yselivanov
priority: normal
severity: normal
status: open
title: ascynio readexactly() should raise ValueError if passed length <= 0 in argument
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 12 14:14:39 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Nov 2015 19:14:39 +0000
Subject: [New-bugs-announce] [issue25609] Add a ContextManager ABC and type
Message-ID: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There should probably be a context manager ABC in collections.abc that requires __enter__/__exit__ and a matching entry in `typing` that also takes a type argument of what the __enter__ method returns.

----------
components: Library (Lib)
keywords: easy
messages: 254546
nosy: brett.cannon, gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a ContextManager ABC and type
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 12 14:16:08 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Nov 2015 19:16:08 +0000
Subject: [New-bugs-announce] [issue25610] Add typing.Awaitable
Message-ID: <1447355768.55.0.0781055266737.issue25610@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Probably should have a subclass of Callable in `typing` for Awaitable functions (there is already a corollary object in collections.abc).

----------
components: asyncio
messages: 254547
nosy: brett.cannon, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Add typing.Awaitable
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 12 14:37:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Nov 2015 19:37:35 +0000
Subject: [New-bugs-announce] [issue25611] test_deque failure on Gentu and
 OpenIndiana buildbots on 2.7
Message-ID: <1447357055.57.0.0198756025718.issue25611@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

http://buildbot.python.org/all/builders/x86%20OpenIndiana%202.7/builds/3104/steps/test/logs/stdio
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%202.7/builds/107/steps/test/logs/stdio
======================================================================
FAIL: test_basics (test.test_deque.TestBasic)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/2.7.ware-gentoo-x86/build/Lib/test/test_deque.py", line 38, in test_basics
    self.assertEqual(list(d), range(-200, 400))
AssertionError: Lists differ: [-200, -199, -198, -197, -196,... != [-200, -199, -198, -197, -196,...

First differing element 200:
-5125
0

First list contains 125 additional elements.
First extra element 600:
275

Diff is 6032 characters long. Set self.maxDiff to None to see it.

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

On other buildbots the test is passed, and I can't reproduce the failure locally.

----------
components: Extension Modules
messages: 254548
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_deque failure on Gentu and OpenIndiana buildbots on 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 12 15:59:19 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 12 Nov 2015 20:59:19 +0000
Subject: [New-bugs-announce] [issue25612] nested try..excepts don't work
 correctly for generators
Message-ID: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Nested try..except statements with yields can loose reference to the current exception.

The following code:

    class MainError(Exception):
        pass

    class SubError(Exception):
        pass

    def main():
        try:
            raise MainError()
        except MainError:
            try:
                yield
            except SubError:
                print('got SubError')
            raise

    coro = main()
    coro.send(None)
    coro.throw(SubError())

prints:

    got SubError
    Traceback (most recent call last):
      File "t.py", line 19, in <module>
        coro.throw(SubError())
      File "t.py", line 15, in main
        raise
    RuntimeError: No active exception to reraise

----------
components: Interpreter Core
messages: 254557
nosy: benjamin.peterson, gvanrossum, haypo, larry, ncoghlan, yselivanov
priority: release blocker
severity: normal
status: open
title: nested try..excepts don't work correctly for generators
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Nov 12 18:27:16 2015
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 12 Nov 2015 23:27:16 +0000
Subject: [New-bugs-announce] [issue25613] fix ssl tests with sslv3 disabled
Message-ID: <1447370836.15.0.704598456658.issue25613@psf.upfronthosting.co.za>


New submission from Matthias Klose:

Linux distributions (now starting with the Ubuntu development version for 16.04 LTS) are starting to disable SSLv3, letting at least two test_ssl tests fail.

a partial fix is mentioned in https://launchpad.net/bugs/1515793

----------
messages: 254573
nosy: doko
priority: normal
severity: normal
status: open
title: fix ssl tests with sslv3 disabled
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Nov 12 18:41:20 2015
From: report at bugs.python.org (Yclept Nemo)
Date: Thu, 12 Nov 2015 23:41:20 +0000
Subject: [New-bugs-announce] [issue25614] Lib/code.py:
 InteractiveConsole.raw_input writes prompt to stdout
Message-ID: <1447371680.73.0.599273963393.issue25614@psf.upfronthosting.co.za>


New submission from Yclept Nemo:

Just like InteractiveInterpreter.write and the actual python interpreter, the console's prompt should be written to stderr. Something like:

self.write(prompt)
return input()

----------
components: Library (Lib)
messages: 254575
nosy: Yclept.Nemo
priority: normal
severity: normal
status: open
title: Lib/code.py: InteractiveConsole.raw_input writes prompt to stdout
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 13 05:26:21 2015
From: report at bugs.python.org (Dave Jones)
Date: Fri, 13 Nov 2015 10:26:21 +0000
Subject: [New-bugs-announce] [issue25615] Document unsorted behaviour of
 glob.glob
Message-ID: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>


New submission from Dave Jones:

As suggested in issue 21748, this is a minor documentation change to make explicitly clear that glob.glob returns unsorted results (on the basis that the existing specification references shell behaviour which is always sorted).

----------
assignee: docs at python
components: Documentation
files: glob-spec-unsorted.patch
keywords: patch
messages: 254597
nosy: Dave Jones, docs at python
priority: normal
severity: normal
status: open
title: Document unsorted behaviour of glob.glob
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file41029/glob-spec-unsorted.patch

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

From report at bugs.python.org  Fri Nov 13 08:01:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Nov 2015 13:01:21 +0000
Subject: [New-bugs-announce] [issue25616] Extract OrderedDict tests into
 separate file
Message-ID: <1447419681.57.0.354121086978.issue25616@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

OrderedDict tests now are about 1/3 of test_collections, and I think their volume will grow. I suggest to extract these tests into separate file test_ordereddict. There are precedences: test_deque (deque also is implemented in C), and test_userdict, test_userlist and test_userstring (for historical reasons).

The main reason to me is the possibility to run quick OrderedDict tests (and only OrderedDict tests).

----------
components: Tests
messages: 254602
nosy: eric.snow, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Extract OrderedDict tests into separate file
type: enhancement

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

From report at bugs.python.org  Fri Nov 13 09:52:02 2015
From: report at bugs.python.org (Koustav Pal)
Date: Fri, 13 Nov 2015 14:52:02 +0000
Subject: [New-bugs-announce] [issue25617] Installing local installation of
 Python
Message-ID: <1447426322.89.0.546978633067.issue25617@psf.upfronthosting.co.za>


New submission from Koustav Pal:

The inherent behaviour of python installations (local or global) is such that it expects to source system wide modules from the global python installation. 

There is no non hacky way to solve this problem.

The idea of local installations is that they should be independent of system-wide builds. Python's behaviour contradicts this condition.

In cases where users on clusters need to maintain their own python installations such that these installations are independent of uncontrollable cluster variables, python will break on a regular basis as it tries to import modules from the system wide sources which were compiled on a similar python version but with different parameters.

Why was this express decision made to include this path in the python development tree? 

How can this be resolved without hacking site.py?

----------
components: Installation
messages: 254606
nosy: koustavpal88
priority: normal
severity: normal
status: open
title: Installing local installation of Python
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 13 13:03:11 2015
From: report at bugs.python.org (mrudula)
Date: Fri, 13 Nov 2015 18:03:11 +0000
Subject: [New-bugs-announce] [issue25618] gdk attribute error
Message-ID: <1447437791.6.0.752022160668.issue25618@psf.upfronthosting.co.za>


New submission from mrudula:

I am porting application from python 2 to python 3. Unable to import rati modules and local modules.

gdk is not getting imported and unable to access many module.
AttributeError: 'gi.repository.Gtk' object has no attribute 'gdk'

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 254608
nosy: mrudula
priority: normal
severity: normal
status: open
title: gdk attribute error
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 13 14:08:03 2015
From: report at bugs.python.org (terry)
Date: Fri, 13 Nov 2015 19:08:03 +0000
Subject: [New-bugs-announce] [issue25619] Exception AttributeError:
 "'NoneType'.... thrown on exit
Message-ID: <1447441683.08.0.711928345113.issue25619@psf.upfronthosting.co.za>


New submission from terry:

The attached code generates this output:

init called
finished init
init called
finished init
init called
finished init
initPorts done
alldone
destroying /sys/class/gpio/gpio16/
destroying /sys/class/gpio/gpio6/
Exception AttributeError: "'NoneType' object has no attribute 'path'" in <bound method sysfsGpio.__del__ of <__main__.sysfsGpio instance at 0xb6c90e68>> ignored
destroying /sys/class/gpio/gpio13/
Exception AttributeError: "'NoneType' object has no attribute 'path'" in <bound method sysfsGpio.__del__ of <__main__.sysfsGpio instance at 0xb6c90e40>> ignored

It is necessary to have two functions defined (railVarRes() and batleveltopct()) and further more changing the name of railVarRes to arailVarRes changes the behavior:


init called
finished init
init called
finished init
init called
finished init
initPorts done
alldone
destroying /sys/class/gpio/gpio16/
destroying /sys/class/gpio/gpio13/
destroying /sys/class/gpio/gpio6/
Exception AttributeError: "'NoneType' object has no attribute 'path'" in <bound method sysfsGpio.__del__ of <__main__.sysfsGpio instance at 0xb6c10e68>> ignored


notice that the order of the class destruction has changed.

----------
files: bug.py
messages: 254612
nosy: Terry Garyet
priority: normal
severity: normal
status: open
title: Exception AttributeError: "'NoneType'....  thrown on exit
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41032/bug.py

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

From report at bugs.python.org  Fri Nov 13 14:16:42 2015
From: report at bugs.python.org (Marios Kourtesis)
Date: Fri, 13 Nov 2015 19:16:42 +0000
Subject: [New-bugs-announce] [issue25620] Bytes Issue
Message-ID: <1447442202.29.0.169880559008.issue25620@psf.upfronthosting.co.za>


New submission from Marios Kourtesis:

Hello,

Executing the following code in a Python2 interpreter the result is True while running the same code in Python3 is False. I tested this in Python version 2.7.10 and 3.4.2.

a = b'a'
b = b'b'
c = a+b
c[1] == b'b'

When I call type(c[1]) in Python2 I get str:

type(c[1])
<type 'str'>

While in Python3 I get int:
type(c[1])
<class 'int'>

Is this the expected behavior?

----------
components: Interpreter Core
messages: 254613
nosy: Marios Kourtesis
priority: normal
severity: normal
status: open
title: Bytes Issue
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 13 15:30:48 2015
From: report at bugs.python.org (Maxime Chambreuil)
Date: Fri, 13 Nov 2015 20:30:48 +0000
Subject: [New-bugs-announce] [issue25621] ast.literal_eval() fails on
 docstrings
Message-ID: <1447446648.4.0.141417536435.issue25621@psf.upfronthosting.co.za>


New submission from Maxime Chambreuil:

ast.literal_eval fails when there is docstrings in the file.

I used the file attached and this code in our CI server:

def is_installable_module(path):
    """return False if the path doesn't contain an installable odoo module,
    and the full path to the module manifest otherwise"""
    manifest_path = is_module(path)
    if manifest_path:
        manifest = ast.literal_eval(open(manifest_path).read())
        if manifest.get('installable', True):
            return manifest_path
    return False

I get the following error message:
Traceback (most recent call last):

  File "/home/travis/maintainer-quality-tools/travis/test_flake8", line 14, in <module>

    for addon in get_modules(os.path.abspath('.')):

  File "/home/travis/maintainer-quality-tools/travis/getaddons.py", line 53, in get_modules

    if is_installable_module(os.path.join(path, x))]

  File "/home/travis/maintainer-quality-tools/travis/getaddons.py", line 38, in is_installable_module

    manifest = ast.literal_eval(open(manifest_path).read())

  File "/usr/lib/python2.7/ast.py", line 49, in literal_eval

    node_or_string = parse(node_or_string, mode='eval')

  File "/usr/lib/python2.7/ast.py", line 37, in parse

    return compile(source, filename, mode, PyCF_ONLY_AST)

  File "<unknown>", line 22

    {

    ^

SyntaxError: invalid syntax


https://github.com/OCA/knowledge/pull/75
https://github.com/OCA/maintainer-quality-tools/blob/master/travis/getaddons.py#L33
https://travis-ci.org/OCA/knowledge/jobs/90332842

----------
components: Interpreter Core
files: __openerp__.py
messages: 254619
nosy: Maxime Chambreuil
priority: normal
severity: normal
status: open
title: ast.literal_eval() fails on docstrings
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41033/__openerp__.py

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

From report at bugs.python.org  Fri Nov 13 16:28:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Nov 2015 21:28:54 +0000
Subject: [New-bugs-announce] [issue25622] Enable
 ctypes.test.test_values.Win_ValuesTestCase for non-Windows
Message-ID: <1447450134.96.0.43104915369.issue25622@psf.upfronthosting.co.za>


New submission from Martin Panter:

In /Lib/ctypes/test/test_values.py, three out of the five test cases are only run on Windows. There is a comment saying ?This test only works when python itself is a dll/shared library?, and the tests run fine on Linux. So I propose to remove the Windows-only restriction, and rename the class from Win_ValuesTestCase to PythonValuesTestCase.

The immediate benefit for me is that I can see on Linux when I need to update one of those tests before I break a Windows builtbot :)

This test used to be completely disabled (probably by accident), and was enabled for Windows only in revision 6f63fff5c120. There was a comment <https://bugs.python.org/issue19493#msg206649> by Zach wondering if it shouldn?t be Windows-specific.

----------
components: Tests, ctypes
files: python-values.patch
keywords: patch
messages: 254623
nosy: martin.panter, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Enable ctypes.test.test_values.Win_ValuesTestCase for non-Windows
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41034/python-values.patch

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

From report at bugs.python.org  Sat Nov 14 03:12:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Nov 2015 08:12:48 +0000
Subject: [New-bugs-announce] [issue25623] Keep the link to Python
 implementation of OrderedDict
Message-ID: <1447488768.43.0.519685796607.issue25623@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now C implementation of OrderedDict totally overrides Python implementation.

>>> import collections
>>> collections.OrderedDict.__init__
<slot wrapper '__init__' of 'collections.OrderedDict' objects>                                                                

The only way to get Python implementation of OrderedDict is to block the _collections module and reload the collections module.

>>> del sys.modules['collections']
>>> del sys.modules['collections.abc']
>>> sys.modules['_collections'] = None
>>> import collections
>>> collections.OrderedDict.__init__
<function OrderedDict.__init__ at 0xb6f6da4c>

But this also blocks collections.deque, collections.defaultdict, and the acceleration of collections.Counter.

As long as C implementation of OrderedDict still has some bugs (and I'm not sure we will have fixed all them before releasing 3.5.1), I think it would be good to have a workaround for applications that encounter one of still not fixed bugs.

I propose to keep a reference to Python implementation as collections._OrderedDict. This is not a public interface and we don't promise existing this name in future releases. This is just a way to make a workaround for the time while C implementation is not stable enough. I hope we will got rid from it in 3.7.

A workaround for an application that suffers from OrderedDict bug:

import collections
try:
    collections.OrderedDict = collections._OrderedDict
except AttributeError:
    pass

----------
components: Library (Lib)
files: OrderedDict_python_impl.patch
keywords: patch
messages: 254645
nosy: eric.snow, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Keep the link to Python implementation of OrderedDict
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41038/OrderedDict_python_impl.patch

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

From report at bugs.python.org  Sat Nov 14 04:25:24 2015
From: report at bugs.python.org (Dingyuan Wang)
Date: Sat, 14 Nov 2015 09:25:24 +0000
Subject: [New-bugs-announce] [issue25624] shutil.make_archive makes invalid
 directory entries
Message-ID: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za>


New submission from Dingyuan Wang:

The _make_zipfile in shutil uses ZIP_DEFLATED compression by default, and the fix introduced by #24982 adds directory entries. In zipfile.ZipFile.write, directories is added as 0 file_size, 0 compress_size, regardless of the compression method. Deflate will compress an empty string as \x03\x00, thus the directory entries become incorrect.

The command line interface of zipfile is correct. Shutil can be fixed as zipfile.main. As a directory entry with compression methods other than ZIP_STORED is meaningless, zipfile.write and (maybe) zipfile.writestr should always write a ZIP_STORED header for directory entries to avoid the above problem occuring by programming mistakes.

----------
components: Library (Lib)
messages: 254647
nosy: gumblex
priority: normal
severity: normal
status: open
title: shutil.make_archive makes invalid directory entries
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov 14 12:45:43 2015
From: report at bugs.python.org (=?utf-8?b?SsOhY2h5bSBCYXJ2w61uZWs=?=)
Date: Sat, 14 Nov 2015 17:45:43 +0000
Subject: [New-bugs-announce] [issue25625] "chdir" Contex manager for pathlib
Message-ID: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za>


New submission from J?chym Barv?nek:

I use this context manager in my code:

@contextmanager
def in_directory(path):
    pwd = str(Path().absolute())
    if not path.is_dir():
        path = path.parent
    os.chdir(str(path))
    yield path.absolute()
    os.chdir(pwd)

I thought it would be nice to have something like this in the pathlib as a method of Path library, I find it quite convenient, especially when dealing with subprocesses.

----------
components: Library (Lib)
messages: 254664
nosy: J?chym Barv?nek
priority: normal
severity: normal
status: open
title: "chdir" Contex manager for pathlib
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov 14 14:48:21 2015
From: report at bugs.python.org (Ben Cipollini)
Date: Sat, 14 Nov 2015 19:48:21 +0000
Subject: [New-bugs-announce] [issue25626] Gzip fails for file over 2**32
 bytes
Message-ID: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za>


New submission from Ben Cipollini:

Gzip fails when opening a file more than 2**32 bytes. This is a new issue in Python 3.5.

We hit this opening large neuroimaging files from the Human Connectome Project. See https://github.com/nipy/nibabel/issues/362 for more details.

When size is > 2**32, we get the following error on Python 3.5:

/usr/lib/python3.5/gzip.py in read(self, size)
    467             buf = self._fp.read(io.DEFAULT_BUFFER_SIZE)
    468 
--> 469             uncompress = self._decompressor.decompress(buf, size)
    470             if self._decompressor.unconsumed_tail != b"":
    471                 self._fp.prepend(self._decompressor.unconsumed_tail)

OverflowError: Python int too large for C unsigned int

----------
messages: 254668
nosy: Ben Cipollini
priority: normal
severity: normal
status: open
title: Gzip fails for file over 2**32 bytes
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov 14 16:13:32 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Sat, 14 Nov 2015 21:13:32 +0000
Subject: [New-bugs-announce] [issue25627] distutils : file "bdist_rpm.py"
 allows Shell injection in "name
Message-ID: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za>


New submission from Bernd Dietzel:

https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1514183

File :
/usr/lib/python2.7/distutils/command/bdist_rpm.py

Line 358 :
This line in the code uses the depreached os.popen command, should be replaced with subprocess.Popen() :

out = os.popen(q_cmd)

Exploit demo :
============
1) Download the setup.py script witch i attached
2) Create a test folder an put the setup.py script in this folder
3) cd to the test folder
4) python setup.py bdist_rpm
5) A xmessage window pops up as a proof of concept

----------
components: Distutils
files: setup.py
messages: 254670
nosy: TheRegRunner, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils : file "bdist_rpm.py" allows Shell injection in "name
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file41043/setup.py

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

From report at bugs.python.org  Sun Nov 15 14:21:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Nov 2015 19:21:13 +0000
Subject: [New-bugs-announce] [issue25628] Make namedtuple "verbose" and
 "renanme" parameters into keyword only arguments
Message-ID: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

This is a usability and readability improvement made possible by Python 3's keyword only arguments.

Usability is improved by getting a much less confusing response from the following mistake:

    namedtuple('Point', 'x', 'y')
                              ^--- invisibly goes to the "verbose" argument 

The "verbose" argument is normally used interactively (much like help() and dis()) or is used with a keyword argument, so it is unlikely that existing scripts will be much affected.  For the rare cases, the remediation is simple and improves code clarity (replacing "True" with "verbose=True").

----------
components: Library (Lib)
files: namedtuple_keywords.diff
keywords: patch
messages: 254689
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make namedtuple "verbose" and "renanme" parameters into keyword only arguments
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41049/namedtuple_keywords.diff

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

From report at bugs.python.org  Sun Nov 15 15:17:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Nov 2015 20:17:47 +0000
Subject: [New-bugs-announce] [issue25629] Move set fill/used updates out of
 set_insert_clean()
Message-ID: <1447618667.35.0.632647105996.issue25629@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Will need to update the comment block over set_insert_clean() as well.

----------
components: Interpreter Core
files: set_faster_resize2.diff
keywords: patch
messages: 254692
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Move set fill/used updates out of set_insert_clean()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41050/set_faster_resize2.diff

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

From report at bugs.python.org  Sun Nov 15 18:22:18 2015
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Krawczyk?=)
Date: Sun, 15 Nov 2015 23:22:18 +0000
Subject: [New-bugs-announce] [issue25630] SIGSEGV in os.putenv()
Message-ID: <1447629738.32.0.300278557124.issue25630@psf.upfronthosting.co.za>


New submission from Pawe? Krawczyk:

A numerical value argument of the os.putenv() call causes my python3.5 to crash with SIGSEGV, for example:

Python 3.5.0+ (default, Oct 11 2015, 09:05:38) 
[GCC 5.2.1 20151010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.putenv('AAA', 1)
Segmentation fault (core dumped)

While numerical 1 (one) is not a valid argument for the function which expects a string as value, it shouldn't crash but rather throw an exception. This seems to be the behaviour in python3.4:

Python 3.4.3 (default, Oct 14 2015, 20:28:29) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.putenv('AAA', 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly
>>>

I can provide a strace/ltrace/core dump but it's huge and I'm not sure if it's necessary taking into account that this issue is trivial to reproduce.

----------
components: Library (Lib)
messages: 254700
nosy: Pawe? Krawczyk
priority: normal
severity: normal
status: open
title: SIGSEGV in os.putenv()
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Nov 15 20:06:05 2015
From: report at bugs.python.org (Itai Bar-Natan)
Date: Mon, 16 Nov 2015 01:06:05 +0000
Subject: [New-bugs-announce] [issue25631] Segmentation fault with invalid
 Unicode command-line arguments in embedded Python
Message-ID: <1447635965.36.0.72529883046.issue25631@psf.upfronthosting.co.za>


New submission from Itai Bar-Natan:

The following embedded application, which calls Py_Main with a "-W X" argument where X is not a valid Unicode string, returns a segmentation fault:

```
#include "Python.h"

main() {
    wchar_t *invalid_str;
    invalid_str = malloc(2*sizeof(wchar_t));
    invalid_str[0] = 0x110000;
    invalid_str[1] = 0;
    wchar_t *argv[4] = {L"embedded-python", L"-W", invalid_str, NULL};

    Py_Main(3, argv);
}
```

This segmentation fault is present in Python 3.4, 3.5, and the latest development branch I downloaded, but is not present in Python 3.2. This program is obviously invalid and it may be reasonable to emit a fatal error in this situation, but it should not give a segmentation fault.

I believe the issue is that this codes leads to exception being thrown before exceptions are initialized, and more specifically, a call to PyExceptionClass_Check() within PyErr_Object() reads a NULL pointer. I haven't tested this but I expect that this problem would not appear when calling Python directly since Python sanitizes the command line arguments from main(). Nonetheless even here the possibility of other exceptions being raised early in the initialization sequence remains a potential problem.

----------
components: Interpreter Core
messages: 254703
nosy: itaibn
priority: normal
severity: normal
status: open
title: Segmentation fault with invalid Unicode command-line arguments in embedded Python
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov 16 01:12:17 2015
From: report at bugs.python.org (Antony Lee)
Date: Mon, 16 Nov 2015 06:12:17 +0000
Subject: [New-bugs-announce] [issue25632] Document BUILD_*_UNPACK opcodes
Message-ID: <1447654337.27.0.0979674663638.issue25632@psf.upfronthosting.co.za>


New submission from Antony Lee:

The additional unpack generalizations provided by Python3.5 rely on a new set of opcodes, BUILD_{TUPLE,LIST,DICT,SET}_UNPACK, that are not documented in the docs for the dis module.

----------
assignee: docs at python
components: Documentation
messages: 254715
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Document BUILD_*_UNPACK opcodes
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov 16 03:42:51 2015
From: report at bugs.python.org (jon orebro)
Date: Mon, 16 Nov 2015 08:42:51 +0000
Subject: [New-bugs-announce] [issue25633] The documentation for
 urllib.request should mention http.client.HTTPException
Message-ID: <1447663371.73.0.839165836135.issue25633@psf.upfronthosting.co.za>


New submission from jon orebro:

The documentation for urllib.request should mention that a robust client using urllib.request must be prepared for exceptions of type http.client.HTTPException in addition to urllib.error.URLError.

Example: the server breaks HTTP and returns an empty status line and we get a http.client.BadStatusLine.

----------
assignee: docs at python
components: Documentation
messages: 254720
nosy: docs at python, jon orebro
priority: normal
severity: normal
status: open
title: The documentation for urllib.request should mention http.client.HTTPException
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 16 04:39:59 2015
From: report at bugs.python.org (Jun Wang)
Date: Mon, 16 Nov 2015 09:39:59 +0000
Subject: [New-bugs-announce] [issue25634] Add a dedicated subclass for
 attribute missing errors
Message-ID: <1447666799.36.0.119700754928.issue25634@psf.upfronthosting.co.za>


New submission from Jun Wang:

See this simple example:

class A(): 
	def __init__(self, x=None): 
		self.x = x

	@property
	def t(self): 
		return self.x.t

	def __getattr__(self, name): 
		return 'default'

print(A().t)


AttributeError is raised as "'NoneType' object has no attribute 't'". Currently __getattr__ is called if any AttributeError is raised, so the result of a.t is *default*, while an AttributeError is the desired behavior.

The most intuitive solution seems to add a subclass of AttributeError, say AttributeMissError, which triggers __getattr__. At present, I have to do some tricky and ugly things to __getattribute__ to show where the AttributeError occurs, or it's quite hard to figure out what happened with no informative traceback messages.

----------
components: Interpreter Core
messages: 254722
nosy: ??
priority: normal
severity: normal
status: open
title: Add a dedicated subclass for attribute missing errors
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Nov 16 08:47:11 2015
From: report at bugs.python.org (keakon)
Date: Mon, 16 Nov 2015 13:47:11 +0000
Subject: [New-bugs-announce] [issue25635] urllib2 cannot fully read FTP file
Message-ID: <1447681631.39.0.26682578174.issue25635@psf.upfronthosting.co.za>


New submission from keakon:

I found the bug from this slide: http://sector.ca/Portals/17/Presentations15/SecTor_Branca.pdf

The second way cannot fully read the file.

import urllib2

url = 'ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest'
response = urllib2.urlopen(url)
data = response.read()
print len(data)  # 6653498

data = urllib2.urlopen(url).read()
print len(data)  # 65536


It might be something wrong with the FTP server. It's OK when I read from my own FTP server.

----------
components: Library (Lib)
messages: 254733
nosy: keakon
priority: normal
severity: normal
status: open
title: urllib2 cannot fully read FTP file
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 16 13:37:05 2015
From: report at bugs.python.org (Christian Ullrich)
Date: Mon, 16 Nov 2015 18:37:05 +0000
Subject: [New-bugs-announce] [issue25636] Let launcher autoselect best
 32-bit Python on 64-bit system
Message-ID: <1447699025.13.0.574177201603.issue25636@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

As described in PEP 397, the launcher can autoselect the "best" Python version available on a system, or a full version number (major.minor) can be specified. In the latter case, optionally a "-32" suffix can be given to select a 32-bit version, which is useful on 64-bit systems where a 64-bit Python is also present. By default it will select the highest (native) version.

I have an application that runs unmodified on Python 3.[345], but only with the 32-bit version because it loads a DLL (this is on Windows, but I think the basic issue applies to other systems as well) that has no 64-bit version available. I would like to run it on any system that has *any* suitable Python installed.

However, with the version selection syntax supported by the launcher, I can only demand a 32-bit version if I also specify the Python minor version I want, and I do not necessarily know that in advance.

What I would like the launcher to support is a version specification that allows using the "-32" suffix in all possible combinations with version numbers:

py -3.5-32 (same as today, 32-bit Python 3.5)
py -3-32   (highest 32-bit Python 3)
py -32     (highest 32-bit Python available)

The last form above, with no major version given, would look for the highest minor version in the default major version. The syntax might have to be different for compatibility reasons, although both incomplete specifications would result in an error message in all released versions.

I have been looking for a reason this limited syntax was chosen, but there has not to my knowledge been any discussion of this change on python-dev, and the May 2011 revision to PEP 397 ("based on python-dev feedback") in which it was introduced over the original, more flexible syntax also gives no further hint about its reasoning.

Solving this in application code could be done, of course, but both apparent solutions are incredibly ugly:

- Reimplementing the version autoselection by listing the available 32-bit versions.
- "Shooting blind", invoking every possible version from the top down until one works.
  "3.5-32? Nope. 3.4-32? Nope. 3.3-32? Yes!" This approach has the added downside that
  the launcher may not be in the $PATH at all. That is improbable, but possible.

I would much rather leave the work to the launcher, where the required knowledge is obviously available.

Thanks for hearing me out :-)

----------
messages: 254742
nosy: Christian.Ullrich
priority: normal
severity: normal
status: open
title: Let launcher autoselect best 32-bit Python on 64-bit system
type: enhancement

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

From report at bugs.python.org  Mon Nov 16 14:21:22 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Nov 2015 19:21:22 +0000
Subject: [New-bugs-announce] [issue25637] Move non-collections-related ABCs
 out of collections.abc
Message-ID: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za>


New submission from Brett Cannon:

In discussing adding a context manager ABC in issue #25609, the idea of creating a new module for ABCs that is more analogous to the types modules came up. Currently all ABCs that are generic in the stdlib and don't belong to a specific module end up in collections.abc, e.g. the Awaitable ABC has nothing to do with data structures and yet it's in a module in the collections package.

What we could do is create an interfaces module which contains all the ABCs that are not specific to a package. This would mean moving the ABCs out of collections.abc that have nothing to do with collections such as things for async, etc. The real question, though, is how to decide what belongs where, e.g. is Iterable/Iterator a collection, and if so then what about Generator?

The other option is that instead of introducing a generic interfaces module we simply create appropriate new modules to house the thematic ABCs and avoid a dumping ground scenario, e.g. some new module for the async stuff instead of just dumping them in an interfaces module. All the other ABCs could probably find existing homes, e.g. Callable could go into functools (although do we want to start a practice of having an abc submodule for all instances where ABCs exist and thus introduce functools.abc?).

----------
components: Library (Lib)
messages: 254744
nosy: brett.cannon, rhettinger, stutzbach
priority: normal
severity: normal
stage: test needed
status: open
title: Move non-collections-related ABCs out of collections.abc
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Nov 16 14:41:23 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Nov 2015 19:41:23 +0000
Subject: [New-bugs-announce] [issue25638] Verify the etree_parse and
 etree_iterparse benchmarks are working appropriately
Message-ID: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you look at bit.ly/pycon-ca-keynote you will notice that the etree_parse and etree_iterparse benchmarks were horrible for everyone. Because of how badly everyone seemed to do, I think the benchmarks should be verified to be doing reasonable things on implementations other than CPython 2.7.

----------
components: Benchmarks
messages: 254746
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Verify the etree_parse and etree_iterparse benchmarks are working appropriately

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

From report at bugs.python.org  Mon Nov 16 16:42:09 2015
From: report at bugs.python.org (Roman Kozhemiakin)
Date: Mon, 16 Nov 2015 21:42:09 +0000
Subject: [New-bugs-announce] [issue25639] open 'PhysicalDriveN' on windows
 fails (since python 3.5) with OSError: [WinError 1] Incorrect function
Message-ID: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za>


New submission from Roman Kozhemiakin:

open('\\\\.\\PHYSICALDRIVE1','rb',0)
fails since python 3.5

At the end of _io_FileIO___init___impl function 
_Py_fstat call raise OSError: [WinError 1] Incorrect function
_Py_fstat result not used on windows in this place. 

     440     self->blksize = DEFAULT_BUFFER_SIZE;
---> 441     if (_Py_fstat(self->fd, &fdfstat) < 0)
     442         goto error;
     443 #if defined(S_ISDIR) && defined(EISDIR)
     444     /* On Unix, open will succeed for directories.
     445        In Python, there should be no file objects referring to
     446        directories, so we need a check.  */
     447     if (S_ISDIR(fdfstat.st_mode)) {
     448         errno = EISDIR;
     449         PyErr_SetFromErrnoWithFilenameObject(PyExc_IOError, nameobj);
     450         goto error;
     451     }
     452 #endif /* defined(S_ISDIR) */
     453 #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE
     454     if (fdfstat.st_blksize > 1)
     455         self->blksize = fdfstat.st_blksize;
     456 #endif /* HAVE_STRUCT_STAT_ST_BLKSIZE */

----------
components: Library (Lib)
messages: 254756
nosy: rokozh
priority: normal
severity: normal
status: open
title: open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 16 16:48:00 2015
From: report at bugs.python.org (Matthieu Pepin)
Date: Mon, 16 Nov 2015 21:48:00 +0000
Subject: [New-bugs-announce] [issue25640] Message.is_attachment() throws
 exception
Message-ID: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za>


New submission from Matthieu Pepin:

Message.is_attachment() throws the exception below:

 File "/usr/lib/python3.5/email/message.py", line 956, in is_attachment
    return False if c_d is None else c_d.content_disposition == 'attachment'
AttributeError: 'str' object has no attribute 'content_disposition'

It seems to work fine for me with:

return c_d == 'attachment'

----------
components: email
messages: 254757
nosy: Matthieu Pepin, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Message.is_attachment() throws exception
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 16 17:46:08 2015
From: report at bugs.python.org (alphalfalfa)
Date: Mon, 16 Nov 2015 22:46:08 +0000
Subject: [New-bugs-announce] [issue25641]
 urllib/request.py/getproxies_environment() throws "dictionary changed size
 during iteration" error occasionally
Message-ID: <1447713968.83.0.231956831244.issue25641@psf.upfronthosting.co.za>


New submission from alphalfalfa:

For the following lines of code, "dictionary changed size during iteration" would be thrown when the environment variables change while in iteration.

Python-3.5.0/Lib/urllib/request.py
2393     for name, value in os.environ.items():
2394         name = name.lower()
2395         if value and name[-6:] == '_proxy':
2396             proxies[name[:-6]] = value

----------
components: Library (Lib)
messages: 254767
nosy: alphalfalfa
priority: normal
severity: normal
status: open
title: urllib/request.py/getproxies_environment() throws "dictionary changed size during iteration" error occasionally
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov 16 19:37:33 2015
From: report at bugs.python.org (Chris Seto)
Date: Tue, 17 Nov 2015 00:37:33 +0000
Subject: [New-bugs-announce] [issue25642] Setting maxsize breaks
 asyncio.JoinableQueue/Queue
Message-ID: <1447720653.5.0.538430267197.issue25642@psf.upfronthosting.co.za>


New submission from Chris Seto:

When maxsize is set on a JoinableQueue/Queue and the queue is full (maxsize <= len(queue)) _put is called rather than __put_internal.
__put_internal increments _unfinished_tasks but _put does not.
Whenever using maxsize in a Queue calling task_done will almost always cause a ValueError('task_done() called too many times').

----------
components: asyncio
files: test.py
messages: 254773
nosy: Chris Seto, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Setting maxsize breaks asyncio.JoinableQueue/Queue
type: crash
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file41057/test.py

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

From report at bugs.python.org  Mon Nov 16 20:27:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Nov 2015 01:27:33 +0000
Subject: [New-bugs-announce] [issue25643] Python tokenizer rewriting
Message-ID: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is preliminary patch that refactors the lowest level of Python tokenizer, reading and decoding. It splits the code on smaller simpler functions, decreases the source size by 37 lines, and fixes bugs: issue14811, issue18961, and a number of others. Added tests for most of fixed bugs (except leaks and others hardly reproducible). But the fix for other bugs can be harder, especially for issues with null byte (issue1105770, issue20115).

Many bug easily can be fixed if read all Python file in memory instead of reading it line by line. I don't know if it is acceptable.

----------
assignee: serhiy.storchaka
components: Interpreter Core
files: tokenize_input.patch
keywords: patch
messages: 254778
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Python tokenizer rewriting
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file41058/tokenize_input.patch

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

From report at bugs.python.org  Mon Nov 16 22:56:20 2015
From: report at bugs.python.org (Jatin Miglani)
Date: Tue, 17 Nov 2015 03:56:20 +0000
Subject: [New-bugs-announce] [issue25644] Unable to open IDLE on Windows 10
 with Python 2.7.10
Message-ID: <1447732580.69.0.0826869384289.issue25644@psf.upfronthosting.co.za>


New submission from Jatin Miglani:

Hi,
Seems like an issue with IDLE on Windows 10 with Python 2.7.10 active Python distribution. I'm able to open IDLE but it crash immediately. Try with deleting .idle.... folder but it couldn't help. Then I moved backed to 2.7.9 version which ultimately helps to get it invoked from machine. 
Kindly reproduce and check the 2.7.10 distribution with windows 10 64 bit.
Thanks
Jatin Miglani

----------
components: IDLE
messages: 254782
nosy: jatanig
priority: normal
severity: normal
status: open
title: Unable to open IDLE on Windows 10 with Python 2.7.10
type: crash

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

From report at bugs.python.org  Tue Nov 17 05:23:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Nov 2015 10:23:09 +0000
Subject: [New-bugs-announce] [issue25645] Reference leak in test_capi,
 on "import _pickle" in a subinterpreter
Message-ID: <1447755789.28.0.949162336612.issue25645@psf.upfronthosting.co.za>


New submission from STINNER Victor:

"""
[Python-checkins] Daily reference leaks (97e2a6810f7f): sum=10

    results for 97e2a6810f7f on branch "default"
    --------------------------------------------

    test_asyncio leaked [0, 0, 3] memory blocks, sum=3
    test_capi leaked [1, 1, 1] references, sum=3
    test_functools leaked [0, 2, 2] memory blocks, sum=4


    Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflogBLsY2a', '--timeout', '7200']
"""

It looks the leak comes from "import _pickle". The reference leak was introduced by the issue #24164 with the change bc5894a3a0e6. Attached patch should fix it.

To validate the patch, run: "./python -m test -R 3:3 test_capi", or "./python -m test -R 3:3 test_leak" with attached "test_leak.py".

@Serhiy: Since you wrote the change introduding the leak, could you please review my fix? Thanks.

----------
files: _pickle_partial.patch
keywords: patch
messages: 254787
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Reference leak in test_capi, on "import _pickle" in a subinterpreter
type: resource usage
versions: Python 3.6
Added file: http://bugs.python.org/file41060/_pickle_partial.patch

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

From report at bugs.python.org  Tue Nov 17 05:31:43 2015
From: report at bugs.python.org (JGoutin)
Date: Tue, 17 Nov 2015 10:31:43 +0000
Subject: [New-bugs-announce] [issue25646] Distutils and Windows SDK 7.0 /
 Windows SDK 7.1 / Visual C++ Build Tools 2015
Message-ID: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za>


New submission from JGoutin:

Hello,

This issue is related to Visual C++ standalone distributions (Without any Visual Studio version installed).

Distutils don't properly detect theses compilers. It try to work with "vcvarsall.bat" but this file : 
- is missing with Visual C++ Build Tools 2015.
- don't set correctly the environment with Windows SDK 7.0/7.1

I fixed this issue by modifying "vcvarsall.bat" for redirect to the goods files and set properly the environment. The procedure is detailed here : https://wiki.python.org/moin/WindowsCompilers

I have tested this issue with :
- Python 3.5 + Visual C++ Tools 2015
- Python 3.4 + Windows SDK 7.1
I have not tested yet (But it work exactly as SDK 7.1): 
- Python 2.7 + Windows SDK 7.0


I can eventually work to fix this directly on distutils (Or help to fix it).

----------
components: Distutils
messages: 254788
nosy: JGoutin, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015
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/issue25646>
_______________________________________

From report at bugs.python.org  Tue Nov 17 07:05:09 2015
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 17 Nov 2015 12:05:09 +0000
Subject: [New-bugs-announce] [issue25647] Return of asyncio.coroutine from
 asyncio.coroutine don't work in with enabled debug
Message-ID: <1447761909.17.0.397190405372.issue25647@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

Return of @asyncio.coroutine-wrapped coroutine object from @asyncio.coroutine-wrapped coroutine fails if asyncio debug is enabled.

Consider following example:

@asyncio.coroutine
def outer_coro():
    @asyncio.coroutine
    def inner_coro():
        return 1

    return g()

result = loop.run_until_complete(outer_coro())

If debug is disabled result will be 1, if debug is enabled, result will be CoroWrapper object.

This issue is discussed on asyncio mailing list: https://groups.google.com/forum/?fromgroups#!topic/python-tulip/YFfFxftxxDc

Complete example to reproduce this problem is here: https://gist.github.com/rutsky/c72be2edeb1c8256d680

Attaching patch for Python 3.4 branch that fixes this issue and add test for this bug.

This issue is not reproduced in Python 3.5, because CoroWrapper is awaitable in Python 3.5 (and in Python 3.4 CoroWrapper is not future or generator).

----------
components: asyncio
files: fix_return_of_coro_from_coro.diff
keywords: patch
messages: 254799
nosy: gvanrossum, haypo, vrutsky, yselivanov
priority: normal
severity: normal
status: open
title: Return of asyncio.coroutine from asyncio.coroutine don't work in with enabled debug
versions: Python 3.4
Added file: http://bugs.python.org/file41063/fix_return_of_coro_from_coro.diff

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

From report at bugs.python.org  Tue Nov 17 07:47:20 2015
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 17 Nov 2015 12:47:20 +0000
Subject: [New-bugs-announce] [issue25648] asyncio.coroutine fails if asyncio
 debug mode is enabled and wrapped function don't have "__name__" attribute
Message-ID: <1447764440.4.0.175921042664.issue25648@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

In Python 3.4.3 with enabled asyncio debug a function is
wrapped using the following code in @asyncio.coroutine:

@functools.wraps(func)
def wrapper(*args, **kwds):
    w = CoroWrapper(coro(*args, **kwds), func)
    if w._source_traceback:
        del w._source_traceback[-1]
    w.__name__ = func.__name__
    if hasattr(func, '__qualname__'):
        w.__qualname__ = func.__qualname__
    w.__doc__ = func.__doc__
    return w

The unconditional access to "__name__" and "__doc__" attributes may fail in some circumstances.

As this case looks strange and unrealistic I met it in a real
application that used mocking in tests. The code there was something like the following:

def f():
    return "f result"

mocked_f = Mock(wraps=f)
coro_func = asyncio.coroutine(mocked_f)
print(loop.run_until_complete(coro_func()))
mocked_f.assert_called_once_with() 

Here is complete example:
https://gist.github.com/rutsky/65cee7728135b05d49c3

This issue is fixed in 95964:957478e95b26 changeset during adding support of async/await syntax, so it is not reproduced in Python 3.5 or 3.4 head, but still reproducible in latest released version of Python 3.4 branch: 3.4.3.

So until 3.4.4 is released this issue still may be considered as not fixed.

----------
components: asyncio
messages: 254800
nosy: gvanrossum, haypo, vrutsky, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 17 12:07:40 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Nov 2015 17:07:40 +0000
Subject: [New-bugs-announce] [issue25649] Come up with a good way to handle
 module aliasing
Message-ID: <1447780060.32.0.735153163812.issue25649@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you look at things like https://github.com/kennethreitz/requests/issues/2870 and https://pythonhosted.org/six/#module-six.moves you start to notice that users do on occasion have a need to alias module names. It might be worth thinking through what that might entail and provide a solution.

Historically it has been done with a meta path importer which catches the import for some old module name, imports the real name, and then sets sys.modules under the alternative name before returning that the import was successful. It's a little tricky to get right, though, since you essentially have to pause an import while another one is going on, make sure you wait to the last minute to do the sys.modules aliasing to make sure no object swap handled from underneath you. I also have not thought through the best way to do this with module specs., but maybe there is a better way. There's also making sure locking is handled properly.

The reason this might be useful to have in importlib is it would help facilitate module renamings. If you set it up so that it isn't hard to turn on with mappings of old name to new along with whether you want to raise an ImportWarning about the aliasing then others may find it useful.

----------
components: Library (Lib)
messages: 254805
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Come up with a good way to handle module aliasing
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 17 13:36:23 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 Nov 2015 18:36:23 +0000
Subject: [New-bugs-announce] [issue25650] Mismatching documentation <=>
 behaviour for typing.Any
Message-ID: <1447785383.67.0.0503638677753.issue25650@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

The docstring for typing.Any specifically says "- Any object is an instance of Any."; in practice however it's not actually the case, as isinstance(x, Any) raises a TypeError.

AnyMeta makes this behaviour seem intentional, however the official documentation seems to be a bit vague on that one too -- https://docs.python.org/3/library/typing.html#the-any-type makes no mention of 'isinstance', but just the next paragraph mirrors the docstring, in 'Any object is an instance of Any'.

I personally believe this is a behaviour error and the docs are correct, as that seems the most logical conclusion. Should this be fixed for 3.5.1?

----------
components: Library (Lib)
messages: 254811
nosy: ebarry
priority: normal
severity: normal
status: open
title: Mismatching documentation <=> behaviour for typing.Any
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov 17 21:34:13 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 18 Nov 2015 02:34:13 +0000
Subject: [New-bugs-announce] [issue25651] Confusing output for
 TestCase.subTest(0)
Message-ID: <1447814053.14.0.516761369725.issue25651@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

When a single positional argument is passed to subTest(), if the argument is false, its value won't be displayed in the output -- (<subtest>) will appear instead:

>>> import unittest
>>> class NumbersTest(unittest.TestCase):
...   def test_odd(self):
...     for i in range(4):
...       with self.subTest(i):  # single positional arg
...         self.assertNotEqual(i%2, 0)
... 
>>> unittest.main(exit=False)
======================================================================
FAIL: test_odd (__main__.NumbersTest) (<subtest>)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 5, in test_odd
AssertionError: 0 == 0
======================================================================
FAIL: test_odd (__main__.NumbersTest) [2]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 5, in test_odd
AssertionError: 0 == 0
----------------------------------------------------------------------
Ran 1 test in 0.001s
FAILED (failures=2)

This is because subTest() accepts a positional "msg" arg, passes it to _SubTest (Lib/unittest/case.py:515), and then _SubTest checks using "if self._message:" (Lib/unittest/case.py:1400).

I think it would be better to check the message against a sentinel value instead.

----------
components: Library (Lib)
keywords: easy
messages: 254827
nosy: ezio.melotti, michael.foord, pitrou, rbcollins
priority: normal
severity: normal
stage: test needed
status: open
title: Confusing output for TestCase.subTest(0)
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Nov 18 00:16:09 2015
From: report at bugs.python.org (Jonathan Goble)
Date: Wed, 18 Nov 2015 05:16:09 +0000
Subject: [New-bugs-announce] [issue25652] collections.UserString.__rmod__()
 raises NameError
Message-ID: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za>


New submission from Jonathan Goble:

In an instance of collections.UserString, any call to the __rmod__() method will raise NameError, due to the undefined "args" name in the method.

----------
components: Library (Lib)
messages: 254830
nosy: Jonathan Goble, rhettinger
priority: normal
severity: normal
status: open
title: collections.UserString.__rmod__() raises NameError
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Nov 18 01:03:04 2015
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 18 Nov 2015 06:03:04 +0000
Subject: [New-bugs-announce] [issue25653] ctypes+callbacks+fork+selinux =
 crash
Message-ID: <1447826584.36.0.973987165664.issue25653@psf.upfronthosting.co.za>


New submission from Armin Rigo:

Ctypes uses libffi's `ffi_closure_alloc()`, which has a bug that make existing applications obscurely crash in one situation: if we are running on SELinux, making use of callbacks, and forking.  This is because `ffi_closure_alloc()` will detect that it is running on SELinux and use an alternative way to allocate memory for the callbacks.

It does that because selinux won't let a process mmap() any anonymous read-write-execute memory (at least in some settings; but libffi always uses the workaround if selinux is detected).  The workaround is to create a temporary file and mmap() it twice (at randomly different addresses), once as a read-write mapping and once as a read-execute mapping.  However, the internal structure of libffi requires that this mapping be MAP_SHARED (we can't easily first build the memory content, then write it to the temporary file and mmap() that fixed content in executable memory).

The problem with this is that if the process forks, this memory is shared.  If one of the two processes then frees the callback, the memory becomes garbage in the other process.

The problem was reported a few times at various places already, but not in this bug tracker.  See:

https://sourceware.org/ml/libffi-discuss/2009/msg00320.html

https://bugzilla.redhat.com/show_bug.cgi?id=531233

https://bugzilla.redhat.com/show_bug.cgi?id=707944

I am adding this issue to Python's bug tracker because, while in theory a libffi issue, it seems that Python is one of the very few libffi users that actually frees callbacks in this way.  I don't have a solution for either libffi or ctypes, though.  My own recommendation would be to stop using ``ffi_closure_alloc()`` and let the application either work (on selinux without deny_execmem) or cleanly trigger an error (on selinux with deny_execmem).

For reference, the issue was reported to CFFI's bug tracker about python-cryptography 1.0: it uses cffi's version of callbacks, whose implementation is close to ctypes', except not using ``ffi_closure_alloc()`` and so hitting the original selinux error instead of a crash.  The file https://bitbucket.org/cffi/cffi/raw/default/c/malloc_closure.h inside CFFI comes from an older version of ctypes which (by chance in this case) does not call ``ffi_closure_alloc()``.

----------
components: ctypes
messages: 254831
nosy: arigo
priority: normal
severity: normal
status: open
title: ctypes+callbacks+fork+selinux = crash
type: crash

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

From report at bugs.python.org  Wed Nov 18 02:13:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Nov 2015 07:13:48 +0000
Subject: [New-bugs-announce] [issue25654] test_multiprocessing_spawn
 ResourceWarning with -Werror
Message-ID: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za>


New submission from Martin Panter:

Running the test suite with -Werror enabled causes test_multiprocessing_spawn to print out lots of unhandled errors from the garbage collector, and one of these causes a test failure. It looks like there are lots of files that should be explicitly closed rather than leaving them for the garbage collector.

Also, one error occurred _after_ the test command had exiting. That can?t be a good thing, though I have never used the multiprocessing module so maybe this is unavoidable.

$ ./python -Werror -m unittest -v test.test_multiprocessing_spawn
. . .
======================================================================
FAIL: test_sys_exit (test.test_multiprocessing_spawn.WithProcessesTestSubclassingProcess)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/_test_multiprocessing.py", line 483, in test_sys_exit
    self.assertEqual(f.read().rstrip(), str(reason))
AssertionError: "[1, 2, 3]\nException ignored in: <_io.Fi[136 chars]-8'>" != '[1, 2, 3]'
- [1, 2, 3]
?          -
+ [1, 2, 3]- Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True>
- ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>

----------------------------------------------------------------------
Ran 265 tests in 151.904s

FAILED (failures=1, skipped=15)
[Exit 1]
$ Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True>
ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>

----------
components: Tests
messages: 254834
nosy: martin.panter
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn ResourceWarning with -Werror
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Nov 18 03:37:03 2015
From: report at bugs.python.org (never-eat-yellow-snow)
Date: Wed, 18 Nov 2015 08:37:03 +0000
Subject: [New-bugs-announce] [issue25655] Python errors related to failures
 loading DLL's lack information
Message-ID: <1447835823.22.0.872666546521.issue25655@psf.upfronthosting.co.za>


New submission from never-eat-yellow-snow:

Currently you get errors like this:

ImportError: DLL load failed: The specified procedure could not be found.
ImportError: DLL load failed: The specified module could not be found.

It would be nice to include more information, at least the name of the dll which could not be loaded. Maybe also the name of the (dependent) dll which could not be found.

Currently, I use ProcessMonitor to debug which dll could not be found, because the error message is lacking important information.

Note: I tagged the two versions I use, but probably all python versions are affected by this issue.

----------
components: Windows
messages: 254838
nosy: never-eat-yellow-snow, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python errors related to failures loading DLL's lack information
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Nov 18 09:04:58 2015
From: report at bugs.python.org (Tomer)
Date: Wed, 18 Nov 2015 14:04:58 +0000
Subject: [New-bugs-announce] [issue25656] multiprocessing.dummy: pool.map
 hangs on empty list
Message-ID: <1447855498.22.0.263851728204.issue25656@psf.upfronthosting.co.za>


New submission from Tomer:

Hi,
In multiprocessing.dummy module I noticed when you send a zero-length iterator to pool.map it hang forever,

Code example:

import urllib2 
from multiprocessing.dummy import Pool as ThreadPool

def start_multithreading_urlopen(threads_num):

    pool = ThreadPool(threads_num)
    results = pool.map(urllib2.urlopen, [])
    pool.close() 
    pool.join()

    # hang here

    print results

I think it related to Issue6433 that was fixed on multiprocessing module with simple length check

----------
components: Library (Lib)
messages: 254844
nosy: tomer70
priority: normal
severity: normal
status: open
title: multiprocessing.dummy: pool.map hangs on empty list
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 18 09:48:48 2015
From: report at bugs.python.org (serge-sans-paille)
Date: Wed, 18 Nov 2015 14:48:48 +0000
Subject: [New-bugs-announce] [issue25657] virtualenv's activate does not
 update LD_LIBRARY_PATH
Message-ID: <1447858128.82.0.165586856524.issue25657@psf.upfronthosting.co.za>


New submission from serge-sans-paille:

My use cas of virtual env was the following:

1. create a virtual env
2. install a third party shared library and its python wrapper
3. import the wrapper that itself loads the shared library

The problem is that the shared library gets install into <my_env>/lib (which is a normal behavior) but virtualenv's activate does not update LD_LIBRARY_PATH

A possible fix would be to add the following lines into virtualenv's activate:

```
if [ -n "$_OLD_VIRTUAL_LD_LIBRARY_PATH" ] ; then
    PATH="$_OLD_VIRTUAL_LD_LIBRARY_PATH"
    export LD_LIBRARY_PATH
    unset _OLD_VIRTUAL_LD_LIBRARY_PATH
fi
```

and a bit later

```
_OLD_VIRTUAL_LD_LIBRARY_PATH="$LD_LIBRARY_PATH"
LD_LIBRARY_PATH="$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
```

in a simialr manner to what is done with `PATH`

----------
messages: 254845
nosy: serge-sans-paille
priority: normal
severity: normal
status: open
title: virtualenv's activate does not update LD_LIBRARY_PATH
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 18 10:50:16 2015
From: report at bugs.python.org (Ed Schouten)
Date: Wed, 18 Nov 2015 15:50:16 +0000
Subject: [New-bugs-announce] [issue25658] PyThread assumes pthread_key_t is
 an integer, which is against POSIX
Message-ID: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>


New submission from Ed Schouten:

While trying to port Python over to a new platform (CloudABI), I noticed a couple of compiler errors in PyThread_create_key(), PyThread_delete_key(), PyThread_delete_key_value() and PyThread_set_key_value() caused by fact that pthread_key_t is converted to an integer (and vice versa)

POSIX doesn't seem to require that pthread_key_t is an integer or any other arithmetic type:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

Old revisions of the standard did require pthread_t to be an arithmetic type, but this requirement was dropped later on.

In my opinion we should strongly consider changing the API, so that we can treat the key created by pthread_key_create() or returned by TlsAlloc() as an opaque type.

----------
components: Interpreter Core
messages: 254846
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: PyThread assumes pthread_key_t is an integer, which is against POSIX
versions: Python 3.5

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

From report at bugs.python.org  Wed Nov 18 12:57:16 2015
From: report at bugs.python.org (Ely Spears)
Date: Wed, 18 Nov 2015 17:57:16 +0000
Subject: [New-bugs-announce] [issue25659] ctypes.Array.from_buffer
 segmentation fault when trying to create from array.array
Message-ID: <1447869436.37.0.609997226839.issue25659@psf.upfronthosting.co.za>


New submission from Ely Spears:

I'm trying to find a way to create a ctypes array from the underlying memory buffer exposed by an array.array object. The ctypes.Array.from_buffer function isn't documented, but I did find the source code in _ctypes.c around line 497. It's not clear to me where the problem might be.


Code to reproduce it below:

import array, ctypes
a1 = array.array('l')
a1.fromlist(range(10))
ctypes.Array.from_buffer(a1)
#Segfault

----------
components: ctypes
messages: 254851
nosy: spearsem at gmail.com
priority: normal
severity: normal
status: open
title: ctypes.Array.from_buffer segmentation fault when trying to create from array.array
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 18 14:58:50 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 18 Nov 2015 19:58:50 +0000
Subject: [New-bugs-announce] [issue25660] tabs don't work correctly in
 python repl
Message-ID: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

When Python is compiled with readline, repeatedly pressing <TAB> key in repl breaks the repl prompt.

Below is what I see when I hit <TAB> 4 times.

    yury at ysmac ~/dev/py/cpython $ ./python.exe
    Python 3.5.0+ (3.5:4ae62ddf7bc7+, Nov 18 2015, 14:52:57)
    [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>>

    >>>

    >>>

    >>>


Reproducible when Python is built from source on latest OS X.  Works OK when installed from MacPorts.

Further, if I add

   PyOS_ReadlineFunctionPointer = PyOS_StdioReadline;

in PyOS_Readline in myreadline.c, everything works as expected, so I think this is a readline bug.

----------
components: Interpreter Core
messages: 254855
nosy: r.david.murray, serhiy.storchaka, yselivanov
priority: high
severity: normal
status: open
title: tabs don't work correctly in python repl
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Nov 18 16:13:27 2015
From: report at bugs.python.org (Blake Hilliard)
Date: Wed, 18 Nov 2015 21:13:27 +0000
Subject: [New-bugs-announce] [issue25661] tokenize.untokenize does not
 maintain the order of tabbed indentations and leading spaces
Message-ID: <1447881207.88.0.934848299376.issue25661@psf.upfronthosting.co.za>


New submission from Blake Hilliard:

Here's a simple test case that shows the bug:

# python
Python 2.7.9 (default, Apr  2 2015, 14:49:18) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO, tokenize
>>> code = "if False:\n\tx=3\n \ty=3\n"
>>> g = list(tokenize.generate_tokens(StringIO.StringIO(code).readline))
>>> assert tokenize.untokenize(g) == code
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError


This is very similar to: https://bugs.python.org/issue20387

I'm using the patch that was provided to fix that bug, but with the patch this slightly different test case still fails. On the last line of "code" from my example, where the line begins with a single space then a tab, the untokenized string reverses the order, and the tab precedes the space. This generates code that will throw an IndentationError if run.

----------
components: Library (Lib)
messages: 254857
nosy: Blake Hilliard
priority: normal
severity: normal
status: open
title: tokenize.untokenize does not maintain the order of tabbed indentations and leading spaces
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 18 19:03:26 2015
From: report at bugs.python.org (Chesqa Yen)
Date: Thu, 19 Nov 2015 00:03:26 +0000
Subject: [New-bugs-announce] [issue25662] _tkinter.TclError: bad event type
 or keysym "Alt"
Message-ID: <1447891406.93.0.234833254631.issue25662@psf.upfronthosting.co.za>


New submission from Chesqa Yen:

For a while now my python IDLE has not been working, mostly due to me trying and failing to reconfigure the button assignment to tailor me. Now when i try to open idle it does not open. I tried using some sites for help (http://www.gossamer-threads.com/lists/python/bugs/901999) which had a similar error however, even with a new config file it still wasn't working. Please could I get some help as I need python running on my laptop to do my university coursework. I've attached a file with the error message from cmd.exe and will paste it again;

C:\Users\Francesca>C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\
Lib\idlelib\idle.py
Traceback (most recent call last):
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\PyShell.py", line 1560, in main
    shell = flist.open_shell()
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\PyShell.py", line 320, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\PyShell.py", line 867, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\EditorWindow.py", line 167, in __init__
    self.apply_bindings()
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\EditorWindow.py", line 1097, in apply_bindings
    text.event_add(event, *keylist)
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib
\MultiCall.py", line 374, in event_add
    widget.event_add(self, virtual, seq)
  File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\tkinter
\__init__.py", line 1503, in event_add
    self.tk.call(args)
_tkinter.TclError: bad event type or keysym "Alt"

----------
components: IDLE
files: error file.txt
messages: 254863
nosy: ronixx
priority: normal
severity: normal
status: open
title: _tkinter.TclError: bad event type or keysym "Alt"
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file41070/error file.txt

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

From report at bugs.python.org  Wed Nov 18 21:14:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Nov 2015 02:14:21 +0000
Subject: [New-bugs-announce] [issue25663] Make rlcompleter avoid duplicate
 global names
Message-ID: <1447899261.09.0.497189339865.issue25663@psf.upfronthosting.co.za>


New submission from Martin Panter:

When playing with the Editline alternative to Readline, I noticed that ?global? name completions can include duplicates:

>>> No
None                 NotADirectoryError(  NotImplementedError(
None                 NotImplemented      
>>> None
None None

It completed my line to ?None?, but if you hit Tab again, it lists two duplicate options both identical to what I already have. The reason is that ?None? is both a reserved keyword, and a member of the builtins module.

My patch avoids adding extra completions if a name has already been added. It also prioritizes the global namespace over builtins, so that say if you alias ?int? to a non-callable, it is no longer listed with an opening bracket ?(? suffix. Earlier behaviour:

>>> int = 81
>>> in
in     input( int    int(  

Now:

>>> in
in     input( int

----------
components: Library (Lib)
files: global-dupes.patch
keywords: patch
messages: 254873
nosy: martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Make rlcompleter avoid duplicate global names
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41071/global-dupes.patch

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

From report at bugs.python.org  Thu Nov 19 00:36:22 2015
From: report at bugs.python.org (Zephor Wu)
Date: Thu, 19 Nov 2015 05:36:22 +0000
Subject: [New-bugs-announce] [issue25664] Unexpected UnicodeDecodeError in
 logging module
Message-ID: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za>


New submission from Zephor Wu:

# coding=utf-8
import logging

logger = logging.getLogger(u'??')
logger.error(u'??')

# these code will get an unexpected error
# because getLogger encode the unicode to utf-8 while _log don't
# see line 474 in logging/__init__.py
# my suggestion is to keep the encoding in logging same with python2 with unicode

----------
components: Library (Lib)
messages: 254881
nosy: zephor
priority: normal
severity: normal
status: open
title: Unexpected UnicodeDecodeError in logging module
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 19 03:06:26 2015
From: report at bugs.python.org (Ashwini Chaudhary)
Date: Thu, 19 Nov 2015 08:06:26 +0000
Subject: [New-bugs-announce] [issue25665] typing.NamedTuple instances are
 not picklable.
Message-ID: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za>


New submission from Ashwini Chaudhary:

Currently namedtuple(https://hg.python.org/cpython/file/3.5/Lib/collections/__init__.py#l418) sets the `__module__` attribute by looking up `__name__` in calling frame's globals. As in the case of `typing.NamedTuple` it is always going to be 'typing' pickle will raise an error.

Instead of this `typing.NamedTuple` should override the `__module__` attribute itself because it has info about the actual caller frame.

Something like this should work fine:

```
def NamedTuple(typename, fields):

    fields = [(n, t) for n, t in fields]
    cls = collections.namedtuple(typename, [n for n, t in fields])
    cls._field_types = dict(fields)
    try:
        cls.__module__ = sys._getframe(1).f_globals.get('__name__', '__main__')
    except (AttributeError, ValueError):
        pass
    return cls
```

Related: http://stackoverflow.com/q/33796490/846892

----------
components: Library (Lib)
messages: 254883
nosy: montysinngh
priority: normal
severity: normal
status: open
title: typing.NamedTuple instances are not picklable.
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 19 04:00:33 2015
From: report at bugs.python.org (jon orebro)
Date: Thu, 19 Nov 2015 09:00:33 +0000
Subject: [New-bugs-announce] [issue25666] Python unexpectedly ignores a
 signal after fork
Message-ID: <1447923633.78.0.317393195352.issue25666@psf.upfronthosting.co.za>


New submission from jon orebro:

Description:
I found a slight problem with signal handling. It seems that if you have a signal handler setup for a signal, right after a fork the child ignores that signal for a short time. This is regardless of what the signal handler is setup to do. This can cause hangs if the parent immediately kills and then waits for the child. Since the timeframe is small, in practice this only happens sometimes (se example). There might be a reason for this behavour, but in that case I think it should me mentioned in the docs.

What I expected:
I expected the child to, at any point in time, either do the default action for the signal (terminate in this case), or to run the signal handler.

What happens:
It ignores the signal for a short while.

Tested versions:
Python 2.7.6
Python 3.4.0

----------
assignee: docs at python
components: Documentation, Interpreter Core
files: example.py
messages: 254890
nosy: docs at python, jon orebro
priority: normal
severity: normal
status: open
title: Python unexpectedly ignores a signal after fork
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41074/example.py

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

From report at bugs.python.org  Thu Nov 19 08:32:53 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 19 Nov 2015 13:32:53 +0000
Subject: [New-bugs-announce] [issue25667] Supply dual-stack (IPv4/IPv6)
 socket bind routine
Message-ID: <1447939973.83.0.965937708444.issue25667@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

When binding to a socket for creating a service, the socket API provides a mechanism for selecting only IPv4 or IPv6, but the simple operation of binding to all interfaces in a dual-stack environment is not easy, as is revealed in issue20215 and issue24209, but also in third-party packages. I ran into this during the implementation of aiosmtpd (https://gitlab.com/python-smtpd-hackers/aiosmtpd). As a long time maintainer of CherryPy, I've enjoyed the [dual stack support](https://bitbucket.org/cherrypy/cherrypy/src/536a9cb66e91de92502e766b2b0cf53d1cb5cb4a/cherrypy/wsgiserver/wsgiserver2.py?at=default&fileviewer=file-view-default#wsgiserver2.py-2007:2020) there.

I propose the Python stdlib provide a routine to facilitate this need more generally, and then invoke that implementation to address these other use-cases.

As it is a new feature, a backports package should be created to supply the same functionality for older Pythons.

Would this effort require a PEP? Is there a good place for such a routine (maybe socketserver)? Any other thoughts?

----------
components: Library (Lib)
messages: 254895
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: Supply dual-stack (IPv4/IPv6) socket bind routine
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 19 09:22:53 2015
From: report at bugs.python.org (Florent Viard)
Date: Thu, 19 Nov 2015 14:22:53 +0000
Subject: [New-bugs-announce] [issue25668] Deadlock in logging caused by a
 possible race condition with "format"
Message-ID: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>


New submission from Florent Viard:

When an user, use logging, to try to display an object that uses some threading locks, there could be a race condition and the logging module will deadlock. So, any thread that will try to use logging, will then be stuck forever.

Please see the following test case that is a simplification of a case that I have encountered. I'm able to reproduce the issue on python 3.4.3, and python 2.7.9. But, based on the code, I think that all versions are affected.

Basically, I try to log a variable that is like a property or the __unicode__ function of an object. But this value will not be calculated before entering the "logging.warning" code but in the "self.format" of the logging handler. This self.format is called under the umbrella of the big lock of "logging".

So, if function to get my variable value involve taking another lock and then performing a logging call. There is great chances that another thread also took the variable lock between the time that I took the logging lock and before it take the variable lock.

So, the first thread will wait for the variable lock but will have the logging lock.
But the other thread will have the variable lock but will wait the logging lock.


Traceback of the current situation:
# ThreadID: 140410437482240
File: "/usr/lib/python2.7/threading.py", line 783, in __bootstrap
  self.__bootstrap_inner()
File: "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
  self.run()
File: "/usr/lib/python2.7/threading.py", line 763, in run
  self.__target(*self.__args, **self.__kwargs)
File: "testcase-bug-python-deadlock-logging.py", line 37, in second_thread
  my_db.log_pid()
File: "testcase-bug-python-deadlock-logging.py", line 24, in log_pid
  logging.warning(u"my_db pid is: %s", u"1234")
File: "/usr/lib/python2.7/logging/__init__.py", line 1604, in warning
  root.warning(msg, *args, **kwargs)
File: "/usr/lib/python2.7/logging/__init__.py", line 1164, in warning
  self._log(WARNING, msg, args, **kwargs)
File: "/usr/lib/python2.7/logging/__init__.py", line 1271, in _log
  self.handle(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 1281, in handle
  self.callHandlers(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 1321, in callHandlers
  hdlr.handle(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 747, in handle
  self.acquire()
File: "/usr/lib/python2.7/logging/__init__.py", line 698, in acquire
  self.lock.acquire()
File: "/usr/lib/python2.7/threading.py", line 173, in acquire
  rc = self.__block.acquire(blocking)

# ThreadID: 140410445874944
File: "/usr/lib/python2.7/threading.py", line 783, in __bootstrap
  self.__bootstrap_inner()
File: "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
  self.run()
File: "/usr/lib/python2.7/threading.py", line 763, in run
  self.__target(*self.__args, **self.__kwargs)
File: "testcase-bug-python-deadlock-logging.py", line 31, in first_thread
  logging.warning(u"My slow pid is: %s", my_db)
File: "/usr/lib/python2.7/logging/__init__.py", line 1604, in warning
  root.warning(msg, *args, **kwargs)
File: "/usr/lib/python2.7/logging/__init__.py", line 1164, in warning
  self._log(WARNING, msg, args, **kwargs)
File: "/usr/lib/python2.7/logging/__init__.py", line 1271, in _log
  self.handle(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 1281, in handle
  self.callHandlers(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 1321, in callHandlers
  hdlr.handle(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 749, in handle
  self.emit(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
  msg = self.format(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 724, in format
  return fmt.format(record)
File: "/usr/lib/python2.7/logging/__init__.py", line 464, in format
  record.message = record.getMessage()
File: "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
  msg = msg % self.args
File: "testcase-bug-python-deadlock-logging.py", line 17, in __unicode__
  with db_lock:
File: "/usr/lib/python2.7/threading.py", line 173, in acquire
  rc = self.__block.acquire(blocking)

----------
components: Library (Lib)
files: testcase-bug-python-deadlock-logging.py
messages: 254896
nosy: fviard
priority: normal
severity: normal
status: open
title: Deadlock in logging caused by a possible race condition with "format"
type: crash
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/file41077/testcase-bug-python-deadlock-logging.py

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

From report at bugs.python.org  Thu Nov 19 09:59:24 2015
From: report at bugs.python.org (Nathan Herring)
Date: Thu, 19 Nov 2015 14:59:24 +0000
Subject: [New-bugs-announce] [issue25669] unittest.assertEqual() on un-equal
 types inheriting from collections.Mapping
Message-ID: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za>


New submission from Nathan Herring:

We have some code that generates objects that inherit from Mapping that are not nearly as straightforward to instantiate in a test. It's much easier to have something like the follows:

foo = ? # some collections.Mapping subtype
self.assertEqual({'key': 'value'}, foo)

unittest/case.py's _baseAssertEqual will print out both sides and let me do visual inspection, but I'd prefer it if it knew both sides supported Mapping and in the != case, performed an analog of assertDictEqual so I could just get the keys/values that were mismatched, especially in the cases of large dictionaries.

----------
components: Tests
messages: 254902
nosy: Nathan Herring
priority: normal
severity: normal
status: open
title: unittest.assertEqual() on un-equal types inheriting from collections.Mapping
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 19 10:11:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Nov 2015 15:11:04 +0000
Subject: [New-bugs-announce] [issue25670] ast.NodeTransformer: remove
 duplicate getattr()
Message-ID: <1447945864.74.0.854545532845.issue25670@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ast.NodeTransformer.generic_visit() calls getattr() whereas iter_fields() already returns the attribute. The getattr() is useless, attached patch removes it.

Sadly, it looks like test_ast doesn't test this class at all :-(

The class is tested *indirectly* by test_inspect.

----------
files: node_transformer.patch
keywords: patch
messages: 254903
nosy: haypo
priority: normal
severity: normal
status: open
title: ast.NodeTransformer: remove duplicate getattr()
type: performance
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41078/node_transformer.patch

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

From report at bugs.python.org  Thu Nov 19 10:24:50 2015
From: report at bugs.python.org (Nathan West)
Date: Thu, 19 Nov 2015 15:24:50 +0000
Subject: [New-bugs-announce] [issue25671] Fix venv activate.fish to maintain
 $status
Message-ID: <1447946690.19.0.336666934208.issue25671@psf.upfronthosting.co.za>


New submission from Nathan West:

Many fish_prompts use display the $status (fish's equivalent to $?) somewhere in the prompt. Currently, venv's activate.fish overwrites and wraps the user's fish_prompt, the wrapping doesn't preserve this $status. This patch ensures that the $status is correctly restored before invoking the user's fish_prompt.

This is based on my similar work in virtualenv, at https://github.com/pypa/virtualenv/pull/799

----------
components: Library (Lib)
files: patch.diff
keywords: patch
messages: 254906
nosy: Lucretiel
priority: normal
severity: normal
status: open
title: Fix venv activate.fish to maintain $status
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41079/patch.diff

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

From report at bugs.python.org  Thu Nov 19 13:17:07 2015
From: report at bugs.python.org (Cory Benfield)
Date: Thu, 19 Nov 2015 18:17:07 +0000
Subject: [New-bugs-announce] [issue25672] Unconditionally set
 SSL_MODE_RELEASE_BUFFERS
Message-ID: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za>


New submission from Cory Benfield:

Originally raised by Ben Bangert on the python-dev mailing list.

It turns out that OpenSSL has a mode setting, SSL_MODE_RELEASE_BUFFERS, that can be set by a call to SSK_CTX_set_mode. This mode can potentially reduce connection overhead by nearly 18kB *per connection*, a reduction of something like 60%. Further, this does not change the behaviour of OpenSSL in any meaningful way.

For this reason, we should unconditionally set this mode on all SSL Context objects we create.

I'm happy to submit a patch to the standard library that will do this.

----------
components: Library (Lib)
messages: 254918
nosy: Lukasa
priority: normal
severity: normal
status: open
title: Unconditionally set SSL_MODE_RELEASE_BUFFERS
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 19 13:34:52 2015
From: report at bugs.python.org (kehlert)
Date: Thu, 19 Nov 2015 18:34:52 +0000
Subject: [New-bugs-announce] [issue25673] unittest assertLessEqual not
 working properly with lists
Message-ID: <1447958092.38.0.804432580848.issue25673@psf.upfronthosting.co.za>


New submission from kehlert:

I attached a file that explains the issue. Basically, assertLessEqual only seems to compare the first elements of the two lists and ignores the others. Thus a test can pass when it shouldn't.

----------
files: example.py
messages: 254920
nosy: kehlert
priority: normal
severity: normal
status: open
title: unittest assertLessEqual not working properly with lists
versions: Python 3.4
Added file: http://bugs.python.org/file41081/example.py

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

From report at bugs.python.org  Thu Nov 19 16:54:38 2015
From: report at bugs.python.org (David Bolen)
Date: Thu, 19 Nov 2015 21:54:38 +0000
Subject: [New-bugs-announce] [issue25674] test_ssl (test_algorithms)
 failures on bolen-ubuntu slaves: sha256.tbs-internet.com unknown host
Message-ID: <1447970078.37.0.506919207401.issue25674@psf.upfronthosting.co.za>


New submission from David Bolen:

It appears that the test host (sha256.tbs-internet.com) used by test_algorithms in test_ssl.py no longer exists.

It was showing up as a certificate failure in the test because it ended up falling back to a resolv.conf search path which yielded a host that did do SSL but obviously with the wrong certificate.

db3l at buildbot-ubuntu:~$ host sha256.tbs-internet.com
Host sha256.tbs-internet.com not found: 3(NXDOMAIN)

db3l at buildbot-ubuntu:~/tmp/python3.x/Lib/test$ dig +short ns tbs-internet.com
NS1.tbs-internet.com.
maj.pitux.com.
ns2.atdynet.com.
nsc.pitux.com.
db3l at buildbot-ubuntu:~/tmp/python3.x/Lib/test$ dig @ns1.tbs-internet.com sha256.tbs-internet.com

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @ns1.tbs-internet.com sha256.tbs-internet.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25154
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sha256.tbs-internet.com.	IN	A

;; AUTHORITY SECTION:
tbs-internet.com.	3600	IN	SOA	ovh12.tbs-internet.com. hostmaster.tbs-internet.com. 2015110705 21600 3600 2419200 3600

;; Query time: 93 msec
;; SERVER: 2001:41d0:8:380d::1#53(2001:41d0:8:380d::1)
;; WHEN: Thu Nov 19 16:51:58 EST 2015
;; MSG SIZE  rcvd: 105


What I can't yet understand is why this is not causing issues on other slaves.  I suppose some might be skipping the test if SNI was not supported, but surely not all of them?

----------
components: Tests
messages: 254938
nosy: db3l, zach.ware
priority: normal
severity: normal
status: open
title: test_ssl (test_algorithms) failures on bolen-ubuntu slaves: sha256.tbs-internet.com unknown host
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Nov 19 16:56:01 2015
From: report at bugs.python.org (Ezequiel Alfie)
Date: Thu, 19 Nov 2015 21:56:01 +0000
Subject: [New-bugs-announce] [issue25675] doc for
 BaseEventLoop.run_in_executor() says its a coroutine, but it is not
Message-ID: <1447970161.65.0.436017258107.issue25675@psf.upfronthosting.co.za>


New submission from Ezequiel Alfie:

Doc says:

coroutine BaseEventLoop.run_in_executor(executor, func, *args)
...<more lines>...
    This method is a coroutine.

However, inspecting the code, I find that this function is not a coroutine. Also this function returns a Future instance, this fact should be mentioned in the doc.

----------
components: asyncio
messages: 254939
nosy: ealfie, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Nov 19 17:36:59 2015
From: report at bugs.python.org (Richard Tupper)
Date: Thu, 19 Nov 2015 22:36:59 +0000
Subject: [New-bugs-announce] [issue25676] Bug
Message-ID: <1447972619.43.0.147160136943.issue25676@psf.upfronthosting.co.za>


New submission from Richard Tupper:

resolved

----------
components: Windows
files: Garcinia Cambogia Free Trial UK.html
messages: 254940
nosy: omskinbourbe1977, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Bug
type: enhancement
versions: Python 2.6
Added file: http://bugs.python.org/file41088/Garcinia Cambogia Free Trial UK.html

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

From report at bugs.python.org  Fri Nov 20 00:50:56 2015
From: report at bugs.python.org (Michael Layzell)
Date: Fri, 20 Nov 2015 05:50:56 +0000
Subject: [New-bugs-announce] [issue25677] Syntax error caret confused by
 indentation
Message-ID: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za>


New submission from Michael Layzell:

It appears that syntax errors generated by checking the AST will get confused by indentation and place the caret incorrectly.

With no indentation:
===
1 + 1 = 2
===
  File "/Users/mlayzell/test.py", line 1
    1 + 1 = 2
    ^
SyntaxError: can't assign to operator
===

With 4 spaces of indentation:
===
if True:
    1 + 1 = 2
===
  File "/Users/mlayzell/test.py", line 2
    1 + 1 = 2
       ^
SyntaxError: can't assign to operator
===

As you can see, the caret appears to be placed randomly in the middle of the second statement, apparently offset (probably by the 4 space indentation).

The above examples were run with Python3.5 on Mac OS X 10.10.4, though my somewhat-recent trunk clone exhibits the same problems.

----------
components: Interpreter Core
messages: 254951
nosy: Michael Layzell
priority: normal
severity: normal
status: open
title: Syntax error caret confused by indentation
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Nov 20 03:40:40 2015
From: report at bugs.python.org (Sven Berkvens-Matthijsse)
Date: Fri, 20 Nov 2015 08:40:40 +0000
Subject: [New-bugs-announce] [issue25678] int() from a buffer reads past the
 buffer boundaries
Message-ID: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za>


New submission from Sven Berkvens-Matthijsse:

Calling int() or long() on a buffer() object in Python 2.7 does not do the right thing. The following code snippet:

buf = buffer("123test", 1, 2)
print buf
print int(buf)

does not do what I would expect (that it print "23" twice). Instead, it prints "23" once and then throws an exception:

ValueError: invalid literal for int() with base 10: '23test'

This is caused by Objects/abstract.c function int_from_string(), which gets passed the length of the string but does not actually use that information to limit what part is parsed from the string. It only uses it to check for embedded NUL bytes. The real culprit is probably PyInt_FromString() which does not take a length indicator.

----------
components: Interpreter Core
messages: 254958
nosy: svenberkvens
priority: normal
severity: normal
status: open
title: int() from a buffer reads past the buffer boundaries
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 20 04:13:31 2015
From: report at bugs.python.org (Novice Live)
Date: Fri, 20 Nov 2015 09:13:31 +0000
Subject: [New-bugs-announce] [issue25679] Fix typo in
 Doc/reference/executionmodel.rst
Message-ID: <1448010811.87.0.415617545534.issue25679@psf.upfronthosting.co.za>


New submission from Novice Live:

> 4. Execution model
> 4.1. Structure of a programm

You see.

----------
assignee: docs at python
components: Documentation
files: executionmodel-typo.patch
keywords: patch
messages: 254962
nosy: docs at python, n0vicelive
priority: normal
severity: normal
status: open
title: Fix typo in Doc/reference/executionmodel.rst
Added file: http://bugs.python.org/file41092/executionmodel-typo.patch

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

From report at bugs.python.org  Fri Nov 20 09:18:22 2015
From: report at bugs.python.org (Aleksey Kladov)
Date: Fri, 20 Nov 2015 14:18:22 +0000
Subject: [New-bugs-announce] [issue25680] Selector.select() hangs when there
 is nothing to select
Message-ID: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>


New submission from Aleksey Kladov:

The following hangs on Linux

```Python
>>> import selectors
>>> s = selectors.DefaultSelector()
>>> s.select()
```

On Mac it returns an empty list.

----------
messages: 254975
nosy: Aleksey Kladov
priority: normal
severity: normal
status: open
title: Selector.select() hangs when there is nothing to select
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 20 09:39:48 2015
From: report at bugs.python.org (Yan)
Date: Fri, 20 Nov 2015 14:39:48 +0000
Subject: [New-bugs-announce] [issue25681] Assignment of one element in
 nested list changes multiple elements
Message-ID: <1448030388.6.0.28566235581.issue25681@psf.upfronthosting.co.za>


New submission from Yan:

Is this the correct behavior?

>>> l=[['']*2]*3
>>> b=[['', ''], ['', ''], ['', '']]
>>> l == b
True
>>> l[0][1]='A'
>>> b[0][1]='A'
>>> l == b
False
>>> l
[['', 'A'], ['', 'A'], ['', 'A']]
>>> b
[['', 'A'], ['', ''], ['', '']]

----------
messages: 254978
nosy: ydu
priority: normal
severity: normal
status: open
title: Assignment of one element in nested list changes multiple elements
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 20 11:02:19 2015
From: report at bugs.python.org (Keith Prussing)
Date: Fri, 20 Nov 2015 16:02:19 +0000
Subject: [New-bugs-announce] [issue25682] __package__ not set to None under
 pdb in Python 3
Message-ID: <1448035339.32.0.969832659097.issue25682@psf.upfronthosting.co.za>


New submission from Keith Prussing:

When a module is run under pdb in Python 3, __package__ is set to the empty string instead of None.  The attached minimum working example depicts this behavior.  The results are summarized in the following table.

=============== ====== ======
    Command      Py 2   Py 3
=============== ====== ======
 python          None   None
 python -m        ''     ''
 python -m pdb   None    ''
 pdb             None    ''
=============== ====== ======

The behavior I expected was for the Python executable to treat the input file as a script and not a module.  My rationale is that pdb is loaded as the executing module that accepts a script as its argument.  Per the help, only one -m option is allowed when launching python.

----------
components: Extension Modules
files: mwe.py
messages: 254989
nosy: Keith Prussing
priority: normal
severity: normal
status: open
title: __package__ not set to None under pdb in Python 3
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file41099/mwe.py

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

From report at bugs.python.org  Fri Nov 20 11:29:46 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 20 Nov 2015 16:29:46 +0000
Subject: [New-bugs-announce] [issue25683] __context__ for yields inside
 except clause
Message-ID: <1448036986.79.0.682793402944.issue25683@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

In the below snippet, SubError will propagate with __context__ set to None, instead of MainError.  Maybe this isn't a bug?

    class MainError(Exception): pass
    class SubError(Exception): pass

    def main():
        try:
            raise MainError()
        except MainError:
            yield

    coro = main()
    coro.send(None)
    coro.throw(SubError())

----------
components: Interpreter Core
messages: 254994
nosy: benjamin.peterson, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: __context__ for yields inside except clause
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Nov 20 12:24:48 2015
From: report at bugs.python.org (Bryan Oakley)
Date: Fri, 20 Nov 2015 17:24:48 +0000
Subject: [New-bugs-announce] [issue25684] ttk.OptionMenu radiobuttons aren't
 unique between two instances of OptionMenu
Message-ID: <1448040288.53.0.198369542776.issue25684@psf.upfronthosting.co.za>


New submission from Bryan Oakley:

Original issue was brought to my attention by this SO question: http://stackoverflow.com/questions/33831289/ttk-optionmenu-displaying-check-mark-on-all-menus

The ttk.OptionMenu uses radiobuttons for the dropdown menu. However, because it doesn't set the `variable` attribute, they all get the default. If you have two or more OptionMenu instances, all of the radiobuttons are tied together. If you select the first item in the first OptionMenu, and the second item in the second OptionMenu, the dropdown menu for both will show the second item checked.

The solution is to add `variable=self._variable` when creating the menu radiobutton items.

----------
components: Tkinter
messages: 255001
nosy: Bryan.Oakley
priority: normal
severity: normal
status: open
title: ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu
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/issue25684>
_______________________________________

From report at bugs.python.org  Fri Nov 20 14:06:50 2015
From: report at bugs.python.org (Marvin Greenberg)
Date: Fri, 20 Nov 2015 19:06:50 +0000
Subject: [New-bugs-announce] [issue25685] Inefficiency with SocketHandler -
 may send log record message string twice in pickled data structure
Message-ID: <1448046410.18.0.578360319482.issue25685@psf.upfronthosting.co.za>


New submission from Marvin Greenberg:

In logging.handlers.SocketHandler.makePickle code was added for issue 14436 that replaces the 'msg' in the log record dict with the formatted message.  But if an earlier handler already formatted the message, it will have been added to the log record with key 'message'.  In this case the identical message will be sent across the wire twice in the pickled data.

The patch simply deletes the 'message' entry from the dict.  More involved changes (like reusing record.message instead of calling getMessage) probably not useful.

----------
components: Library (Lib)
files: handlers.py.patch
keywords: patch
messages: 255011
nosy: Marvin Greenberg
priority: normal
severity: normal
status: open
title: Inefficiency with SocketHandler - may send log record message string twice in pickled data structure
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file41104/handlers.py.patch

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

From report at bugs.python.org  Fri Nov 20 17:13:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Nov 2015 22:13:35 +0000
Subject: [New-bugs-announce] [issue25686] Don't use distutils in test_shutil
Message-ID: <1448057615.39.0.634950011826.issue25686@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The distutils package is used in test_shutil to search and run external archivers. But using distutils can have side effects (see issue25607).

Proposed patch replaces distutils with standard functions for searching executables and running command, shutil.which() and subprocess.check_call().

----------
components: Tests
files: test_shutil_no_distutils.patch
keywords: patch
messages: 255023
nosy: eric.araujo, serhiy.storchaka, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Don't use distutils in test_shutil
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41105/test_shutil_no_distutils.patch

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

From report at bugs.python.org  Sat Nov 21 02:54:27 2015
From: report at bugs.python.org (Benno Leslie)
Date: Sat, 21 Nov 2015 07:54:27 +0000
Subject: [New-bugs-announce] [issue25687] Error during test case and tearDown
Message-ID: <1448092467.41.0.746674123801.issue25687@psf.upfronthosting.co.za>


New submission from Benno Leslie:

I'm not sure if this should be considered a bug, but the behaviour is surprising and not clearly documented.

I a have a very simple test that has an error during both the test case, and during tearDown.

"""
import unittest

class Test(unittest.TestCase):

    def test_a(self):
        asdf

    def tearDown(self):
        asdf

if __name__ == '__main__':
    unittest.main()
"""

When this occurs it is surprising (to me) that the output is:

"""
Ran 1 test in 0.000s

FAILED (errors=2)
"""

In particular, the fact that has more errors than there are tests that have been run. Obviously in this very simple example it is clear what has happened, however in a test suite that has hundreds of test cases it is somewhat frustrating to have the number of failing test cases over-reported. (And of course in the real-world test suite that led to this the tearDown doesn't fail on every single test case like in this simplified example).

Although there are definitely two errors occurring in my example, in all other cases, only the first error would be reported. e.g.: an error in setUp wouldn't run the test case, and only the first (potential) error in the testcase itself would occur.

I think that either:

1/ The documentation of the tearDown method should clearly indicate that an error in tearDown would cause multiple errors to be reported for the single testCase, or.
2/ Change the implementation so that if there is an exception during tearDown, and there was already an error in the test case only the first error is reported.

2 is probably a non-starter given backwards compatibility concerns (even assuming anyone else thinks this is the best behaviour in this corner case).

I'd be happy to try and draft something for #1 if that is the best action.

----------
components: Library (Lib)
messages: 255045
nosy: bennoleslie
priority: normal
severity: normal
status: open
title: Error during test case and tearDown
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 21 06:11:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Nov 2015 11:11:33 +0000
Subject: [New-bugs-announce] [issue25688] File leak in
 ElementTree.iterparse()
Message-ID: <1448104293.18.0.824435970603.issue25688@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

ElementTree.iterparse() can leak internally open file in case of error. Proposed patch fixes the leak.

----------
components: Library (Lib)
files: etree_iterparse_leak.patch
keywords: patch
messages: 255051
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: File leak in ElementTree.iterparse()
type: resource usage
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41111/etree_iterparse_leak.patch

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

From report at bugs.python.org  Sat Nov 21 07:35:52 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 21 Nov 2015 12:35:52 +0000
Subject: [New-bugs-announce] [issue25689] ftplib docs language fix
Message-ID: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za>


New submission from SilentGhost:

Just a minor fix, removing the following: "Here is a sample on how using it:"

----------
assignee: docs at python
components: Documentation
files: ftplib_docs.diff
keywords: patch
messages: 255056
nosy: SilentGhost, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: ftplib docs language fix
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41112/ftplib_docs.diff

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

From report at bugs.python.org  Sat Nov 21 11:23:04 2015
From: report at bugs.python.org (Niv Ben-David)
Date: Sat, 21 Nov 2015 16:23:04 +0000
Subject: [New-bugs-announce] [issue25690] Replacement for
 unittest.mock.mock_open
Message-ID: <1448122983.8.0.049241542179.issue25690@psf.upfronthosting.co.za>


New submission from Niv Ben-David:

The unittest.mock module defines a mock_open utility to mock the builtin open function.

During a recent project I found I needed something more. Specifically, mocking different files at the same time, better mocking for operations (like seek, readlines, etc.) among others.

The project can also be found on http://github.com/nivbend/mock-open

Thanks

----------
components: Library (Lib)
files: mock_open.patch
keywords: patch
messages: 255061
nosy: Niv Ben-David
priority: normal
severity: normal
status: open
title: Replacement for unittest.mock.mock_open
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41113/mock_open.patch

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

From report at bugs.python.org  Sat Nov 21 12:04:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Nov 2015 17:04:39 +0000
Subject: [New-bugs-announce] [issue25691] Crash on deleting Element attribute
Message-ID: <1448125479.67.0.778631980782.issue25691@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import xml.etree.ElementTree as ET
>>> e = ET.Element('tag')
>>> del e.tag
Segmentation fault (core dumped)

Proposed patch fixes the crash.

----------
components: Extension Modules
files: etree_del_attributes.patch
keywords: patch
messages: 255063
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Crash on deleting Element attribute
type: crash
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file41114/etree_del_attributes.patch

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

From report at bugs.python.org  Sat Nov 21 17:01:43 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 21 Nov 2015 22:01:43 +0000
Subject: [New-bugs-announce] [issue25692] input function outputs prompt to
 stderr
Message-ID: <1448143303.11.0.840684568567.issue25692@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

The built-in function 'input' appears to be sending the prompt to stderr instead of stdout, as the docs state it should.

$ python3.5 -c "print('stdout'); import sys; print('stderr', file=sys.stderr); input('foo')" 2> errors.txt
stdout
hello
$ cat errors.txt
stderr
foo

I've replicated this behavior in both Python 3.4 on Linux and Python 3.5 and 2.7 on OS X. Here's the 2.7 test/output:

$ python2.7 -c "from __future__ import print_function; print('stdout'); import sys; print('stderr', file=sys.stderr); raw_input('foo')" 2> errors.txt
stdout
hello
$ cat errors.txt 
stderr
foo

I believe the stated behavior (outputting the prompt to stdout) is the proper behavior.

I figure I must be doing something wrong here, because it seems bizarre to me that this discrepancy hasn't been discovered before.

----------
messages: 255072
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: input function outputs prompt to stderr
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Nov 22 03:08:35 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 Nov 2015 08:08:35 +0000
Subject: [New-bugs-announce] [issue25693] test_asyncio prints some messages
Message-ID: <1448179715.27.0.908145386853.issue25693@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

When running full test suite, test_asyncio prints some messages.
ResourceWarnings should be fixed.
Other messages should not be shown, at least without --verbose.

[171/398] test_epoll
[172/398] test_optparse
[173/398] test_socket
[174/398] test_sax
[175/398] test_weakref
[176/398] test_codecmaps_tw
[177/398] test_property
[178/398] test_asyncio
Executing <Task finished coro=<CoroutineTests.test_async_def_wrapped.<locals>.start() done, defined at /tmp/cpython/Lib/test/test_asyncio/test_pep492.py:146> result=None created at /tmp/cpython/Lib/asyncio/base_events.py:317> took 0.252 seconds
/tmp/cpython/Lib/threading.py:864: ResourceWarning: unclosed <socket.socket fd=24, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 58231)>
  self._target(*self._args, **self._kwargs)
returning true from eof_received() has no effect when using ssl
returning true from eof_received() has no effect when using ssl
/tmp/cpython/Lib/asyncio/base_events.py:379: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False>
  warnings.warn("unclosed event loop %r" % self, ResourceWarning)
[179/398] test_os
[180/398] test_enumerate
[181/398] test_math
[182/398] test_zipfile
[183/398] test_tarfile
[184/398] test_pep380
[185/398] test_with
[186/398] test_mmap
[187/398] test_trace
[188/398] test_eintr

----------
components: Tests, asyncio
messages: 255086
nosy: Arfrever, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio prints some messages
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Nov 22 03:49:09 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 Nov 2015 08:49:09 +0000
Subject: [New-bugs-announce] [issue25694] test.libregrtest not installed
Message-ID: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test.libregrtest is not installed, which breaks running of test suite from installed Python.
Probably LIBSUBDIRS in Makefile.pre.in should be updated.

$ python3.5 -m test test_int
[1/1] test_int
1 test OK.
$ python3.6 -m test test_int
Traceback (most recent call last):
  File "/usr/lib64/python3.6/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/lib64/python3.6/test/__main__.py", line 1, in <module>
    from test import regrtest
  File "/usr/lib64/python3.6/test/regrtest.py", line 14, in <module>
    from test.libregrtest import main, main_in_temp_cwd
ImportError: No module named 'test.libregrtest'

----------
assignee: haypo
components: Tests
messages: 255087
nosy: Arfrever, haypo
priority: normal
severity: normal
status: open
title: test.libregrtest not installed
versions: Python 3.6

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

From report at bugs.python.org  Sun Nov 22 03:58:57 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 Nov 2015 08:58:57 +0000
Subject: [New-bugs-announce] [issue25695] test___all__ and test_support
 alter execution environment
Message-ID: <1448182737.98.0.235138945354.issue25695@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test___all__ and test_support alter execution environment.
Problem seems to be present only in Python 3.6.

$ python3.5 -m test test___all__ test_support
[1/2] test___all__
[2/2] test_support
All 2 tests OK.
$ python3.6 -m test test___all__ test_support
[1/2] test___all__
Warning -- files was modified by test___all__
[2/2] test_support
Warning -- files was modified by test_support
2 tests altered the execution environment:
    test___all__ test_support


When running these test files separately, problem is only present for test___all__:

$ python3.5 -m test test___all__
[1/1] test___all__
1 test OK.
$ python3.6 -m test test___all__
[1/1] test___all__
Warning -- files was modified by test___all__
1 test altered the execution environment:
    test___all__
$ python3.5 -m test test_support
[1/1] test_support
1 test OK.
$ python3.6 -m test test_support
[1/1] test_support
1 test OK.

----------
components: Tests
messages: 255088
nosy: Arfrever, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: test___all__ and test_support alter execution environment
versions: Python 3.6

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

From report at bugs.python.org  Sun Nov 22 09:31:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 Nov 2015 14:31:42 +0000
Subject: [New-bugs-announce] [issue25696] "make install" fails because
 bininstall target requires the libainstall target
Message-ID: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I'm unable to install Python 3.6, "make install" doesn't copy .py files because the bininstall target failed. It failed because /opt/py36/lib/pkgconfig doesn't exist.

Try:
---
export MAKEFLAGS=-j9
rm -rf /opt/py36
./configure --prefix=/opt/py36
make
make install   # you may need 'sudo make install'
---

Attached patch fixes the Makefile, but I don't know if my change is correct.

----------
components: Build
files: bininstall.patch
keywords: patch
messages: 255102
nosy: Arfrever, doko, haypo
priority: normal
severity: normal
status: open
title: "make install" fails because bininstall target requires the libainstall target
versions: Python 3.6
Added file: http://bugs.python.org/file41124/bininstall.patch

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

From report at bugs.python.org  Sun Nov 22 10:44:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Nov 2015 15:44:48 +0000
Subject: [New-bugs-announce] [issue25697] Fix rough alphabetical order in
 Misc/ACKS
Message-ID: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

the list in Misc/ACKS is intended to be in rough alphabetical order by last names. But some lines breaks this order. Proposed patch restores ordering. It also removes duplicates for Richard Oudkerk.

Correct sorting is not easy due to different letter order in different alphabets and different collation rules in different languages. I tried to take it into account, but can make a mistake.

----------
assignee: docs at python
components: Documentation
files: acks_order-3.6.patch
keywords: patch
messages: 255106
nosy: docs at python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix rough alphabetical order in Misc/ACKS
Added file: http://bugs.python.org/file41125/acks_order-3.6.patch

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

From report at bugs.python.org  Sun Nov 22 13:58:26 2015
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 22 Nov 2015 18:58:26 +0000
Subject: [New-bugs-announce] [issue25698] test regressions introduced with
 the fix for #22995
Message-ID: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen with the 2.7.11 release candidate; I'm not yet 100% if this is the fix for #22995 causing these test regressions.

[ 93/395] test_cpickle
test test_cpickle failed -- multiple errors occurred; run in verbose mode for details
[101/395/2] test_decimal
test test_decimal failed -- Traceback (most recent call last):
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_decimal.py", line 1774, in test_pickle
    e = pickle.loads(pickle.dumps(c, proto))
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 1380, in dumps
    Pickler(file, protocol).dump(obj)
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 224, in dump
    self.save(obj)
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 306, in save
    rv = reduce(self.proto)
AttributeError: 'module' object has no attribute '_reduce_ex'

[108/395/4] test_dictviews
test test_dictviews failed -- Traceback (most recent call last):
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_dictviews.py", line 201, in test_pickle
    pickle.dumps, d.viewkeys(), proto)
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/unittest/case.py", line 473, in assertRaises
    callableObj(*args, **kwargs)
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 1380, in dumps
    Pickler(file, protocol).dump(obj)
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 224, in dump
    self.save(obj)
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 306, in save
    rv = reduce(self.proto)
AttributeError: 'module' object has no attribute '_reduce_ex'

[177/395/7] test_imp
test test_imp failed -- Traceback (most recent call last):
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_imp.py", line 60, in test_source
    imp.reload(os)
  File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/os.py", line 727, in <module>
    _copy_reg.pickle(stat_result, _pickle_stat_result, _make_stat_result)
AttributeError: 'module' object has no attribute 'pickle'

[184/395/10] test_int_literal
[185/395/10] test_ioctl
test test_ioctl crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[186/395/11] test_isinstance
[187/395/11] test_iter
[188/395/11] test_iterlen
[189/395/11] test_itertools
[190/395/11] test_json
test test_json crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[191/395/12] test_kqueue
test_kqueue skipped -- test works only on BSD
[192/395/12] test_largefile
test test_largefile crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[193/395/13] test_lib2to3
test test_lib2to3 crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[194/395/14] test_linecache
test test_linecache crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[195/395/15] test_list
test test_list crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[196/395/16] test_locale
[197/395/16] test_logging
test test_logging crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[198/395/17] test_long
[199/395/17] test_long_future
[200/395/17] test_longexp
[201/395/17] test_macos
test test_macos crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[202/395/18] test_macostools
test test_macostools crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[203/395/19] test_macpath
[204/395/19] test_macurl2path
[205/395/19] test_mailbox
test test_mailbox crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[206/395/20] test_marshal
test test_marshal crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[207/395/21] test_math
test test_math crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'
[208/395/22] test_md5
[209/395/22] test_memoryio
test test_memoryio failed -- multiple errors occurred; run in verbose mode for details
[210/395/23] test_memoryview
[211/395/23] test_mhlib
test test_mhlib crashed -- <type 'exceptions.AttributeError'>: 'module' object has no attribute 'pickle'

----------
components: Extension Modules
messages: 255109
nosy: benjamin.peterson, doko, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: test regressions introduced with the fix for #22995
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 22 15:46:20 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Sun, 22 Nov 2015 20:46:20 +0000
Subject: [New-bugs-announce] [issue25699] Easier way to specify reduced
 globals for doctest
Message-ID: <1448225180.77.0.54969716848.issue25699@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

Currently doctest.testmod `globals` defaults to including everything in the module scope, and tools like pyflakes assume that doctests run with globals as a copy of __dict__ .

It is relatively simple to exclude everything using doctest.testmod(globs={}).

However to use a limited scope, such as only including attributes in __all__, we need to use `doctest.testmod(globs=[(name, globals()[name]) for name in __all__])`

However those solutions require that each module includes a `if __name__ == "__main__":` block that invokes doctest.testmod, and then other doctest related tools (pyflakes, nose, etc) need to *parse* the invocation to determine the desired globals contents.

It would be easier to control the globals using a module attribute that works like __all__, so that all doctest tools could easily determine the desired contents of globals.

e.g. the following could provide a sane reduced globals for doctests

__test_all__ = __all__ = ['foo']

As people sometimes add docstrings/doctest for functions not exported in __all__ for external use, in addition to the list of symbols in __test_all__, the doctest globals should include the function/class which the docstring/doctest is attached to.

See https://bugs.launchpad.net/pyflakes/+bug/1178807 for background to this enhancement request.

----------
components: Tests
messages: 255111
nosy: John.Mark.Vandenberg
priority: normal
severity: normal
status: open
title: Easier way to specify reduced globals for doctest
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Nov 22 19:44:40 2015
From: report at bugs.python.org (Laur Joost)
Date: Mon, 23 Nov 2015 00:44:40 +0000
Subject: [New-bugs-announce] [issue25700] namedtuple documentation
Message-ID: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za>


New submission from Laur Joost:

collections.namedtuple documentation has an example about changing the resulting class docstrings:

  Docstrings can be customized by making direct assignments to the
  ``__doc__`` fields:
  
     >>> Book = namedtuple('Book', ['id', 'title', 'authors'])
     >>> Book.__doc__ += ': Hardcover book in active collection'

This seems to work for the resulting class, but not the field names:

    MsgPacket = namedtuple('MsgPacket', ['sender', 'target', 'sig', 'ser_msg'])
    MsgPacket.__doc__ = '. Message packet format. This is the data added to client queues.'
    MsgPacket.sender.__doc__ = 'Sender public key.'

gives

    Traceback (most recent call last):
      File "C:/UTCloud/UT/DS/S11/server.py", line 42, in <module>
        MsgPacket.sender.__doc__ = 'Sender public key.'
    AttributeError: readonly attribute

----------
assignee: docs at python
components: Documentation
messages: 255121
nosy: Laur Joost, docs at python
priority: normal
severity: normal
status: open
title: namedtuple documentation
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 23 01:57:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 06:57:21 +0000
Subject: [New-bugs-announce] [issue25701] Document that tp_setattro and
 tp_setattr are used for deleting attributes
Message-ID: <1448261841.63.0.685963364339.issue25701@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

tp_setattro and tp_setattr fields of PyTypeObject are used for deleting attributes. In this case the third argument is NULL. This should be documented. Not awareness of this can cause a segmentation fail (for example see issue25698).

----------
assignee: docs at python
components: Documentation
messages: 255130
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document that tp_setattro and tp_setattr are used for deleting attributes
type: crash
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov 23 03:59:40 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 23 Nov 2015 08:59:40 +0000
Subject: [New-bugs-announce] [issue25702] Link Time Optimizations support
 for GCC and CLANG
Message-ID: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>


New submission from Alecsandru Patrascu:

Title: Link Time Optimizations support for GCC and CLANG

Hi All,

This is Alecsandru from Server Scripting Languages Optimization team at Intel Corporation. I would like to submit a patch that adds support for Link Time Optimization (LTO) when using GCC and CLANG to compile CPython2 and CPython3. LTO is a compiler assisted optimization technique that is performed by the compiler at link time.

Combined with Profile Guided Optimization (PGO), enabled when running "make profile-opt", and running the Grand Unified Python Benchmark (GUPB), a speedup up to 11%, with a few regressions, was observed comparing with PGO only. Compared with a default build, a performance gain as high as 26% was observed from PGO+LTO. In addition, we are also seeing 2% boost in throughput rate from our OpenStack Swift setup comparing with PGO only. Our GUPB performance evaluation was conducted on Intel SkyLake/Broadwell systems running CentOS/Ubuntu, with CLANG/LLVM and GCC 4.*/5.*. Our OpenStack Swift performance was done on various systems consisting of XEON and Avoton processors.

Steps:
======

1. Get the CPython source codes
    hg clone https://hg.python.org/cpython cpython
    cd cpython
    hg update 2.7 (for CPython2)

2. Build the binary
    a) Default:
        ./configure
        make
    
    b) PGO:
        ./configure
        make profile-opt
        
    c) PGO+LTO:
        Copy the attached patch files
        hg import --no-commit lto-cpython3-v01.patch (for CPython3)
        hg import --no-commit lto-cpython2-v01.patch (for CPython2)
        ./configure
        make profile-opt

        
Hardware and OS Configuration
=============================
Hardware:           Intel XEON (Broadwell-DE) 8 Cores

BIOS settings:      Intel Turbo Boost Technology: false
                    Hyper-Threading: false                  

OS:                 Ubuntu 14.04.3 LTS Server

OS configuration:   Address Space Layout Randomization (ASLR) disabled to reduce run
                    to run variation by echo 0 > /proc/sys/kernel/randomize_va_space
                    CPU frequency set fixed at 2.6GHz

GCC version:        GCC version 4.9.2

Benchmark:          Grand Unified Python Benchmark from 
                    https://hg.python.org/benchmarks/

                    
Measurements and Results
========================
A. Repository:
    GUPB Benchmark:
        hg id :  2979f5ce6a0c tip
        hg --debug id -i : 2979f5ce6a0cee994d5485401945d8457bb0afac

    CPython3:
        hg id : 21a28f6de358
        hg id -r 'ancestors(.) and tag()': 374f501f4567 (3.5) v3.5.0
        hg --debug id -i : 21a28f6de3582833652c958b8fd6ae8448b61c7c

    CPython2:
        hg id : a37ea1d56e98 (2.7)
        hg id -r 'ancestors(.) and tag()': 15c95b7d81dc (2.7) v2.7.10
        hg --debug id -i : a37ea1d56e98eb158750d3e495a5cf524e8c3980


B. Results: 
CPython2 and CPython3 sample results, measured on a Broadwell platform, can be viewed in Table 1 and 2. On the first column (Benchmark) you can see the benchmark name, on the second (%D) the speedup compared with the default version and on the third column (%PGO) the speedup compared with just PGO; a higher value is better.

Table 1. CPython2 results:
Benchmark           %D      %PGO
--------------------------------
raytrace            18      3
chaos               16      5
django_v2           16      6
mako                16      6
pathlib             15      3
simple_logging      15      1
slowpickle          15      5
django              14      4
go                  14      4
richards            13      -1
float               12      4
slowunpickle        12      4
etree_process       11      3
fastunpickle        11      6
formatted_logging   11      3
nqueens             11      1
regex_compile       11      3
etree_iterparse     10      4
mako_v2             10      3
telco               10      5
pybench             9       1
hexiom2             9       1
html5lib_warmup     9       3
meteor_contest      9       4
pickle_list         9       5
2to3                8       2
bzr_startup         8       2
chameleon           8       0
etree_generate      8       2
regex_v8            8       3
silent_logging      8       1
fannkuch            7       1
html5lib            7       3
json_load           7       -5
tornado_http        7       3
call_method_slots   6       3
json_dump_v2        6       -4
spambayes           6       2
unpickle_list       6       0
etree_parse         5       3
fastpickle          5       4
rietveld            5       1
call_method         4       -1
normal_startup      4       2
startup_nosite      4       2
slowspitfire        3       0
ssbench             4       2
call_method_unknown 1       -6
json_dump           1       -4
nbody               1       1
pidigits            1       -10
pickle_dict         0       -1
regex_effbot        0       -2
spectral_norm       0       -3
call_simple         -3      -3
unpack_sequence     -6      -2


Table 2. CPython3 results:
Benchmark           %D      %PGO
--------------------------------
formatted_logging   26      11
raytrace            24      8
simple_logging      24      6
richards            22      3
chaos               21      7
go                  21      11
hexiom2             21      8
nbody               21      9
etree_generate      19      5
etree_process       19      5
call_method_slots   18      3
fastunpickle        18      0
pathlib             18      5
regex_compile       18      8
float               17      8
nqueens             17      7
call_method         16      3
etree_iterparse     16      9
json_dump           16      -4
json_load           16      5
silent_logging      15      8
2to3                14      5
fannkuch            14      8
call_simple         12      0
meteor_contest      12      7
call_method_unknown 11      -1
spectral_norm       11      4
json_dump_v2        10      3
telco               10      5
fastpickle          9       -4
etree_parse         8       1
normal_startup      8       3
startup_nosite      7       3
unpack_sequence     7       3
regex_v8            6       4
unpickle_list       5       3
pickle_list         1       -10
pidigits            1       -11
regex_effbot        -2      2
pickle_dict         -3      -10

Thank you,
Alecsandru

----------
components: Build
messages: 255140
nosy: alecsandru.patrascu
priority: normal
severity: normal
status: open
title: Link Time Optimizations support for GCC and CLANG
type: performance
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov 23 04:35:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 09:35:47 +0000
Subject: [New-bugs-announce] [issue25703] test_sys is failed if standard
 stream is redirected in 2.7
Message-ID: <1448271347.53.0.201659881218.issue25703@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When stdout or stderr (but not both) are redirected and PYTHONIOENCODING is not set, test_sys is failed in 2.7.

======================================================================
FAIL: test_43581 (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython2.7-debug/Lib/test/test_sys.py", line 415, in test_43581
    self.assertTrue(sys.__stdout__.encoding == sys.__stderr__.encoding)
AssertionError: False is not true

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

Can be reproduced by one of following commands:

$ ./python -m test.regrtest -v test_sys | cat
$ ./python -m test.regrtest -v test_sys 2>/dev/null

Proposed patch fixes the test.

----------
assignee: serhiy.storchaka
components: Tests
files: test_sys_test_43581.patch
keywords: patch
messages: 255142
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: test_sys is failed if standard stream is redirected in 2.7
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41132/test_sys_test_43581.patch

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

From report at bugs.python.org  Mon Nov 23 07:48:24 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 12:48:24 +0000
Subject: [New-bugs-announce] [issue25704] Update the documentation to 3.5
Message-ID: <1448282904.47.0.71490462116.issue25704@psf.upfronthosting.co.za>


Changes by St?phane Wirtel <stephane at wirtel.be>:


----------
components: Devguide
nosy: ezio.melotti, matrixise, willingc
priority: normal
severity: normal
status: open
title: Update the documentation to 3.5
versions: Python 3.6

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

From report at bugs.python.org  Mon Nov 23 08:05:25 2015
From: report at bugs.python.org (Florin Papa)
Date: Mon, 23 Nov 2015 13:05:25 +0000
Subject: [New-bugs-announce] [issue25705] Fix regex_compile benchmark crash
Message-ID: <1448283925.8.0.456132903966.issue25705@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi all,

This is Florin Papa from the Server Languages Optimizations Team at Intel Corporation.

The patch submitted here solves a crash occurring on Python 2.7 and 3.6 when running the regex_compile benchmark. The clear_cache() call was replaced with re.purge().

To apply the patch please follow these steps:

hg clone https://hg.python.org/benchmarks
cd benchmarks/
copy fix_regex_compile.patch to the current directory
hg import --no-commit fix_regex_compile.patch

Thank you,
Florin Papa

----------
components: Benchmarks
files: fix_regex_compile.patch
keywords: patch
messages: 255152
nosy: brett.cannon, florin.papa, pitrou
priority: normal
severity: normal
status: open
title: Fix regex_compile benchmark crash
type: crash
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41136/fix_regex_compile.patch

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

From report at bugs.python.org  Mon Nov 23 08:29:19 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Mon, 23 Nov 2015 13:29:19 +0000
Subject: [New-bugs-announce] [issue25706] problems in library/base64.rst
Message-ID: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>


New submission from hiroaki itoh:

* default of ignorechars for a85decode
    b' tnrv' should be b' \t\n\r\v'
* explanation of newline for a85encode
    "newline('n')" should be "newline('\n')"

----------
assignee: docs at python
components: Documentation
messages: 255155
nosy: docs at python, xwhhsprings
priority: normal
severity: normal
status: open
title: problems in library/base64.rst
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 23 08:57:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 13:57:25 +0000
Subject: [New-bugs-announce] [issue25707] Add the close method for
 ElementTree.iterparse() object
Message-ID: <1448287045.22.0.0931965485798.issue25707@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

If ElementTree.iterparse() is called with file names, it opens a file. When resulting iterator is not exhausted, the file lefts not closed.

>>> import xml.etree.ElementTree as ET
>>> import gc
>>> ET.iterparse('/dev/null')
<xml.etree.ElementTree._IterParseIterator object at 0xb6f9e38c>
>>> gc.collect()
__main__:1: ResourceWarning: unclosed file <_io.BufferedReader name='/dev/null'>
34

Martin Panter proposed in issue25688 to add an explicit way to clean it up, like a generator.close() method.

----------
assignee: serhiy.storchaka
components: Library (Lib)
messages: 255159
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add the close method for ElementTree.iterparse() object
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Mon Nov 23 09:49:24 2015
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 23 Nov 2015 14:49:24 +0000
Subject: [New-bugs-announce] [issue25708] runpy hides traceback for some
 exceptions
Message-ID: <1448290164.96.0.435205932558.issue25708@psf.upfronthosting.co.za>


New submission from Cal Leeming:

Originally posted here:
http://stackoverflow.com/q/33873243/1267398

The problem is caused by this line:

    # For -m switch, just display the exception
    info = str(exc)

Caused by the following commit in 2008;
https://mail.python.org/pipermail/python-checkins/2008-February/066256.html

The commit states;
"Try to make command line error messages from runpy easier to understand (and suppress traceback cruft from the implicitly invoked runpy machinery)"

However by suppressing the traceback it's now impossible to debug what caused the error when running with `runpy` without wrapping the entire `__init__.py` with your own try/except statement.

I'd like to propose either displaying the full traceback by default, or adding a CLI option to enable it at runtime. The fact that it only suppresses *some* tracebacks and not all is a flawed approach surely?

Thoughts?

----------
components: Interpreter Core
messages: 255169
nosy: ncoghlan, sleepycal
priority: normal
severity: normal
status: open
title: runpy hides traceback for some exceptions
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 23 09:57:19 2015
From: report at bugs.python.org (=?utf-8?b?w4FycMOhZCBLw7NzYQ==?=)
Date: Mon, 23 Nov 2015 14:57:19 +0000
Subject: [New-bugs-announce] [issue25709] greek alphabet bug it is very
 disturbing...
Message-ID: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>


New submission from ?rp?d K?sa:

One of my students found this bug. For ascii characters it works as you expect, but for greek alphabet it works unexpectedly.
The program works correctly for Python 3.2.x but for 3.4.x and 3.5 it gives erroneous result.

----------
files: greekbug.py
messages: 255172
nosy: ?rp?d K?sa
priority: normal
severity: normal
status: open
title: greek alphabet bug it is very disturbing...
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41139/greekbug.py

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

From report at bugs.python.org  Mon Nov 23 10:44:56 2015
From: report at bugs.python.org (Robert Byrnes)
Date: Mon, 23 Nov 2015 15:44:56 +0000
Subject: [New-bugs-announce] [issue25710] zipimport is not PEP 3147 or PEP
 488 compliant
Message-ID: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za>


New submission from Robert Byrnes:

zipimport is not PEP 3147 compliant: i.e., it looks for foo.pyc (in the same directory as foo.py) instead of __pycache__/foo.cpython-35.pyc.  This is counterintuitive, and unfortunate because it means that installation directories (that obey PEP 3147 conventions) can't be zip archived from filesystems and then used by zipimport.

When support for PEP 488 was added to Python 3.5, zipimport was modified to just delete references to .pyo files, but it needs to know about the new .opt-[12] filename components (as well as the PEP 3147 version tags).  As far as I can tell, the current version of zipimport can't import optimized bytecode files, using either the old or new filename conventions.

Finally, none of this behavior is documented.  The zipimport docs still mention .pyo files (which were eliminated by PEP 488), and say nothing about the filename conventions expected within zip archives.

----------
components: Extension Modules
messages: 255178
nosy: byrnes
priority: normal
severity: normal
status: open
title: zipimport is not PEP 3147 or PEP 488 compliant
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Nov 23 11:28:40 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Nov 2015 16:28:40 +0000
Subject: [New-bugs-announce] [issue25711] Rewrite zipimport from scratch
Message-ID: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>


New submission from Brett Cannon:

No one wants to work on zipimport, and yet it's full of bugs. It needs a rewrite so that it's more maintainable. An idea floated at PyCon 2015 was to writing the zip-reading code in C and to keep it as simple as possible -- e.g., don't worry about supporting comments, etc. -- and then write the rest of the code in importlib, making maintenance much easier.

All of the various zipimport bugs should be made dependent on this issue as unless they are critical flaws I doubt they will get fixed without the rewrite.

----------
components: Interpreter Core
messages: 255183
nosy: brett.cannon, gregory.p.smith, twouters
priority: high
severity: normal
status: open
title: Rewrite zipimport from scratch
versions: Python 3.6

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

From report at bugs.python.org  Mon Nov 23 11:40:36 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 16:40:36 +0000
Subject: [New-bugs-announce] [issue25712] Dead link in the PEP-3147
Message-ID: <20151123164034.GF15060@sg1>


New submission from St?phane Wirtel:

In the PEP-3147, there is a link to the marshal library.
The link is dead because we get a 404 HTTP error.

https://www.python.org/dev/peps/pep-3147/

The link is [2] : https://www.python.org/doc/current/library/marshal.html
but the link gives a 404

----------
messages: 255189
nosy: matrixise
priority: normal
severity: normal
status: open
title: Dead link in the PEP-3147

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

From report at bugs.python.org  Mon Nov 23 13:06:00 2015
From: report at bugs.python.org (James Paget)
Date: Mon, 23 Nov 2015 18:06:00 +0000
Subject: [New-bugs-announce] [issue25713] Setuptools included with 64-bit
 Windows installer is outdated
Message-ID: <1448301960.52.0.82472871794.issue25713@psf.upfronthosting.co.za>


New submission from James Paget:

This applies to Python 3.5.1rc1 only.  The Windows 64-bit standalone installer installs setuptools 18.2, but the latest version is 18.5.  It should be noted that the Python 2.7.11rc1 Windows 64-bit standalone installer installs setuptools 18.5.  Other Python 3.5.1.rc1 installers (web based, or for other platforms) may have this problem as well, but I have not tried them out.

----------
components: Extension Modules
messages: 255208
nosy: James.Paget
priority: normal
severity: normal
status: open
title: Setuptools included with 64-bit Windows installer is outdated
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 23 13:42:19 2015
From: report at bugs.python.org (Matt Bogosian)
Date: Mon, 23 Nov 2015 18:42:19 +0000
Subject: [New-bugs-announce] [issue25714] Consider isinstance(...,
 numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int,
 long)) in datetime.py
Message-ID: <1448304139.86.0.253570018979.issue25714@psf.upfronthosting.co.za>


New submission from Matt Bogosian:

datetime.py is peppered with ``assert`` statements that are two restrictive. Specifically, ``isinstance(..., int)`` does not afford compatibility with alternate ``int``-like implementations (e.g., ``future.types.newint``). Some background:

* https://github.com/PythonCharmers/python-future/issues/187
* https://bitbucket.org/pypy/pypy/issues/2193/datetimetimedelta-chokes-on-seconds

In all cases that I can find, ``assert isinstance(..., int)`` is unnecessarily restrictive, since it is always followed by another ``assert`` which validates that the boundaries are far smaller than a Python 2 native `int` type. (See, e.g., `datetype.py at line 395 <https://hg.python.org/cpython/file/ebec1a98ab81/Lib/datetime.py#l395>`__).

I propose replacing instances of ``assert isinstance(..., int)`` and ``assert isinstance(..., (int, long))`` with ``assert isinstance(..., numbers.Integral)`` akin to `this patch <https://bitbucket.org/pypy/pypy/pull-requests/361/fix-2193/diff>`__.

----------
components: Library (Lib)
messages: 255211
nosy: posita
priority: normal
severity: normal
status: open
title: Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 23 15:24:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 23 Nov 2015 20:24:42 +0000
Subject: [New-bugs-announce] [issue25715] Python 3.5.1 installer shows wrong
 upgrade path
Message-ID: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za>


New submission from Steve Dower:

When launching the installer to upgrade from a Python 3.5.0 install to 3.5.1, the path shown on the Install button is incorrect. Clicking the button installs to the correct location.

This is a regression from 3.5.0 that will cause a lot of confusion. It ought to be fixed.

----------
assignee: steve.dower
components: Installation, Windows
keywords: 3.5regression
messages: 255219
nosy: larry, paul.moore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Python 3.5.1 installer shows wrong upgrade path
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov 23 17:44:39 2015
From: report at bugs.python.org (Myron Walker)
Date: Mon, 23 Nov 2015 22:44:39 +0000
Subject: [New-bugs-announce] [issue25716] typeobject.c call_method &
 call_maybe can leak references on 'func'
Message-ID: <1448318679.04.0.579867693106.issue25716@psf.upfronthosting.co.za>


New submission from Myron Walker:

The 'call_method' and 'call_maybe' function in typeobject.c are leaking
a reference on 'func' in cases where 'args == NULL'.  In this case both 
of these functions exit like so:

    if (args == NULL)
        return NULL;

When they need to do:

    if (args == NULL)
    {
        Py_DECREF(func);
        return NULL;
    }

----------
components: Interpreter Core
messages: 255235
nosy: Myron Walker
priority: normal
severity: normal
status: open
title: typeobject.c call_method & call_maybe can leak references on 'func'
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 23 23:23:44 2015
From: report at bugs.python.org (Hans Lawrenz)
Date: Tue, 24 Nov 2015 04:23:44 +0000
Subject: [New-bugs-announce] [issue25717] tempfile.TemporaryFile fails when
 dir option set to directory residing on host OS mount
Message-ID: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za>


New submission from Hans Lawrenz:

Inside a virtualbox vm, calling tempfile.TemporaryFile(dir=foo) where foo is a directory which resides on a volume mounted from the host OS, a FileNotFoundError exception is thrown.

In the following code sample, the second block will print "Path 2: ERROR" on Python 3.5 but not on 3.4 or 2.7 (assuming the vagrant environment provided below):

import tempfile


try:
    with tempfile.TemporaryFile() as tf:
        tf.write("testing testing testing\n".encode('utf-8'))
    print("Path 1: worked")
except FileNotFoundError as e:
    print("Path 1: ERROR")

try:
    with tempfile.TemporaryFile(dir="/vagrant") as tf:
        tf.write("testing testing testing\n".encode('utf-8'))
    print("Path 2: worked")
except FileNotFoundError as e:
    print("Path 2: ERROR")


A runnable test case can be found here:
https://github.com/hlawrenz/py35tempfiletest

----------
components: Library (Lib)
messages: 255246
nosy: Hans Lawrenz
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov 24 03:07:23 2015
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 24 Nov 2015 08:07:23 +0000
Subject: [New-bugs-announce] [issue25718] itertools.accumulate
 __reduce__/__setstate__ bug
Message-ID: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za>


New submission from Armin Rigo:

itertools.accumulate() has got methods __reduce__() and __setstate__() which fail at saving/restoring the state in all cases.  Example:

   >>> a = itertools.accumulate([0.0, 42])
   >>> next(a)
   0.0
   >>> b = copy.deepcopy(a)
   >>> next(a)
   42.0
   >>> next(b)
   42           # should have been the same as the previous result

More precisely, the problem occurs when the C-level "total" field has some value whose truth-value is false.  Then __reduce__/__setstate__ will not restore the value of this field, but keep it NULL.  That's why in the example above the intermediate total of 0.0 is forgotten, and the next(b) call will again just pick the next value without doing any addition.  (The problem can hurt more than in this example if we use a custom function instead of addition.)

A fix is easy but, as far as I can tell, it requires breaking the pickled format of accumulate() iterators that have already started.

----------
components: Extension Modules
messages: 255252
nosy: arigo
priority: normal
severity: normal
status: open
title: itertools.accumulate __reduce__/__setstate__ bug
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 24 05:54:19 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 24 Nov 2015 10:54:19 +0000
Subject: [New-bugs-announce] [issue25719] Deprecate spitfire benchmark
Message-ID: <1448362459.17.0.918374944074.issue25719@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi all,

This is Florin Papa from the Server Languages Optimizations Team at Intel Corporation.

The patch submitted here deprecates the spitfire benchmark, which uses psyco. Psyco is "unmaintained and dead", according to their website (http://psyco.sourceforge.net/) and it has not received any updates since 2012. The spitfire benchmark crashes because psyco does not have support for x64 architectures.

To apply the patch please follow these steps:

hg clone https://hg.python.org/benchmarks
cd benchmarks/
copy deprecate_spitfire.patch to the current directory
hg import --no-commit deprecate_spitfire.patch

Thank you,
Florin Papa

----------
components: Benchmarks
files: deprecate_spitfire.patch
keywords: patch
messages: 255260
nosy: brett.cannon, florin.papa, pitrou
priority: normal
severity: normal
status: open
title: Deprecate spitfire benchmark
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file41147/deprecate_spitfire.patch

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

From report at bugs.python.org  Tue Nov 24 06:39:08 2015
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 24 Nov 2015 11:39:08 +0000
Subject: [New-bugs-announce] [issue25720] Fix curses module compilation with
 ncurses6
Message-ID: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za>


New submission from Ismail Donmez:

ncurses6 turned on NCURSES_OPAQUE, so now you have to use some helper functions instead of accessing the structs directly. This _should_ be compatible with ncurses5 though I didn't test it.

Original patch is from openSUSE.

----------
components: Extension Modules
files: curses-ncurses6.patch
keywords: patch
messages: 255261
nosy: donmez
priority: normal
severity: normal
status: open
title: Fix curses module compilation with ncurses6
versions: Python 3.5
Added file: http://bugs.python.org/file41148/curses-ncurses6.patch

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

From report at bugs.python.org  Tue Nov 24 07:06:23 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 24 Nov 2015 12:06:23 +0000
Subject: [New-bugs-announce] [issue25721] Fix pybench always_display error
Message-ID: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi all,

This is Florin Papa from the Server Languages Optimizations Team at Intel Corporation.

The patch submitted here solves a crash occurring on Python 2.7 after running pybench from perf.py (python perf.py -r -b pybench base_python modified_python). The error appears when trying to display the results of the run because the PyBenchBenchmarkResult class does not include the attribute "always_display".

Here is the error message received:
File "../benchmarks/perf.py", line 2574, in main
    if result.always_display:
AttributeError: 'PyBenchBenchmarkResult' object has no attribute 'always_display'

To apply the patch please follow these steps:

hg clone https://hg.python.org/benchmarks
cd benchmarks/
copy fix_pybench_results.patch to the current directory
hg import --no-commit fix_pybench_results.patch

Thank you,
Florin Papa

----------
components: Benchmarks
messages: 255262
nosy: brett.cannon, florin.papa, pitrou
priority: normal
severity: normal
status: open
title: Fix pybench always_display error
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov 24 08:37:38 2015
From: report at bugs.python.org (Alexander Todorov)
Date: Tue, 24 Nov 2015 13:37:38 +0000
Subject: [New-bugs-announce] [issue25722] Lib/ssl.py breaks certificate
 validation for wildcard domains, e.g. *.s3.amazonaws.com
Message-ID: <1448372258.01.0.348498754399.issue25722@psf.upfronthosting.co.za>


New submission from Alexander Todorov:

The latest ssl.py file tries to validate hostnames vs certificates but includes a faulty regexp which causes any wildcard domains (e.g. *.s3.amazonaws.com) to fail validation. 

Steps to Reproduce:
>>> import ssl
>>> ssl._dnsname_match("*.s3.amazonaws.com", "planet.sofiavalley.com.s3.amazonaws.com")
>>> 

>From Python's documentation:

[]

    Used to indicate a set of characters. In a set:

...
        Special characters lose their special meaning inside sets. For example, [(+*)] will match any of the literal characters '(', '+', '*', or ')'.


^^^^^^^^^ this is the cause of the error

I've found this after an upgrade to RHEL 7.2 which contains the faulty code broke s3cmd for me. The result - one of my sites was outdated for a couple of days.

For more info and proposed patch see:
https://bugzilla.redhat.com/show_bug.cgi?id=1284916
https://bugzilla.redhat.com/show_bug.cgi?id=1284930

Note: As far as I can tell this affects upstream Python 2.7.10 and 3.5.0, however in the packages Red Hat distributes the code is different between 2 and 3 while upstream is more consistent.

----------
messages: 255265
nosy: Alexander Todorov
priority: normal
severity: normal
status: open
title: Lib/ssl.py breaks certificate validation for wildcard domains, e.g. *.s3.amazonaws.com
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Tue Nov 24 10:31:44 2015
From: report at bugs.python.org (SpaceOne)
Date: Tue, 24 Nov 2015 15:31:44 +0000
Subject: [New-bugs-announce] [issue25723] ConfigParser should never write
 broken configurations
Message-ID: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za>


New submission from SpaceOne:

>>> from configparser import ConfigParser
>>> from io import StringIO
>>> from configparser import ConfigParser
>>> c = ConfigParser()
>>> c.add_section('foo]\nbar=baz\n[bar')
>>> fd = StringIO()
>>> c.write(fd)
>>> print(fd.getvalue())
[foo]
bar=baz
[bar]

User input should always be validated.

At least a ValueError should be raised if add_section() is called with a string containing anything like ']\x00\n[' or any other non-printable string. As this will always create a broken configuration or might lead to ini-injections.

Otherwise ConfigParser cannot be used to write new config files without having deeper knowledge about the implementation.

See also:
http://bugs.python.org/issue23301
http://bugs.python.org/issue20923

----------
components: Library (Lib)
messages: 255270
nosy: spaceone
priority: normal
severity: normal
status: open
title: ConfigParser should never write broken configurations
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/issue25723>
_______________________________________

From report at bugs.python.org  Tue Nov 24 10:44:59 2015
From: report at bugs.python.org (Marc Deslauriers)
Date: Tue, 24 Nov 2015 15:44:59 +0000
Subject: [New-bugs-announce] [issue25724] SSLv3 test failure on Ubuntu 16.04
 LTS
Message-ID: <1448379899.26.0.590688499284.issue25724@psf.upfronthosting.co.za>


New submission from Marc Deslauriers:

In order to disable SSLv3 in OpenSSL without breaking ABI, Ubuntu 16.04 LTS will ship with OP_NO_SSLv3 forced on by default.

This is causing the test_ssl.py test to fail.
Attached is a patch to fix the issue.

----------
components: Tests
files: fix-sslv3-test.diff
keywords: patch
messages: 255274
nosy: mdeslaur
priority: normal
severity: normal
status: open
title: SSLv3 test failure on Ubuntu 16.04 LTS
versions: Python 3.5
Added file: http://bugs.python.org/file41150/fix-sslv3-test.diff

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

From report at bugs.python.org  Tue Nov 24 15:49:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Nov 2015 20:49:41 +0000
Subject: [New-bugs-announce] [issue25725] Memory leak on unpickling bogus
 data
Message-ID: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

New tests added in issue23914 exposed memory leak on unpickling TUPLE1..TUPLE3 opcodes with insufficient stack. Proposed patch fixes the leak.

----------
assignee: serhiy.storchaka
components: Library (Lib)
keywords: patch
messages: 255289
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Memory leak on unpickling bogus data
type: resource usage
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41154/load_counted_tuple_leak.patch

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

From report at bugs.python.org  Tue Nov 24 18:04:27 2015
From: report at bugs.python.org (Stefan Seefeld)
Date: Tue, 24 Nov 2015 23:04:27 +0000
Subject: [New-bugs-announce] [issue25726] sys.setprofile / sys.getprofile
 asymetry
Message-ID: <1448406267.14.0.484592445826.issue25726@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

I'm using the `cProfile` module to profile my code.

I tried to temporarily disable the profiler by using:

  prof = sys.getprofile()
  sys.setprofile(None)
  ...
   sys.setprofile(prof)

resulting in an error.

The reason is that with `cProfile`, `sys.getprofile` returns the profile object itself, which isn't suitable as argument for `sys.setprofile` (which expects a callable).

Notice that if I use the `profile` module instead of `cProfile`, the above works fine.

----------
messages: 255301
nosy: stefan
priority: normal
severity: normal
status: open
title: sys.setprofile / sys.getprofile asymetry
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 24 18:46:04 2015
From: report at bugs.python.org (Elizabeth Myers)
Date: Tue, 24 Nov 2015 23:46:04 +0000
Subject: [New-bugs-announce] [issue25727] os.startfile implementation for
 other OS'es besides Windows
Message-ID: <1448408764.04.0.983609943062.issue25727@psf.upfronthosting.co.za>


New submission from Elizabeth Myers:

os.startfile can be implemented on other OS'es besides Windows relatively easily (although the operation parameter should probably be limited to Windows; it can be implemented elsewhere, but is probably not worth the trouble).

On Unix-like operating systems besides OS X, an attempt to use xdg-open can be used and will attempt to open the file in a chosen program; this is the freedesktop.org standard open utility. See also http://linux.die.net/man/1/xdg-open and https://wiki.archlinux.org/index.php/Xdg-open (not specific to ArchLinux).

On OS X, open can be used, with similar results to xdg-open (in fact, xdg-open seems inspired by it). See also https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html.

----------
components: Library (Lib)
messages: 255306
nosy: Elizacat
priority: normal
severity: normal
status: open
title: os.startfile implementation for other OS'es besides Windows
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 24 19:04:36 2015
From: report at bugs.python.org (Forest)
Date: Wed, 25 Nov 2015 00:04:36 +0000
Subject: [New-bugs-announce] [issue25728] email parser ignores inner
 multipart boundary when outer message duplicates it
Message-ID: <1448409876.66.0.930152855615.issue25728@psf.upfronthosting.co.za>


New submission from Forest:

When a multipart message erroneously defines a boundary string that conflicts with an inner message's boundary string, the parser ignores the (correct) inner message's boundary, and treats all matching boundary lines as if they belong to the (defective) outer message.

This file from the test_email suite demonstrates the problem:
Python-3.5.0/Lib/test/test_email/data/msg_15.txt

Consequentially, the inner multipart/alternative message is parsed with is_multipart() returning False, and a truncated payload.

Moreover, unit tests like test_same_boundary_inner_outer() expect to find the StartBoundaryNotFoundDefect defect on the inner message in that file, which seems wrong to me, since the inner message is not defective.  According to the RFCs, the outer message should have been generated with a boundary string that does not appear anywhere in its encoded body (including the inner message).  The outer message is therefore the defective one.

----------
components: email
messages: 255309
nosy: barry, forest, r.david.murray
priority: normal
severity: normal
status: open
title: email parser ignores inner multipart boundary when outer message duplicates it
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Nov 25 02:52:26 2015
From: report at bugs.python.org (Brian Kearns)
Date: Wed, 25 Nov 2015 07:52:26 +0000
Subject: [New-bugs-announce] [issue25729] update pure python
 datetime.timedelta creation
Message-ID: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za>


New submission from Brian Kearns:

Brings timedelta creation up to par with the (simpler) C equivalent. Gives a nice speed boost on the pure-py version (not worth much on CPython but useful on other implementations like PyPy).

Included in a few other small bug fixes/cleanups, should be self-explanatory.

----------
files: timedelta.patch
keywords: patch
messages: 255322
nosy: bdkearns
priority: normal
severity: normal
status: open
title: update pure python datetime.timedelta creation
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41158/timedelta.patch

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

From report at bugs.python.org  Wed Nov 25 05:47:41 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Wed, 25 Nov 2015 10:47:41 +0000
Subject: [New-bugs-announce] [issue25730] invisible sidebar content with
 code snippets
Message-ID: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>


New submission from hiroaki itoh:

I think this is maybe known problem, but checking duplication of this issue is very hard because searching it with keyword 'sidebar' hit too many.

Please see details in https://bitbucket.org/hhsprings/nothing.but.only.for.some.kind.of.collabo/wiki/%5Bdocs.python.org%5D%20invisible%20sidebar%20content%20with%20code%20snippets .

I think, this can be fixed by inserting style overriding background to default.css.

----------
messages: 255334
nosy: xwhhsprings
priority: normal
severity: normal
status: open
title: invisible sidebar content with code snippets
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/issue25730>
_______________________________________

From report at bugs.python.org  Wed Nov 25 07:29:50 2015
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Skonieczny_=28Uosiu=29?=)
Date: Wed, 25 Nov 2015 12:29:50 +0000
Subject: [New-bugs-announce] [issue25731] Assigning and deleting __new__
 attr on the class does not allow to create instances of this class
Message-ID: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>


New submission from Stanis?aw Skonieczny (Uosiu):

When moving from python 2.7 to 3.5 I have found a problem with patching __new__ method on the class. It was done this way:
'''
patch('foo.bar.MyClass.__new__', return_value=mocked_instance)
'''
In works with python 2.7, but in 3.5 it fails with:
'''
TypeError: object() takes no parameters
'''

I have created minimal scenario that ilustrates this bug cause:
'''
class X:
    def __init__(self, a):
        pass


def new(cls, a):
    pass


X(1)
X.__new__ = new
X(1)
del X.__new__
X(1)
'''
Setting __new__ attribute and then deleting it has some side effect.

----------
components: Interpreter Core
files: new_patch_fails.py
messages: 255337
nosy: Stanis?aw Skonieczny (Uosiu)
priority: normal
severity: normal
status: open
title: Assigning and deleting __new__ attr on the class does not allow to create instances of this class
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41161/new_patch_fails.py

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

From report at bugs.python.org  Wed Nov 25 08:12:49 2015
From: report at bugs.python.org (David Seddon)
Date: Wed, 25 Nov 2015 13:12:49 +0000
Subject: [New-bugs-announce] [issue25732] functools.total_ordering does not
 correctly implement not equal behaviour
Message-ID: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za>


New submission from David Seddon:

The documentation for functools.total_ordering states that rich comparison can be enabled on a class by specifying an __eq__ method, and one of __lt__(), __le__(), __gt__(), or __ge__().  If these instructions are followed, this results in an incorrect evaluation of the not equal operator:

Here's an example:

    from functools import total_ordering

    @total_ordering
    class Value(object):

        def __init__(self, value):
            self.value = value
    
        def __eq__(self, other):
            return self.value == other.value
    
        def __lt__(self, other):
            return self.value < other.value

 
    >>> a = Value(3)
    >>> b = Value(3)
    >>> a == b
    True
    >>> a != b
    True

I've tested this on 2.7.10.
 
Either the documentation or the behaviour should be corrected.

https://docs.python.org/2/library/functools.html#functools.total_ordering

----------
messages: 255339
nosy: David Seddon
priority: normal
severity: normal
status: open
title: functools.total_ordering does not correctly implement not equal behaviour
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 25 09:26:38 2015
From: report at bugs.python.org (ppperry)
Date: Wed, 25 Nov 2015 14:26:38 +0000
Subject: [New-bugs-announce] [issue25733] Idle does not handle non-standard
 compile errors
Message-ID: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za>


New submission from ppperry:

The following code:
for a in range(26):
  for b in range(26):
   for c in range(26):
    for d in range(26):
     for e in range(26):
      for f in range(26):
       for g in range(26):
        for h in range(26):
         for i in range(26):
          for j in range(26):
           for k in range(26):
            for l in range(26):
             for m in range(26):
              for o in range(26):
               for p in range(26):
                for q in range(26):
                 for r in range(26):
                  for s in range(26):
                   for t in range(26):
                    for u in range(26):
                     for v in range(26):
                       for w in range(26):
                         pass

fails to compile with `SystemError: too many statically nested blocks` when typed in the standard interpreter.

When typed in an IDLE shell , pressing enter will not try to run the code, instead printing the SystemError to the console from which idle was started, instead of to the IDLE shell, which would be expected.

----------
components: IDLE, Interpreter Core
messages: 255358
nosy: ppperry
priority: normal
severity: normal
status: open
title: Idle does not handle non-standard compile errors
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 25 09:43:46 2015
From: report at bugs.python.org (Alberto Galera)
Date: Wed, 25 Nov 2015 14:43:46 +0000
Subject: [New-bugs-announce] [issue25734] fnmatch regular expression can be
 improved
Message-ID: <1448462626.73.0.555480375618.issue25734@psf.upfronthosting.co.za>


New submission from Alberto Galera:

# https://hg.python.org/cpython/file/tip/Lib/fnmatch.py
fnmatch reviewing the code I've noticed that the outcome of the regular expression all returns generated in the first result

l97:
            res = res + '.*'
to:
            res = res + '.*?'

l100:
    return res + '\Z(?ms)'
to:
    return res + '$(?ms)'


example test:

import re
import fnmatch

urls = ['example/l1/l2/test3-1.py',
        'example/l1/test2-1.py',
        'example/l1/test2-2.py',
        'example/l1/l2/l3/test4-1.py']

regex = fnmatch.translate('example/*')
# 'example\\/.*\\Z(?ms)'
re.findall(regex, "\n".join(urls))
# return ['example/l1/l2/test3-1.py\nexample/l1/test2-1.py\nexample/l1/test2-2.py\nexample/l1/l2/l3/test4-1.py']

# suggested change 
re.findall('example\\/.*?$(?ms)', "\n".join(urls))
# return ['example/l1/l2/test3-1.py',
#         'example/l1/test2-1.py',
#         'example/l1/test2-2.py',
#         'example/l1/l2/l3/test4-1.py']

----------
components: Library (Lib)
messages: 255361
nosy: Alberto Galera
priority: normal
severity: normal
status: open
title: fnmatch regular expression can be improved
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 25 14:44:31 2015
From: report at bugs.python.org (John Yeung)
Date: Wed, 25 Nov 2015 19:44:31 +0000
Subject: [New-bugs-announce] [issue25735] math.factorial doc should mention
 integer return type
Message-ID: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>


New submission from John Yeung:

The math module docs state

Except when explicitly noted otherwise, all return values are floats.

But math.factorial isn't what I would call explicit about returning int:

math.factorial(x)
    Return x factorial. Raises ValueError if x is not integral or is negative.

At minimum, shouldn't the first sentence be "Return x factorial as an int."? I haven't tested on all Python versions, but math.factorial on 2.7 and 3.2 definitely return int (or long in Python 2 when necessary).

----------
assignee: docs at python
components: Documentation
messages: 255382
nosy: John.Yeung, docs at python
priority: normal
severity: normal
status: open
title: math.factorial doc should mention integer return type
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 26 02:42:20 2015
From: report at bugs.python.org (=?utf-8?q?Ervin_Heged=C3=BCs?=)
Date: Thu, 26 Nov 2015 07:42:20 +0000
Subject: [New-bugs-announce] [issue25736] smtplib can't send 8bit encoded
 utf-8 message
Message-ID: <1448523740.68.0.442451319254.issue25736@psf.upfronthosting.co.za>


Changes by Ervin Heged?s <airween at gmail.com>:


----------
nosy: airween
priority: normal
severity: normal
status: open
title: smtplib can't send 8bit encoded utf-8 message
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 26 06:34:09 2015
From: report at bugs.python.org (berdario)
Date: Thu, 26 Nov 2015 11:34:09 +0000
Subject: [New-bugs-announce] [issue25737] array is not a Sequence
Message-ID: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za>


New submission from berdario:

>>> from array import array
>>> from collections.abc import Sequence
>>> isinstance(array('I', [1]), Sequence)
False

----------
components: Interpreter Core
messages: 255413
nosy: berdario
priority: normal
severity: normal
status: open
title: array is not a Sequence
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 26 19:26:18 2015
From: report at bugs.python.org (SpaceOne)
Date: Fri, 27 Nov 2015 00:26:18 +0000
Subject: [New-bugs-announce] [issue25738] http.server doesn't handle RESET
 CONTENT status correctly
Message-ID: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za>


New submission from SpaceOne:

The status 205 RESET CONTENT is not correctly evaluated by http.server.
It MUST NOT write a response body to the client.
 
Patch: https://github.com/spaceone/cpython/commit/17048e2e7349cc4861c7fe90299f2c092b8e1604

----------
components: Library (Lib)
messages: 255443
nosy: spaceone
priority: normal
severity: normal
status: open
title: http.server doesn't handle RESET CONTENT status correctly

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

From report at bugs.python.org  Thu Nov 26 19:30:04 2015
From: report at bugs.python.org (SpaceOne)
Date: Fri, 27 Nov 2015 00:30:04 +0000
Subject: [New-bugs-announce] [issue25739] Add PAYLOAD_TOO_LARGE (new name in
 RFC 7231)
Message-ID: <1448584204.43.0.941086994375.issue25739@psf.upfronthosting.co.za>


New submission from SpaceOne:

Add PAYLOAD_TOO_LARGE status code to http package.
Patch: https://github.com/spaceone/cpython/commit/5d9427a07bde43b523386322b1fc377618eadb76

----------
components: Library (Lib)
messages: 255444
nosy: spaceone
priority: normal
severity: normal
status: open
title: Add PAYLOAD_TOO_LARGE (new name in RFC 7231)

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

From report at bugs.python.org  Thu Nov 26 19:35:22 2015
From: report at bugs.python.org (SpaceOne)
Date: Fri, 27 Nov 2015 00:35:22 +0000
Subject: [New-bugs-announce] [issue25740] multiple issues in http.client
Message-ID: <1448584522.19.0.187814376378.issue25740@psf.upfronthosting.co.za>


New submission from SpaceOne:

* RESET_CONTENT not evaluated
* negative chunk size accepted
* invalid ports accepted
* success status !== 200 ignored

Patch: https://github.com/spaceone/cpython/commit/3289080306408db971f8b816d3e9f0ab44ed392b

Part of github Pull Request https://github.com/python/cpython/pull/19 from July. Should I split this up into multiple bugtracker issues?

----------
components: Library (Lib)
messages: 255445
nosy: spaceone
priority: normal
severity: normal
status: open
title: multiple issues in http.client

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

From report at bugs.python.org  Fri Nov 27 04:24:04 2015
From: report at bugs.python.org (Firat Ozgul)
Date: Fri, 27 Nov 2015 09:24:04 +0000
Subject: [New-bugs-announce] [issue25741] Usual Installation Directory
Message-ID: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>


New submission from Firat Ozgul:

Official documentation reads: "On Windows machines, the Python installation is usually placed in C:\Python35"

However, as of Python 3.5.0, usual installation directory on Windows is %LOCALAPPDATA%\Programs\Python.

----------
assignee: docs at python
components: Documentation
messages: 255455
nosy: docs at python, firatozgul
priority: normal
severity: normal
status: open
title: Usual Installation Directory
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 27 09:54:09 2015
From: report at bugs.python.org (tierlieb)
Date: Fri, 27 Nov 2015 14:54:09 +0000
Subject: [New-bugs-announce] [issue25742] locale.setlocale does not work
 with unicode strings
Message-ID: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za>


New submission from tierlieb:

Within locale.py in setlocale your have this piece of code:

    if locale and type(locale) is not type(""):
        # convert to string
        locale = normalize(_build_localename(locale))

That does not work with unicode strings as I found out after wondering quite a bit about the difference was between my tests and my production code...

So either expand the check here to include type(u"") or make _build_localename smarter.

----------
components: Unicode
messages: 255461
nosy: ezio.melotti, haypo, tierlieb
priority: normal
severity: normal
status: open
title: locale.setlocale does not work with unicode strings
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 27 10:50:58 2015
From: report at bugs.python.org (Zack Weinberg)
Date: Fri, 27 Nov 2015 15:50:58 +0000
Subject: [New-bugs-announce] [issue25743] Clarify exactly what \w matches in
 UNICODE mode
Message-ID: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za>


New submission from Zack Weinberg:

The `re` module documentation does not do a good job of explaining exactly what `\w` matches.  Quoting https://docs.python.org/3.5/library/re.html :

> \w
> For Unicode (str) patterns:
> Matches Unicode word characters; this includes most characters
> that can be part of a word in any language, as well as numbers
> and the underscore.

Empirically, this appears to mean "everything in Unicode general categories L* and N*, plus U+005F (underscore)".  That is a perfectly sensible definition and the documentation should state it in those terms.  "Unicode word characters" could mean any number of different things; note for instance that UTS#18 gives a very different definition.

(Further reading: https://gist.github.com/zackw/3077f387591376c7bf67 plus links therefrom).

----------
assignee: docs at python
components: Documentation
messages: 255463
nosy: docs at python, zwol
priority: normal
severity: normal
status: open
title: Clarify exactly what \w matches in UNICODE mode
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/issue25743>
_______________________________________

From report at bugs.python.org  Fri Nov 27 13:04:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 18:04:18 +0000
Subject: [New-bugs-announce] [issue25744] Reference leaks in test_collections
Message-ID: <1448647458.47.0.750758594214.issue25744@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -uall -R 3:3 test_collections
[1/1] test_collections
beginning 6 repetitions
123456
......
test_collections leaked [-2, 0, 0] references, sum=-2
test_collections leaked [-1, 2, 1] memory blocks, sum=2
1 test failed:
    test_collections

----------
components: Extension Modules, Tests
messages: 255469
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Reference leaks in test_collections
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 13:04:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 18:04:42 +0000
Subject: [New-bugs-announce] [issue25745] Reference leaks in test_curses
Message-ID: <1448647482.06.0.750956111756.issue25745@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -uall -R 3:3 test_curses
[1/1] test_curses
beginning 6 repetitions
123456
.
test_curses leaked [2, 2, 2] references, sum=6
test_curses leaked [0, 1, 2] memory blocks, sum=3
1 test failed:
    test_curses

----------
components: Extension Modules, Tests
messages: 255470
nosy: serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Reference leaks in test_curses
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 13:07:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 18:07:31 +0000
Subject: [New-bugs-announce] [issue25746] test_unittest failure in leaks
 searching mode
Message-ID: <1448647651.46.0.84768072047.issue25746@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -uall -R 3:3 test_unittest
[1/1] test_unittest
test test_unittest failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
    test_unittest

$ ./python -m test.regrtest -vvuall -R 3:3 test_unittest
...
======================================================================
ERROR: test_discover_with_init_module_that_raises_SkipTest_on_import (unittest.test.test_discovery.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-debug/Lib/unittest/test/test_discovery.py", line 532, in test_discover_with_init_module_that_raises_SkipTest_on_import
    pickle.loads(pickle.dumps(suite, proto))
_pickle.PicklingError: Can't pickle <class 'unittest.loader.ModuleSkipped'>: attribute lookup ModuleSkipped on unittest.loader failed

======================================================================
ERROR: test_discover_with_module_that_raises_SkipTest_on_import (unittest.test.test_discovery.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-debug/Lib/unittest/test/test_discovery.py", line 508, in test_discover_with_module_that_raises_SkipTest_on_import
    pickle.loads(pickle.dumps(suite, proto))
_pickle.PicklingError: Can't pickle <class 'unittest.loader.ModuleSkipped'>: attribute lookup ModuleSkipped on unittest.loader failed

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

----------
components: Tests
messages: 255471
nosy: ezio.melotti, michael.foord, rbcollins, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_unittest failure in leaks searching mode
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 13:13:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 18:13:06 +0000
Subject: [New-bugs-announce] [issue25747] test_idle failure in leaks
 searching mode
Message-ID: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -uall -R 3:3 test_idle
[1/1] test_idle
beginning 6 repetitions
123456
test test_idle failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython-debug/Lib/idlelib/idle_test/test_warning.py", line 76, in test_idlever
    self.assertEqual(len(w), 1)
AssertionError: 0 != 1

1 test failed:
    test_idle

----------
components: IDLE, Tests
messages: 255472
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: test_idle failure in leaks searching mode
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 13:33:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 18:33:42 +0000
Subject: [New-bugs-announce] [issue25748] Resource warnings when run
 test_asyncio in leaks searching mode
Message-ID: <1448649222.14.0.755060741285.issue25748@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -uall -R 3:3 test_asyncio
[1/1] test_asyncio
...
.Executing <Task finished coro=<CoroutineTests.test_async_def_wrapped.<locals>.start() done, defined at /home/serhiy/py/cpython-debug/Lib/test/test_asyncio/test_pep492.py:146> result=None created at /home/serhiy/py/cpython-debug/Lib/asyncio/base_events.py:317> took 0.133 seconds
/home/serhiy/py/cpython-debug/Lib/threading.py:864: ResourceWarning: unclosed <socket.socket fd=7, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 37715)>
  self._target(*self._args, **self._kwargs)
returning true from eof_received() has no effect when using ssl
returning true from eof_received() has no effect when using ssl
/home/serhiy/py/cpython-debug/Lib/asyncio/base_events.py:379: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False>
  warnings.warn("unclosed event loop %r" % self, ResourceWarning)
...
1 test OK.

Cited lines are repeated 6 times (for the number of test runs).

----------
components: Tests, asyncio
messages: 255475
nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Resource warnings when run test_asyncio in leaks searching mode
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 14:28:36 2015
From: report at bugs.python.org (Ron Frederick)
Date: Fri, 27 Nov 2015 19:28:36 +0000
Subject: [New-bugs-announce] [issue25749] asyncio.Server class documented
 but not exported
Message-ID: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za>


New submission from Ron Frederick:

The asyncio documentation defines the class 'asyncio.Server' in section 18.5.1.15. However, this class is not exported by asyncio. It is defined in base_events.py but not in the __all__ list. The only class exported at the asyncio top level is asyncio.AbstractServer, defined in events.py.

I think the documentation should match the exports. Either Server should be exported out of base_events.py, or the documentation should only refer to asyncio.AbstractServer.

----------
components: asyncio
messages: 255476
nosy: Ron Frederick, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Server class documented but not exported
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Nov 27 14:56:53 2015
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 27 Nov 2015 19:56:53 +0000
Subject: [New-bugs-announce] [issue25750] tp_descr_get(self, obj,
 type) is called without owning a reference to "self"
Message-ID: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer:

`type_getattro()` calls `tp_descr_get(self, obj, type)` without actually owning a reference to "self". In very rare cases, this can cause a segmentation fault if "self" is deleted by the descriptor.

Downstream: [http://trac.sagemath.org/ticket/19633]

----------
components: Interpreter Core
files: descr_ref.patch
keywords: patch
messages: 255480
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: tp_descr_get(self, obj, type) is called without owning a reference to "self"
versions: Python 2.7
Added file: http://bugs.python.org/file41173/descr_ref.patch

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

From report at bugs.python.org  Fri Nov 27 15:19:20 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Fri, 27 Nov 2015 20:19:20 +0000
Subject: [New-bugs-announce] [issue25751] ctypes.util ,
 Shell Injection in find_library()
Message-ID: <1448655560.8.0.523539379986.issue25751@psf.upfronthosting.co.za>


New submission from Bernd Dietzel:

The find_library() function can execute code when special chars like ;|`<>$ are in the name.
The "os.popen()" calls in the util.py script should be replaced with "subprocess.Popen()".

Demo Exploits for Linux :
====================

>>> from ctypes.util import find_library
>>> find_library(";xeyes") # runs xeyes
>>> find_library("|xterm") # runs terminal
>>> find_library("&gimp") # runs gimp
>>> find_library("$(nautilus)") # runs filemanager
>>> find_library(">test") # creates, and if exists, erases a file "test"

==== Traceback ====

>>> find_library("`xmessage hello`") # shows a message, press ctrl+c for Traceback
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/ctypes/util.py", line 244, in find_library
    return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name))
  File "/usr/lib/python3.4/ctypes/util.py", line 99, in _findLib_gcc
    trace = f.read()
KeyboardInterrupt


https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1512068

----------
components: ctypes
files: workaround.diff
keywords: patch
messages: 255482
nosy: TheRegRunner
priority: normal
severity: normal
status: open
title: ctypes.util , Shell Injection in find_library()
type: security
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41174/workaround.diff

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

From report at bugs.python.org  Fri Nov 27 16:26:38 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 27 Nov 2015 21:26:38 +0000
Subject: [New-bugs-announce] [issue25752] asyncio.readline - add
 customizable line separator
Message-ID: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za>


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

In Python3.5 asyncio.StreamReader.readline() can separate lines only by b'\n'. For some task, I want actually "read until separator", where separator is another byte.

Since I cannot create pull-request, I will write just here what I want:

@coroutine
def readline(self, separator=b'\n'):
    if not isinstance(separator, bytes) or len(separator) != 1:
        raise ValueError(separator)
    ....
    ichar = self._buffer.find(separator)
    ....

----------
components: asyncio
messages: 255488
nosy: gvanrossum, haypo, mmarkk, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.readline - add customizable line separator
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Nov 27 16:41:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 21:41:04 +0000
Subject: [New-bugs-announce] [issue25753] Reference leaks in test_smtplib
Message-ID: <1448660464.47.0.968238224363.issue25753@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -uall -R 3:3 test_smtplib
[1/1] test_smtplib
beginning 6 repetitions
123456
......
test_smtplib leaked [0, 1, 1] references, sum=2
test_smtplib leaked [0, 1, 2] memory blocks, sum=3
1 test failed:
    test_smtplib

----------
components: Tests
messages: 255491
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Reference leaks in test_smtplib
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 16:43:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 21:43:30 +0000
Subject: [New-bugs-announce] [issue25754] Test test_rlcompleter failed if
 run twice
Message-ID: <1448660610.8.0.576604023002.issue25754@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest test_rlcompleter test_rlcompleter
[1/2] test_rlcompleter
[2/2] test_rlcompleter
test test_rlcompleter failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython-debug/Lib/test/test_rlcompleter.py", line 66, in test_attr_matches
    ['CompleteMe.mro(', 'CompleteMe.spam'])
AssertionError: Lists differ: ['CompleteMe.me(', 'CompleteMe.mro(', 'CompleteMe.spam'] != ['CompleteMe.mro(', 'CompleteMe.spam']

First differing element 0:
CompleteMe.me(
CompleteMe.mro(

First list contains 1 additional elements.
First extra element 2:
CompleteMe.spam

- ['CompleteMe.me(', 'CompleteMe.mro(', 'CompleteMe.spam']
?  ------------------

+ ['CompleteMe.mro(', 'CompleteMe.spam']

1 test OK.
1 test failed:
    test_rlcompleter

----------
components: Tests
messages: 255492
nosy: martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Test test_rlcompleter failed if run twice
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 16:45:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Nov 2015 21:45:16 +0000
Subject: [New-bugs-announce] [issue25755] Test test_property failed if run
 twice
Message-ID: <1448660716.3.0.167851724474.issue25755@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest test_property test_property
[1/2] test_property
[2/2] test_property
test test_property failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython-debug/Lib/test/test_property.py", line 172, in test_property_decorator_doc_writable
    self.assertEqual(sub.__class__.spam.__doc__, 'Eggs')
AssertionError: 'Spam' != 'Eggs'
- Spam
+ Eggs


1 test OK.
1 test failed:
    test_property

----------
components: Tests
messages: 255493
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Test test_property failed if run twice
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 27 18:22:04 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 27 Nov 2015 23:22:04 +0000
Subject: [New-bugs-announce] [issue25756] asyncio WriteTransport
 documentation typo
Message-ID: <1448666524.97.0.228973534452.issue25756@psf.upfronthosting.co.za>


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

Here is the match against master.


Doc/library/asyncio-protocol.rst:

@@ -156,9 +156,9 @@ WriteTransport
       high-water limit is given, the low-water limit defaults to an
       implementation-specific value less than or equal to the
       high-water limit.  Setting *high* to zero forces *low* to zero as
-      well, and causes :meth:`pause_writing` to be called whenever the
+      well, and causes :meth:`resume_writing` to be called whenever the
       buffer becomes non-empty.  Setting *low* to zero causes
-      :meth:`resume_writing` to be called only once the buffer is empty.
+      :meth:`pause_writing` to be called only once the buffer is empty.
       Use of zero for either limit is generally sub-optimal as it
       reduces opportunities for doing I/O and computation
       concurrently.

----------
assignee: docs at python
components: Documentation
messages: 255508
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: asyncio WriteTransport documentation typo
type: enhancement
versions: 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/issue25756>
_______________________________________

From report at bugs.python.org  Fri Nov 27 18:43:52 2015
From: report at bugs.python.org (Torsten Landschoff)
Date: Fri, 27 Nov 2015 23:43:52 +0000
Subject: [New-bugs-announce] [issue25757] Subclasses of property lose
 docstring
Message-ID: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za>


New submission from Torsten Landschoff:

I actually found this in Python2, but it is still unchanged in Python 3.6 dev. Namely, creating an instance of a class derived from property will drop the docstring passed explicitly to the constructor: 

torsten at defiant:~$ python3.6
Python 3.6.0a0 (default:9fcfdb53e8af, Nov 27 2015, 23:11:09) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> property(doc="Hello world").__doc__
'Hello world'
>>> class SubProp(property): pass
... 
>>> SubProp(doc="Hello world").__doc__
>>>

This war surprising to me. I actually used a subclass of property to describe fields of configuration classes with extensive documentation, which disappeared during runtime.

In Python2 I work around this by assigning to __doc__ as the last thing in the constructor of my SubProp class.

----------
components: Interpreter Core
messages: 255511
nosy: torsten
priority: normal
severity: normal
status: open
title: Subclasses of property lose docstring
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Nov 28 04:56:53 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Sat, 28 Nov 2015 09:56:53 +0000
Subject: [New-bugs-announce] [issue25758] ensurepip/venv broken on Windows
 if path includes unicode
Message-ID: <1448704613.06.0.448553989281.issue25758@psf.upfronthosting.co.za>


New submission from Dima Tisnek:

One of my students installed Python 3.5 on Windows 10 to default location where user name "?ukasz" contains unicode.

Now "-m venv" and "-m ensurepip" do not work:

C:\Users\?ukasz>C:\Users\?ukasz\AppData\Local\Programs\Python\Python35-32\python.exe -m venv workshops
Error: Command '['C:\\Users\\\u0141ukasz\\workshops\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

C:\Users\?ukasz>C:\Users\?ukasz\AppData\Local\Programs\Python\Python35-32\python.exe -m ensurepip
Traceback (most recent call last):
  File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__main__.py", line 4, in <module>
    ensurepip._main()
  File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__init__.py", line 209, in _main
    default_pip=args.default_pip,
  File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__init__.py", line 116, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__init__.py", line 40, in _run_pip
    import pip
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 954, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 896, in _find_spec
  File "<frozen importlib._bootstrap_external>", line 1136, in find_spec
  File "<frozen importlib._bootstrap_external>", line 1112, in _get_spec
  File "<frozen importlib._bootstrap_external>", line 1093, in _legacy_get_spec
  File "<frozen importlib._bootstrap>", line 444, in spec_from_loader
  File "<frozen importlib._bootstrap_external>", line 530, in spec_from_file_location
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character

----------
components: Unicode
messages: 255534
nosy: Dima.Tisnek, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: ensurepip/venv broken on Windows if path includes unicode
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov 28 15:10:41 2015
From: report at bugs.python.org (Kovid Goyal)
Date: Sat, 28 Nov 2015 20:10:41 +0000
Subject: [New-bugs-announce] [issue25759] Python 2.7.11rc1 not building with
 Visual Studio 2015
Message-ID: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>


New submission from Kovid Goyal:

The Pcbuild/readme.txt file implies that it is possible to build python 2.7.11rc1 with Visual Studio 2015 (although it is not officially supported). However, there are at least a couple of problems, that I have encountered so far:

1) timemodule.c uses timezone, tzname and daylight which are no longer defined in visual studio, as a quick hackish workaround, one can do
#if defined _MSC_VER && MSC_VER >= 1900
#define timezone _timezone
#define tzname _tzname
#define daylight _daylight
#endif

2) More serious, the code in posixmodule.c to check if file descriptors are valid no longer links, since it relies on an internal structure from microsoft ddls, __pioinfo that no longer exists. See
https://bugs.python.org/issue23524 for discussion about this in the python 3.x branch

As a quick and dirty fix one could just replace _PyVerify_fd with a stub implementation that does nothing for _MSC_VER >= 1900

However, a proper fix should probably be made.

----------
components: Interpreter Core
messages: 255550
nosy: kovidgoyal
priority: normal
severity: normal
status: open
title: Python 2.7.11rc1 not building with Visual Studio 2015
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 28 21:07:24 2015
From: report at bugs.python.org (Samwyse)
Date: Sun, 29 Nov 2015 02:07:24 +0000
Subject: [New-bugs-announce] [issue25760] TextWrapper fails to split
 'two-and-a-half-hour' correctly
Message-ID: <1448762844.39.0.812229060367.issue25760@psf.upfronthosting.co.za>


New submission from Samwyse:

Single character words in a hyphenated phrase are not split correctly.  The root issue it the wordsep_re class variable.  To reproduce, run the following:

>>> import textwrap
>>> textwrap.TextWrapper.wordsep_re.split('two-and-a-half-hour')
['', 'two-', 'and-a', '-half-', 'hour']

It works if 'a' is replaces with two or more alphabetic characters.

>>> textwrap.TextWrapper.wordsep_re.split('two-and-aa-half-hour')
['', 'two-', '', 'and-', '', 'aa-', '', 'half-', 'hour']

The problem is in this part of the pattern:  (?=\w+[^0-9\W])

I confess that I don't understand the situation that would require that complicated of a pattern.  Why wouldn't (?=\w) would work?

----------
components: Library (Lib)
messages: 255558
nosy: samwyse
priority: normal
severity: normal
status: open
title: TextWrapper fails to split 'two-and-a-half-hour' correctly
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov 29 05:59:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Nov 2015 10:59:25 +0000
Subject: [New-bugs-announce] [issue25761] Improve unpickling errors handling
Message-ID: <1448794765.73.0.847000762162.issue25761@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This issue is for better detecting and reporting errors in broken pickle data.

----------
assignee: serhiy.storchaka
components: Extension Modules, Library (Lib), Tests
messages: 255567
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve unpickling errors handling
type: enhancement

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

From report at bugs.python.org  Sun Nov 29 11:40:53 2015
From: report at bugs.python.org (Yunus Emre Kursav)
Date: Sun, 29 Nov 2015 16:40:53 +0000
Subject: [New-bugs-announce] [issue25762] Calculation Mistake 1.5  * 0.3
Message-ID: <1448815253.26.0.478369331046.issue25762@psf.upfronthosting.co.za>


New submission from Yunus Emre Kursav:

Dear Authorized Person,

When I was using python, I found a bug. When I multiplied 1.5 time 0.3, I got 0.44999999999999996 as a result.

Best Regards,
Yunus

----------
files: Screenshot from 2015-11-29 17-39-20.png
messages: 255579
nosy: zeneregion
priority: normal
severity: normal
status: open
title: Calculation Mistake 1.5  * 0.3
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41190/Screenshot from 2015-11-29 17-39-20.png

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

From report at bugs.python.org  Sun Nov 29 12:02:23 2015
From: report at bugs.python.org (jingtao chen)
Date: Sun, 29 Nov 2015 17:02:23 +0000
Subject: [New-bugs-announce] [issue25763] I cannot use absolute path in
 sqlite3 , python 2.7.9, windows
Message-ID: <1448816543.72.0.957954089761.issue25763@psf.upfronthosting.co.za>


New submission from jingtao chen:

I tried the way like here https://www.sqlite.org/c3ref/open.html#urifilenamesinsqlite3open but it is useless 

what I got is 

C:\Users\CJT-6220>python D:\NKUSearch\pr_cal\main.py
Traceback (most recent call last):
  File "D:\NKUSearch\pr_cal\main.py", line 7, in <module>
    conn = sqlite3.Connection('file:///D:/NKU.db')
sqlite3.OperationalError: unable to open database file


and I tried some other ways to write the URI but none of them works and PEP 249 did not mention anything about absolute path . So what can I do ?

----------
components: Windows
messages: 255581
nosy: jingtao chen, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: I cannot use absolute path in sqlite3 , python 2.7.9, windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 29 14:09:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Nov 2015 19:09:11 +0000
Subject: [New-bugs-announce] [issue25764] PyObject_Call() is called with an
 exception set in subprocess
Message-ID: <1448824151.78.0.622422139525.issue25764@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

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

[117/400] test_subprocess -- running: test_tokenize (65 sec), test_concurrent_futures (38 sec)
Assertion failed: !PyErr_Occurred(), file Objects/abstract.c, line 2158
Fatal Python error: Aborted

Current thread 0x00000001 (most recent call first):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/subprocess.py", line 1483 in _execute_child
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/subprocess.py", line 950 in __init__
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_subprocess.py", line 2295 in test_close_fds_after_preexec
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/case.py", line 600 in run
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/case.py", line 648 in __call__
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 122 in run
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 84 in __call__
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 122 in run
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 84 in __call__
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/runner.py", line 176 in run
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/support/__init__.py", line 1780 in _run_suite
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/support/__init__.py", line 1814 in run_unittest
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_subprocess.py", line 2657 in test_main
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest.py", line 162 in runtest_inner
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest.py", line 115 in runtest
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest_mp.py", line 69 in run_tests_slave
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 379 in main
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 433 in main
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 455 in main_in_temp_cwd
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 39 in <module>
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 85 in _run_code
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 170 in _run_module_as_main
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 455, in main_in_temp_cwd
    main()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 433, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 392, in main
    self.run_tests()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 354, in run_tests
    run_tests_multiprocess(self)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest_mp.py", line 212, in run_tests_multiprocess
    raise Exception(msg)
Exception: Child error on test_subprocess: Exit code -6
make: *** [buildbottest] Error 1
program finished with exit code 2

----------
components: Extension Modules
messages: 255586
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyObject_Call() is called with an exception set in subprocess
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Nov 29 15:10:14 2015
From: report at bugs.python.org (Ayushmaan Saxena)
Date: Sun, 29 Nov 2015 20:10:14 +0000
Subject: [New-bugs-announce] [issue25765] Installation error
Message-ID: <1448827814.4.0.634101535086.issue25765@psf.upfronthosting.co.za>


New submission from Ayushmaan Saxena:

installation error 0x80240004

----------
components: Installation
files: Python 3.5.0 (32-bit)_20151130012741.log
messages: 255589
nosy: ayushmaan121
priority: normal
severity: normal
status: open
title: Installation error
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file41191/Python 3.5.0 (32-bit)_20151130012741.log

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

From report at bugs.python.org  Sun Nov 29 15:26:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Nov 2015 20:26:42 +0000
Subject: [New-bugs-announce] [issue25766] __bytes__ doesn't work for str
 subclasses
Message-ID: <1448828802.95.0.345172708456.issue25766@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Special __bytes__ method is purposed for converting to bytes with bytes constructor (as well as __str__ and __float__ for str and float). But this doesn't work if the class is a subclass of str.

>>> class X:
...     def __bytes__(self):
...         return b'abc'
... 
>>> bytes(X())
b'abc'
>>> class Y(str):
...     def __bytes__(self):
...         return b'abc'
... 
>>> bytes(Y())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument without an encoding

----------
components: Interpreter Core
files: str___bytes__.patch
keywords: patch
messages: 255593
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: __bytes__ doesn't work for str subclasses
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41192/str___bytes__.patch

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

From report at bugs.python.org  Sun Nov 29 17:21:29 2015
From: report at bugs.python.org (Elizabeth Myers)
Date: Sun, 29 Nov 2015 22:21:29 +0000
Subject: [New-bugs-announce] [issue25767] asyncio documentation section
 18.5.2.3.1. (Windows) links to French Wikipedia in English docs
Message-ID: <1448835689.06.0.772038280657.issue25767@psf.upfronthosting.co.za>


New submission from Elizabeth Myers:

The link for HPET in the asyncio documentation (18.5.2.3.1 Windows, final paragraph, see https://docs.python.org/3/library/asyncio-eventloops.html#windows) links to https://fr.wikipedia.org/wiki/High_Precision_Event_Timer for the HPET link even though the document is in English (it should link to the English Wikipedia version instead).

----------
assignee: docs at python
components: Documentation
messages: 255598
nosy: Elizacat, docs at python
priority: normal
severity: normal
status: open
title: asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Nov 29 17:44:15 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Sun, 29 Nov 2015 22:44:15 +0000
Subject: [New-bugs-announce] [issue25768] compileall functions do not
 document return values
Message-ID: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>


New submission from Nicholas Chammas:

I'm using the public functions of Python's built-in compileall module.

https://docs.python.org/3/library/compileall.html#public-functions

There doesn't appear to be documentation of what each of these functions returns.

I figured out, for example, that compileall.compile_file() returns 1 when the file compiles successfully, and 0 if not.

If this is "official" behavior, it would be good to see it documented so that we can rely on it.

I'd be happy to submit a patch to fix this if a committer is willing to shepherd a new contributor (me) through the process. Otherwise, this is probably a quick fix for experienced contributors.

----------
assignee: docs at python
components: Documentation
messages: 255600
nosy: Nicholas Chammas, docs at python
priority: normal
severity: normal
status: open
title: compileall functions do not document return values
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 30 00:16:04 2015
From: report at bugs.python.org (lplatypus)
Date: Mon, 30 Nov 2015 05:16:04 +0000
Subject: [New-bugs-announce] [issue25769] Crash due to using weakref
 referent without acquiring a strong reference
Message-ID: <1448860564.76.0.866220529061.issue25769@psf.upfronthosting.co.za>


New submission from lplatypus:

I have encountered some crashes in a multithreaded application which appear to be due to a bug in weakref_richcompare in Objects/weakref.c

(I am using Python 2.7.9, but the same weakref code exists in 3.5 and hg default branch too)

weakref_richcompare ends with the statement:

    return PyObject_RichCompare(PyWeakref_GET_OBJECT(self),
                                PyWeakref_GET_OBJECT(other), op);

At this point the code has established that the referents of "self" and "other" are still alive, and it is trying to compare the referents.  However it has not acquired a strong reference to the referents, so I think it is possible for one of them to be deleted half way through this comparison.  This can lead to a crash, because PyObject_RichCompare assumes that the PyObject*?s it was passed will remain usable for the duration of the call.

The crash dumps I have seen involve data corruption consistent with one of these PyObject's being deleted and the memory used for something else, eg:

00 python27!try_3way_compare+0x15 [objects\object.c @ 712]
01 python27!try_3way_to_rich_compare+0xb [objects\object.c @ 901]
02 python27!do_richcmp+0x2c [objects\object.c @ 935]
03 python27!PyObject_RichCompare+0x99 [objects\object.c @ 982]
04 python27!weakref_richcompare+0x6a [objects\weakrefobject.c @ 212]

In this example, in try_3way_compare the value of v->ob_type was 0x5f637865, which is ASCII "exc_" and not a valid pointer at all.

Other places in weakrefobject.c seem to have a similar weakness, eg in weakref_hash and weakref_repr.

I have not been successful in producing a small test case to demonstrate this crash.

----------
components: Interpreter Core
messages: 255608
nosy: ldeller
priority: normal
severity: normal
status: open
title: Crash due to using weakref referent without acquiring a strong reference
type: crash
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/issue25769>
_______________________________________

From report at bugs.python.org  Mon Nov 30 21:07:11 2015
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 01 Dec 2015 02:07:11 +0000
Subject: [New-bugs-announce] [issue25770] expose name, args,
 and kwargs from methodcaller
Message-ID: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za>


New submission from Joe Jevnik:

This patch adds 3 properties to methodcaller objects for inspecting the object at runtime:

1. 'name': the name of the method to call
2. 'args': the position arguments to pass to the method
3. 'keywords': the keyword arguments to pass to the method

args and keywords act like functools.partial (that is why I did not name it kwargs).

I noticed that recently the repr changed to expose this information which helps in the debugging use case; however, this allows us to use the methodcaller to maybe construct a new methodcaller with different args, or call a different method with the same args.

----------
components: Library (Lib)
files: methodcaller-attrs.patch
keywords: patch
messages: 255636
nosy: llllllllll
priority: normal
severity: normal
status: open
title: expose name, args, and kwargs from methodcaller
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41198/methodcaller-attrs.patch

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