From report at bugs.python.org  Tue Jul  1 00:00:38 2014
From: report at bugs.python.org (Karl Richter)
Date: Mon, 30 Jun 2014 22:00:38 +0000
Subject: [New-bugs-announce]
	[issue21889]	https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions	doesn't
	explain exception
Message-ID: <1404165638.91.0.279596288902.issue21889@psf.upfronthosting.co.za>


New submission from Karl Richter:

Although the section https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions (of the multiprocessing module documentation) is titled "... and exceptions" it doesn't say anything about exceptions. I assume that it behaves like the thread API (as stated and referenced in the introduction of the module doc). This implies though that either the reference is limited to that statement (-> remove "and exceptions" from the header as there's no special section on them because everything can be found in thread API) or add an explicit reference to the thread API. If this assumption is wrong the section is badly organized or doesn't make any sense at all.

I'm not yet sure about exception handling in the multiprocessing module in case it's different from threads, but that shouldn't matter for this doc issue report. 

I'd also like to suggest a more detailed section on exceptions with usage of queues to pass them as objects to the parent or another process.

----------
assignee: docs at python
components: Documentation
messages: 221987
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions doesn't explain exception
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  1 05:15:10 2014
From: report at bugs.python.org (Robin Schoonover)
Date: Tue, 01 Jul 2014 03:15:10 +0000
Subject: [New-bugs-announce] [issue21890] wsgiref.simple_server doesn't
	accept empty bytes before	start_response is called
Message-ID: <1404184510.5.0.84615415722.issue21890@psf.upfronthosting.co.za>


New submission from Robin Schoonover:

Consider this paragraph of PEP3333, referring to headers obtained
via start_response, emphasis mine:

    Instead, it must store them for the server or gateway to
    transmit only after the first iteration of the application
    return value that yields a *non-empty bytestring*, or upon
    the application's first invocation of the write() callable.

This means that an WSGI app such as this should be valid, because the
yielded bytes pre-start_response are empty:

    def application(environ, start_response):
        yield b''
        start_response("200 OK", [("Content-Type", "text/plain")])
        yield b'Hello, World.\n'

However, in wsgiref's simple server, this fails:

    Traceback (most recent call last):
      File "/usr/local/lib/python3.4/wsgiref/handlers.py", line 180, in finish_response
        self.write(data)
      File "/usr/local/lib/python3.4/wsgiref/handlers.py", line 269, in write
        raise AssertionError("write() before start_response()")
    AssertionError: write() before start_response()

----------
components: Library (Lib)
messages: 222005
nosy: pje, rschoon
priority: normal
severity: normal
status: open
title: wsgiref.simple_server doesn't accept empty bytes before start_response is called
type: behavior

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

From report at bugs.python.org  Tue Jul  1 06:40:46 2014
From: report at bugs.python.org (John Malmberg)
Date: Tue, 01 Jul 2014 04:40:46 +0000
Subject: [New-bugs-announce] [issue21891] sysmodule.c,
	#define terminated with semicolon.
Message-ID: <1404189646.68.0.928359332954.issue21891@psf.upfronthosting.co.za>


New submission from John Malmberg:

Minor issue, the #define TAG line incorrectly is terminated with a semicolon.

This results in a double semicolon on the following line where the macro is expanded.

As this is an informational message, this is just cosmetic.

Listing fragment:

????????  25861 #define MAJOR STRIFY(PY_MAJOR_VERSION)
????????  25862 #define MINOR STRIFY(PY_MINOR_VERSION)
????????  25863 #define TAG NAME "-" MAJOR MINOR;
????????  25864 const char *_PySys_ImplCacheTag = TAG;
????????????????.....................................1
%CC-I-EXTRASEMI, (1) Extraneous semicolon.

       E????????                                "cpython" "-" "3" "5" ;

----------
messages: 222007
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: sysmodule.c, #define terminated with semicolon.
versions: Python 3.5

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

From report at bugs.python.org  Tue Jul  1 06:59:13 2014
From: report at bugs.python.org (John Malmberg)
Date: Tue, 01 Jul 2014 04:59:13 +0000
Subject: [New-bugs-announce] [issue21892] hashtable.c not using
	PY_FORMAT_SIZE_T
Message-ID: <1404190753.13.0.221533788986.issue21892@psf.upfronthosting.co.za>


New submission from John Malmberg:

hashtable.c is using %zd instead of the PY_FORMAT_SIZE_T as set by configure.

Comments in pymacconfig.h state that this will cause problems on OS-X 10.4 with binaries build on OS-X 10.5.

The attached patch hashtable.giff changes hashtable.c to be like the other modules that use PY_FORMAT_SIZE_T.

----------
files: hashtable.gdiff
messages: 222008
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: hashtable.c not using PY_FORMAT_SIZE_T
versions: Python 3.5
Added file: http://bugs.python.org/file35811/hashtable.gdiff

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

From report at bugs.python.org  Tue Jul  1 06:59:17 2014
From: report at bugs.python.org (John Malmberg)
Date: Tue, 01 Jul 2014 04:59:17 +0000
Subject: [New-bugs-announce] [issue21893] unicodeobject.c not using
	PY_FORMAT_SIZE_T
Message-ID: <1404190757.21.0.550855654281.issue21893@psf.upfronthosting.co.za>


New submission from John Malmberg:

unicodeobject.c is using %zd instead of the PY_FORMAT_SIZE_T as set by configure.

Comments in pymacconfig.h state that this will cause problems on OS-X 10.4 with binaries build on OS-X 10.5.

The attached patch unicodeobject.giff changes unicodeobject.c to be like the other modules that use PY_FORMAT_SIZE_T.

----------
files: unicodeobject.gdiff
messages: 222009
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: unicodeobject.c not using PY_FORMAT_SIZE_T
versions: Python 3.5
Added file: http://bugs.python.org/file35812/unicodeobject.gdiff

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

From report at bugs.python.org  Tue Jul  1 07:32:29 2014
From: report at bugs.python.org (dipen)
Date: Tue, 01 Jul 2014 05:32:29 +0000
Subject: [New-bugs-announce] [issue21894] ImportError: cannot import name jit
Message-ID: <1404192749.19.0.810563514436.issue21894@psf.upfronthosting.co.za>


New submission from dipen:

i want to used parakeet module.
and i install all dependency related to all.
when i run attached file code then i get error like
ImportError: cannot import name jit
So i dont know how to solve this error.

----------
components: Library (Lib)
files: parakeet.py
messages: 222010
nosy: dipen
priority: normal
severity: normal
status: open
title: ImportError: cannot import name jit
versions: Python 2.7
Added file: http://bugs.python.org/file35813/parakeet.py

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

From report at bugs.python.org  Tue Jul  1 12:01:35 2014
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Tue, 01 Jul 2014 10:01:35 +0000
Subject: [New-bugs-announce] [issue21895] signal.pause() doesn't wake up on
	SIGCHLD in non-main	thread
Message-ID: <1404208895.06.0.521807683184.issue21895@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

Reproducer attached. To describe the problem in words, one needs to do this to reproduce this issue:
- Create a signal handler and register it using signal.signal to SIGCHLD.
- Create a thread that invokes a subprocess, e.g. "sleep 1" and then continues to do something for time period longer than the subprocess is running.
- Run this thread from main thread and call signal.pause() in the main thread.
- The pause() call is never interrupted and the signal handler is never run.

This happens because:
- Python adds signal_handler as a handler to the specified signal and stores the passed Python function in structure Handlers.
- When signal.pause() is run, the main thread releases the GIL, so that other threads can run.
- The non-main thread gets to lease and actually invokes the subprocess and then continues to do something.
- When subprocess finishes, it sends the signal *to the thread that invoked it* (assuming this thread is still running). This means that the signal.pause() call is not interrupted and main thread continues to sleep.
- The non-main thread adds handler call to the list of pending calls using Py_AddPendingCall.
- Pending calls are checked in Py_MakePendingCalls, which is called in every iteration of the bytecode evaluation loop in PyEval_EvalFrameEx.
- The problem is that since pause() isn't un-paused and hangs forever, the evaluation loop never gets to another iteration, hence can't do any pending call.

This happens on all Python versions I've tried, using pthread threading.
I think this could *possibly* be solved by issuing a pthread_kill from the non-main thread to the main thread to wake it up, but I'm not sure what all the implications of such a change would be.

----------
components: Interpreter Core
files: signal_pause_doesnt_wake_up.py
messages: 222021
nosy: bkabrda
priority: normal
severity: normal
status: open
title: signal.pause() doesn't wake up on SIGCHLD in non-main thread
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35815/signal_pause_doesnt_wake_up.py

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

From report at bugs.python.org  Tue Jul  1 14:18:25 2014
From: report at bugs.python.org (Tymoteusz Paul)
Date: Tue, 01 Jul 2014 12:18:25 +0000
Subject: [New-bugs-announce] [issue21896] Unexpected ConnectionResetError in
	urllib.request	against a valid website
Message-ID: <1404217105.77.0.742047143649.issue21896@psf.upfronthosting.co.za>


New submission from Tymoteusz Paul:

I've recently ran into a problem with urellib.request.urlopen that it fails against one website (that I've found so far). The website itself is working fine, I can access its content with other libraries like requests, curl and outside of python with telnet, links and so on. But with urllib it fails:

Python 3.4.1 (default, Jul  1 2014, 14:08:25)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.request
>>> urllib.request.urlopen("http://www.thomsonlocal.com/")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.4/urllib/request.py", line 153, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib64/python3.4/urllib/request.py", line 455, in open
    response = self._open(req, data)
  File "/usr/lib64/python3.4/urllib/request.py", line 473, in _open
    '_open', req)
  File "/usr/lib64/python3.4/urllib/request.py", line 433, in _call_chain
    result = func(*args)
  File "/usr/lib64/python3.4/urllib/request.py", line 1215, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib64/python3.4/urllib/request.py", line 1194, in do_open
    r = h.getresponse()
  File "/usr/lib64/python3.4/http/client.py", line 1172, in getresponse
    response.begin()
  File "/usr/lib64/python3.4/http/client.py", line 351, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python3.4/http/client.py", line 313, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib64/python3.4/socket.py", line 371, in readinto
    return self._sock.recv_into(b)
ConnectionResetError: [Errno 104] Connection reset by peer

I've tested it on about 6 different servers, in different parts of the world and all of them seem to be affected. I've tested with with 3.2.5, 3.3.3, 3.4.1 and they are all failed with the same trace.

----------
components: Library (Lib)
messages: 222024
nosy: Tymoteusz.Paul
priority: normal
severity: normal
status: open
title: Unexpected ConnectionResetError in urllib.request against a valid website
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jul  1 15:40:08 2014
From: report at bugs.python.org (Masami HIRATA)
Date: Tue, 01 Jul 2014 13:40:08 +0000
Subject: [New-bugs-announce] [issue21897] frame.f_locals causes segfault on
	Python >=3.4.1
Message-ID: <1404222008.61.0.644156666753.issue21897@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

It seems that frame.f_locals causes segfault on Python >=3.4.1

$ uname -a
Linux ashrose 3.2.0-61-generic #93-Ubuntu SMP Fri May 2 21:31:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ ls
test1.py
$ cat test1.py
import unittest

class TestCallable(unittest.TestCase):
    def test_callable(self):
        try:
            with self.assertRaises(IndexError):
                def raise_error(): raise TypeError
                (lambda: raise_error())()
        except TypeError as exception:
            exception.__traceback__.tb_next.tb_frame.f_locals
$ python3.4.1 -m unittest
Segmentation fault
$ python3.4.0 -m unittest
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK
$ python3.3.5 -m unittest
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
$ gdb /home/python/local/3.4.1mgs/bin/python3.4.1

...

(gdb) run -m unittest
Starting program: /home/python/local/3.4.1mgs/bin/python3.4.1 -m unittest
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
map_to_dict (deref=1, values=0x7ffff5e97510, dict=0x7ffff5e8f588, nmap=<optimized out>, map=0x7ffff60e0278)
    at Objects/frameobject.c:791
791	            value = PyCell_GET(value);
(gdb) bt
#0  map_to_dict (deref=1, values=0x7ffff5e97510, dict=0x7ffff5e8f588, nmap=<optimized out>, 
    map=0x7ffff60e0278) at Objects/frameobject.c:791
#1  PyFrame_FastToLocalsWithError (f=0x7ffff5e97398) at Objects/frameobject.c:915
#2  0x00007ffff79beaa9 in frame_getlocals (f=0x7ffff5e97398, closure=<optimized out>)
    at Objects/frameobject.c:24
#3  0x00007ffff79deff3 in _PyObject_GenericGetAttrWithDict (obj=0x7ffff5e97398, name=0x7ffff7fcdbb0, dict=0x0)
    at Objects/object.c:1043
#4  0x00007ffff7a57891 in PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>)
    at Python/ceval.c:2411
#5  0x00007ffff7a5df3c in PyEval_EvalCodeEx (_co=<optimized out>, globals=<optimized out>, 
    locals=<optimized out>, args=<optimized out>, argcount=1, kws=0x790f48, kwcount=0, defs=0x0, defcount=0, 
    kwdefs=0x0, closure=0x0) at Python/ceval.c:3578
#6  0x00007ffff7a5ca61 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, 
    pp_stack=0x7fffffffbbf0, func=0x7ffff6115158) at Python/ceval.c:4334
#7  call_function (oparg=<optimized out>, pp_stack=0x7fffffffbbf0) at Python/ceval.c:4252
#8  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2829
#9  0x00007ffff7a5df3c in PyEval_EvalCodeEx (_co=<optimized out>, globals=<optimized out>, 
    locals=<optimized out>, args=<optimized out>, argcount=2, kws=0x7ffff7fad060, kwcount=0, 
    defs=0x7ffff617cd48, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3578
#10 0x00007ffff79bf28c in function_call (func=0x7ffff6192400, arg=0x7ffff6101c08, kw=0x7ffff5e8f248)
    at Objects/funcobject.c:632
#11 0x00007ffff799300e in PyObject_Call (func=0x7ffff6192400, arg=<optimized out>, kw=<optimized out>)
    at Objects/abstract.c:2067
#12 0x00007ffff7a56871 in ext_do_call (nk=0, na=1, flags=<optimized out>, pp_stack=0x7fffffffbec0, 
    func=0x7ffff6192400) at Python/ceval.c:4551
#13 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2869
---Type <return> to continue, or q <return> to quit---

----------
components: Interpreter Core
messages: 222029
nosy: msmhrt
priority: normal
severity: normal
status: open
title: frame.f_locals causes segfault on Python >=3.4.1
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Jul  1 16:08:15 2014
From: report at bugs.python.org (Andy Maier)
Date: Tue, 01 Jul 2014 14:08:15 +0000
Subject: [New-bugs-announce] [issue21898] .hgignore: Missing ignores for
	Eclipse/pydev
Message-ID: <1404223695.39.0.861504959592.issue21898@psf.upfronthosting.co.za>


New submission from Andy Maier:

The .hgignore file misses some entries for directories and files created by Eclipse with pydev.

The additional lines for .hgignore would be:
    ^.project
    ^.pydevproject
    ^.settings/

This change applies to 2.7 and 3.x.

----------
messages: 222032
nosy: andymaier
priority: normal
severity: normal
status: open
title: .hgignore: Missing ignores for Eclipse/pydev
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jul  1 16:29:27 2014
From: report at bugs.python.org (Sebastian Kreft)
Date: Tue, 01 Jul 2014 14:29:27 +0000
Subject: [New-bugs-announce] [issue21899] Futures are not marked as completed
Message-ID: <1404224967.0.0.623746440602.issue21899@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

With Python 3.4.1 compiled from source, I'm having an issue in which every now and then some Futures are not marked as completed even though the underlying workload is done.

My workload is launching two subprocess in parallel, and whenever one is ready, launches another one. In one of the runs, the whole process got stuck after launching about 3K subprocess, and the underlying processes had in fact finished.

To wait for the finished subprocesses, I'm using FIRST_COMPLETED. Below is the core of my workload:

for element in element_generator:
    while len(running) >= max_tasks:
        done, pending = concurrent.futures.wait(running, timeout=15.0, return_when=concurrent.futures.FIRST_COMPLETED)
        process_results(done)
        running = pending

    running.add(executor.submit(exe_subprocess, element)) 
 

Replicating the issue takes time, but I've been able to successfully reproduce it with 2 and 3 processes in parallel.

Note: this was already posted in comments to http://bugs.python.org/issue20319, however it did not receive the proper atention as that issue is already closed.

As suggested there I printed the status of the never finished futures and this is the result:

State: RUNNING, Result: None, Exception: None, Waiters: 0, Cancelled: False, Running: True, Done: False

The information does not seem very relevant. However, I can attach a console and debug from there.

----------
messages: 222034
nosy: Sebastian.Kreft.Deezer
priority: normal
severity: normal
status: open
title: Futures are not marked as completed

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

From report at bugs.python.org  Tue Jul  1 16:55:30 2014
From: report at bugs.python.org (Andy Maier)
Date: Tue, 01 Jul 2014 14:55:30 +0000
Subject: [New-bugs-announce] [issue21900] .hgignore: Missing ignores for
	downloaded doc build tools
Message-ID: <1404226530.0.0.067292394888.issue21900@psf.upfronthosting.co.za>


New submission from Andy Maier:

In Python 2.7 and up to Python 3.3, the documentation build process downloads tools such as Sphinx etc. into the Doc/tools subtree. The .hgignore file misses entries to ignore those.

The additional lines for .hgignore would be:
    ^Doc/tools/docutils/
    ^Doc/tools/jinja2/
    ^Doc/tools/pygments/
    ^Doc/tools/sphinx/

This change applies to 2.7 only (assuming 3.1-3.3 are no longer patched).

----------
messages: 222041
nosy: andymaier
priority: normal
severity: normal
status: open
title: .hgignore: Missing ignores for downloaded doc build tools
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul  2 00:40:03 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jul 2014 22:40:03 +0000
Subject: [New-bugs-announce] [issue21901]
	test_selectors.PollSelectorTestCase.test_above_fd_setsize	killed
	by shell
Message-ID: <1404254403.84.0.153705596072.issue21901@psf.upfronthosting.co.za>


New submission from R. David Murray:

On one particular linux vserver virtual machine (which is unfortunately my development platform for python), test.test_selectors.PollSelectorTestCase.test_above_fd_setsize fails with the following message:

   zsh: killed

and at that point the test suite stops running, regardless of whether or not I started it with -j.

As far as I can tell, the configuration of this vserver is the same as the one my buildbots run on, but they are on different host machines, so there could be some differences I'm not remembering.  On the buldbots, the test gets skipped with the message 'FD limit reached'.

Anyone have any clues how to debug this?

----------
components: asyncio
messages: 222059
nosy: gvanrossum, haypo, neologix, r.david.murray, yselivanov
priority: normal
severity: normal
status: open
title: test_selectors.PollSelectorTestCase.test_above_fd_setsize killed by shell
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul  2 06:31:19 2014
From: report at bugs.python.org (Kevin Davies)
Date: Wed, 02 Jul 2014 04:31:19 +0000
Subject: [New-bugs-announce] [issue21902] Docstring of math.acosh, asinh,
	and atanh
Message-ID: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>


New submission from Kevin Davies:

The docstring of acosh should more accurately be 
"Return the area hyperbolic cosine of x."
instead of 
"Return the hyperbolic arc cosine (measured in radians) of x."
asinh and atanh should be changed similarly.  The result of these functions is not an angle but a ratio of areas.  See 
http://en.wikipedia.org/wiki/Inverse_hyperbolic_function.

----------
messages: 222067
nosy: kdavies4
priority: normal
severity: normal
status: open
title: Docstring of math.acosh, asinh, and atanh

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

From report at bugs.python.org  Wed Jul  2 11:14:49 2014
From: report at bugs.python.org (Dan O'Donovan)
Date: Wed, 02 Jul 2014 09:14:49 +0000
Subject: [New-bugs-announce] [issue21903] ctypes documentation MessageBoxA
	example produces error
Message-ID: <1404292489.9.0.647841786316.issue21903@psf.upfronthosting.co.za>


New submission from Dan O'Donovan:

There is an example in the ctypes python3 documentation for producing a native Windows MessageBoxA 

https://docs.python.org/3.3/library/ctypes.html#ctypes.PYFUNCTYPE

Try as I might, I cannot get this example to run under python 3 (it is in the python3 documentation) - it always produces an error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type

I apologise for not attaching a fix, I have tried and cannot find one.

----------
assignee: docs at python
components: Documentation
messages: 222088
nosy: Dan.O'Donovan, docs at python
priority: normal
severity: normal
status: open
title: ctypes documentation MessageBoxA example produces error
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jul  2 13:54:10 2014
From: report at bugs.python.org (Steve Holden)
Date: Wed, 02 Jul 2014 11:54:10 +0000
Subject: [New-bugs-announce] [issue21904] Multiple closures accessing the
	same non-local variable	always see the same value
Message-ID: <1404302050.04.0.0402916465626.issue21904@psf.upfronthosting.co.za>


New submission from Steve Holden:

When repeated use of a nonlocal variable is made (e.g. to define multiple functions in a loop) ideally the closure should reflect the value of the local variable at the time of use. This should at least be explicitly documented if the behavior is considered not to be a bug.

The code sample attached shows that the closures produced operate differently inside and outside the enclosing function.

Without an explicit nonlocal declaration the closure should not be able to affect the nonlocal variable's value (which anyway hardly makes sense once the enclosing namespace has been destroyed), so I think it's possible to argue that this behavior is a bug, but I'd value comments from experienced developers.

----------
files: bugreport.py
keywords: needs review
messages: 222094
nosy: holdenweb
priority: normal
severity: normal
status: open
title: Multiple closures accessing the same non-local variable always see the same value
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file35829/bugreport.py

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

From report at bugs.python.org  Wed Jul  2 15:03:12 2014
From: report at bugs.python.org (Olivier Grisel)
Date: Wed, 02 Jul 2014 13:03:12 +0000
Subject: [New-bugs-announce] [issue21905] RuntimeError in pickle.whichmodule
	when sys.modules if	mutated
Message-ID: <1404306192.8.0.184744206475.issue21905@psf.upfronthosting.co.za>


New submission from Olivier Grisel:

`pickle.whichmodule` performs an iteration over `sys.modules` and tries to perform `getattr` calls on those modules. Unfortunately some modules such as those from the `six.moves` dynamic module can trigger imports when calling `getattr` on them, hence mutating the `sys.modules` dict and causing a `RuntimeError: dictionary changed size during iteration`.

This would also render `pickle.whichmodule` more thread-safe and cause concurrent thread perform new module imports and `whichmodule` calls.

The attach patch protect the iterator by copying the dict items into a fixed list.

I could write a tests involving dynamic module definitions as done in `six.moves` but it sounds very complicated for such a trivial fix.

----------
components: Library (Lib)
files: pickle_whichmodule.patch
keywords: patch
messages: 222099
nosy: Olivier.Grisel
priority: normal
severity: normal
status: open
title: RuntimeError in pickle.whichmodule  when sys.modules if mutated
type: crash
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35830/pickle_whichmodule.patch

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

From report at bugs.python.org  Wed Jul  2 17:38:52 2014
From: report at bugs.python.org (Torrin)
Date: Wed, 02 Jul 2014 15:38:52 +0000
Subject: [New-bugs-announce] [issue21906] Tools\Scripts\md5sum.py doesn't
	work in Python 3.4.1 on	Windows 7 64bit.
Message-ID: <1404315532.22.0.153511853972.issue21906@psf.upfronthosting.co.za>


New submission from Torrin:

md5sum.py uses at least 1 undefined object in Python 3.4.1.  I only tried this on Windows.  I have no idea if it is a problem on any other OS.


C:\>C:\Python27\python.exe --version
Python 2.7.6

C:\>C:\Python34\python.exe --version
Python 3.4.1

C:\>C:\Python34\python.exe C:\Python34\Tools\Scripts\md5sum.py C:\Python34\python.exe
Traceback (most recent call last):
  File "C:\Python34\Tools\Scripts\md5sum.py", line 90, in <module>
    sys.exit(main(sys.argv[1:], sys.stdout))
  File "C:\Python34\Tools\Scripts\md5sum.py", line 87, in main
    return sum(args, out)
  File "C:\Python34\Tools\Scripts\md5sum.py", line 27, in sum
    if files and isinstance(files[-1], file):
NameError: name 'file' is not defined

Here is why . . .

C:\>C:\Python27\python.exe -c "print(file)"
<type 'file'>

C:\>C:\Python34\python.exe -c "print(file)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'file' is not defined

So "file" is defined in 2.7.6 but not in 3.4.1.

----------
components: Demos and Tools
messages: 222109
nosy: torrin
priority: normal
severity: normal
status: open
title: Tools\Scripts\md5sum.py doesn't work in Python 3.4.1 on Windows 7 64bit.
versions: Python 3.4

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

From report at bugs.python.org  Wed Jul  2 21:16:42 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 02 Jul 2014 19:16:42 +0000
Subject: [New-bugs-announce] [issue21907] Update Windows build batch scripts
Message-ID: <1404328602.32.0.540869349126.issue21907@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I am aware of a few open issues with the build scripts provided for Windows (both the Tools/buildbot scripts and the .bat files provided in PCbuild), such as #9973 and #9822, and there are some other issues that bother me but that I haven't opened issues for.  Here's a patch which takes care of all of the issues I'm aware of, by almost completely rewriting most of the scripts.

An overview of the changes:

- Tools/buildbot/external*.bat are dead, replaced by PCbuild/get_externals.bat.  Since those scripts have been suggested for use by normal users by PCbuild/readme.txt and the devguide, stubs for Tools/buildbot/external.bat and external-amd64.bat still exist, which display a message suggesting PCbuild/get_externals.bat and then pass all arguments on to that script.

- PCbuild/get_externals.bat is a complete rewrite of Tools/buildbot/external-common.bat, and is written for users rather than buildbots.  It takes '-c/--clean' or '--clean-only' options, which will gently remove^W^W nuke from orbit all existing external library sources.

- PCbuild/build.bat has been updated to set up the environment itself, and to allow arguments to be passed to MSbuild, such as "/m" (though anything containing [ =,] (and possibly other characters) will require quotes to pass through properly, due to batch's wonderful argument handling abilities).  It has also grown an '-e' option, to pull in external libs using get_externals.bat.

- Tools/buildbot/build.bat has been updated to use PCbuild/build.bat, and Tool/buildbot/build-amd64.bat has been updated to use Tools/buildbot/build.bat.

- PCbuild/env.bat has been updated to allow for non-standard VS install locations, but really, it's obsolete with build.bat setting the environment itself.  I would prefer to eliminate PCbuild/build_env.bat and PCbuild/env.bat, but I don't know whether they're an integral part of other people's workflow and don't want to mess that up if they are.  There doesn't seem to be any harm from running the build with the environment set up twice.

- Tools/buildbot/clean.bat has been updated as I suggested in #9973, it has a set list of kill_python exes to try if they exist, then uses `hg purge` to clean *everything* out.  Tools/buildbot/clean-amd64.bat is now just a stub calling Tools/buildbot/clean.bat.

- Tools/buildbot/buildmsi.bat has a few updates, but I can't properly test them (having not yet managed to get an MSI built at all).  The script is currently unused anyway, as far as I know.

- Tools/buildbot/test[-amd64].bat have been updated to use Tools/scripts/run_tests.py, just like the UNIX buildbots.  run_tests.py has been updated to use subprocess.call instead of os.execv on Windows.

- All scripts have been made cwd-agnostic, by which I mean they should run the same way no matter where they are called from.  Also, every effort is made to not pollute the environment (even with VS setup).  They should also be a bit more robust against paths with spaces, but I make no guarantees about that.

- PCbuild/readme.txt has been updated to suggest PCbuild/get_externals.bat instead of Tools/buildbot/external*.bat, and has an added "Quick Start Guide" at the top.  A patch for the devguide will follow.

I think these changes make things simpler, with fewer places to update when options are changed, compilers upgraded, libraries updated, etc.  With this change, the simplest way to build on Windows becomes "PCbuild\build.bat -e" (or add "-d" for debug).  This is still not exactly what I want eventually (see #16895, which is now long out of date :), but is a solid step in that direction.

Most of these changes could be backported to 3.4, and at least a good portion of those to 2.7.  I'm not exactly sure how worth it that would be, though.

Thoughts?

----------
assignee: zach.ware
components: Build, Windows
files: better_bats.diff
keywords: buildbot, patch
messages: 222118
nosy: loewis, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Update Windows build batch scripts
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35831/better_bats.diff

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

From report at bugs.python.org  Wed Jul  2 21:32:52 2014
From: report at bugs.python.org (Jeremy Fusco)
Date: Wed, 02 Jul 2014 19:32:52 +0000
Subject: [New-bugs-announce] [issue21908] Grammatical error in 3.4 tutorial
Message-ID: <1404329572.95.0.36748102404.issue21908@psf.upfronthosting.co.za>


New submission from Jeremy Fusco:

https://docs.python.org/3/tutorial/controlflow.html

Sentence states 'most such' where either would suffice.

current: In most such cases, however, it is convenient to use the enumerate() function, see Looping Techniques

Proposed: In most cases

----------
assignee: docs at python
components: Documentation
messages: 222120
nosy: Jeremy.Fusco, docs at python
priority: normal
severity: normal
status: open
title: Grammatical error in 3.4 tutorial
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul  3 09:09:19 2014
From: report at bugs.python.org (Hristo Venev)
Date: Thu, 03 Jul 2014 07:09:19 +0000
Subject: [New-bugs-announce] [issue21909] PyLong_FromString drops const
Message-ID: <1404371359.19.0.197887236946.issue21909@psf.upfronthosting.co.za>


New submission from Hristo Venev:

PyObject* PyLong_FromString(const char *str, char **pend, int base)

pend should be const char**

I think casting const away when not required should be a crime punishable by imprisonment.

----------
messages: 222152
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyLong_FromString drops const

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

From report at bugs.python.org  Thu Jul  3 11:38:29 2014
From: report at bugs.python.org (Jan Kanis)
Date: Thu, 03 Jul 2014 09:38:29 +0000
Subject: [New-bugs-announce] [issue21910] File protocol should document if
	writelines must handle	generators sensibly
Message-ID: <1404380309.75.0.473808735546.issue21910@psf.upfronthosting.co.za>


New submission from Jan Kanis:

The resolution of issue 5445 should be documented somewhere properly, so people can depend on it or not.

IOBase.writelines handles generator arguments without problems, i.e. without first draining the entire generator and then writing the result in one go. That would require large amounts of memory if the generator is large, and fail entirely if the generator is infinite. 

codecs.StreamWriter.writelines uses self.write(''.join(argument)) as implementation, which fails on very large or infinite arguments.

According to issue 5445 it is not part of the file protocol that .writelines must handle (large/infinite) generators, only list-like iterables. However as far as I know this is not documented anywhere, and sometimes people assume that writelines is meant for this case. E.g. jinja (https://github.com/mitsuhiko/jinja2/blob/master/jinja2/environment.py#L1153, the dump method is explicitly documented to stream). The guarantees that .writelines makes or does not make in this regard should be documented somewhere, so that either .writeline implementations that don't handle large generators can be pointed out as bugs, or code that makes assumptions on .writeline handling large generators can be.

I personally think .writelines should handle large generators, since in the python 3 world a lot of apis were iterator-ified and it is wat a lot of people would probably expect. But having a clear and documented decision on this is more important. 

(note: I've copied most of the nosy list from #5445)

----------
assignee: docs at python
components: Documentation, IO
messages: 222165
nosy: JanKanis, benjamin.peterson, dlesco, docs at python, hynek, lemburg, pitrou, stutzbach, terry.reedy
priority: normal
severity: normal
status: open
title: File protocol should document if writelines must handle generators sensibly
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul  3 14:33:14 2014
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 03 Jul 2014 12:33:14 +0000
Subject: [New-bugs-announce] [issue21911] "IndexError: tuple index out of
	range" should include	the requested index and tuple length
Message-ID: <1404390794.54.0.630083668536.issue21911@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Ditto for lists and any other place this could be applicable.

----------
components: Interpreter Core
messages: 222168
nosy: cool-RR
priority: normal
severity: normal
status: open
title: "IndexError: tuple index out of range" should include the requested index and tuple length
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jul  3 14:44:01 2014
From: report at bugs.python.org (Jonas Diemer)
Date: Thu, 03 Jul 2014 12:44:01 +0000
Subject: [New-bugs-announce] [issue21912] Deferred logging may use outdated
	references
Message-ID: <1404391441.7.0.556517344659.issue21912@psf.upfronthosting.co.za>


New submission from Jonas Diemer:

I was having trouble with the logging module under Jython: I was getting seemingly sporadic wierd null pointer exceptions in the logging code. 

The problem seemed to be related to references that were passed to the logger, e.g.

logger.debug("My object: %s", myObject)

It seems that logging defers the actual string formatting (maybe only when logging to files). By the time the string is formatted, the reference to the object may no longer be valid. In my case, myObject was a reference to a Java-class that had been invalidated.

Initially, I thought this was only a Java issue. But it seems like this could be an issue with pure Python scripts as well. E.g., what happens if the object behind myObject is changed after the call to debug(), but before the actual log message is formatted?

----------
components: Library (Lib)
messages: 222171
nosy: Jonas.Diemer
priority: normal
severity: normal
status: open
title: Deferred logging may use outdated references
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  4 02:40:19 2014
From: report at bugs.python.org (Sangeeth Saravanaraj)
Date: Fri, 04 Jul 2014 00:40:19 +0000
Subject: [New-bugs-announce] [issue21913] Possible deadlock in
	threading.Condition.wait() in	Python 2.7.7
Message-ID: <1404434419.41.0.802359833018.issue21913@psf.upfronthosting.co.za>


New submission from Sangeeth Saravanaraj:

Python version 2.7.7
Mac OS Darwin Kernel Version 13.2.0

I have the following code which when executed waits to be interrupted by SIGINT, SIGTERM or SIGQUIT. When an object is initialized, it creates a threading.Condition() and acquires() it! The program then registers the signal handlers where notify() and release() is called when the above mentioned signals are received. After registering the signal handlers, it calls wait() on the condition variable and block.

When I tried to stop the program with Ctrl-C, its did not respond. IOW, the _signal_handler() method did not get called.  

# start

from signal import signal, SIGINT, SIGTERM, SIGQUIT
from threading import Condition

class A:
    def __init__(self):
        self._termination_signal = Condition()
        self._termination_signal.acquire(blocking=0)

    def _signal_handler(self, signum, frame):
        print "Received terminate request - signal = {0}".format(signum)
        del frame
        self._termination_signal.notify()
        self._termination_signal.release()
        return

    def register_and_wait(self):
        signal(SIGINT, self._signal_handler)
        signal(SIGTERM, self._signal_handler)
        signal(SIGQUIT, self._signal_handler)
        print "Waiting to be interrupted!"
        self._termination_signal.wait()      # control blocks here!
        print "Notified!!"

def main():
    a = A()
    a.register_and_wait()

if __name__ == "__main__":
    main()

# end


When the same code was tried in Python 3.4, it threw a "RuntimeError: cannot notify on un-acquired lock".

More information is available in this conversation in python-list mailer - https://mail.python.org/pipermail/python-list/2014-July/674350.html

----------
components: Library (Lib)
messages: 222250
nosy: pitrou, sangeeth
priority: normal
severity: normal
status: open
title: Possible deadlock in threading.Condition.wait() in Python 2.7.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  4 04:47:17 2014
From: report at bugs.python.org (Lita Cho)
Date: Fri, 04 Jul 2014 02:47:17 +0000
Subject: [New-bugs-announce] [issue21914] Create unit tests for Turtle
	guionly
Message-ID: <1404442037.11.0.611165319303.issue21914@psf.upfronthosting.co.za>


New submission from Lita Cho:

Create unit tests for the Turtle library, specifically on their gui commands.

----------
components: Library (Lib), Tkinter
messages: 222259
nosy: Lita.Cho, jesstess
priority: normal
severity: normal
status: open
title: Create unit tests for Turtle guionly
versions: Python 3.5

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

From report at bugs.python.org  Fri Jul  4 05:02:55 2014
From: report at bugs.python.org (Garrett Cooper)
Date: Fri, 04 Jul 2014 03:02:55 +0000
Subject: [New-bugs-announce] [issue21915] telnetlib.Telnet constructor does
	not match	telnetlib.Telnet.__init__ docstring
Message-ID: <1404442975.51.0.177790858493.issue21915@psf.upfronthosting.co.za>


New submission from Garrett Cooper:

telnetlib.Telnet.__init__ supports keyword arguments, but the documentation for 2.7.8 ( https://docs.python.org/2/library/telnetlib.html ) claims they're non-keyword arguments.

The py3k docs are much better ( https://docs.python.org/3/library/telnetlib.html ), but unfortunately they still claim that timeout is a non-keyword argument.

----------
assignee: docs at python
components: Documentation
messages: 222263
nosy: docs at python, yaneurabeya
priority: normal
severity: normal
status: open
title: telnetlib.Telnet constructor does not match telnetlib.Telnet.__init__ docstring

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

From report at bugs.python.org  Fri Jul  4 15:12:44 2014
From: report at bugs.python.org (ingrid)
Date: Fri, 04 Jul 2014 13:12:44 +0000
Subject: [New-bugs-announce] [issue21916] Create unit tests for turtle
	textonly
Message-ID: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za>


New submission from ingrid:

Non-gui tests for turtle that Lita and I wrote.

----------
components: Tests
files: test_turtle_textonly.patch
keywords: patch
messages: 222282
nosy: ingrid, jesstess
priority: normal
severity: normal
status: open
title: Create unit tests for turtle textonly
versions: Python 3.5
Added file: http://bugs.python.org/file35856/test_turtle_textonly.patch

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

From report at bugs.python.org  Fri Jul  4 17:26:25 2014
From: report at bugs.python.org (repcsike)
Date: Fri, 04 Jul 2014 15:26:25 +0000
Subject: [New-bugs-announce] [issue21917] Python 2.7.7 Tests fail,
	and math is faulty
Message-ID: <1404487585.95.0.614197630054.issue21917@psf.upfronthosting.co.za>


New submission from repcsike:

Python is built with IBM XLC compiler, some tests fail and after installation mathematical executions are giving bad results. I corrected the _sysconfigdata.py bug (issue18235) with ld_so_aix , and found this out when tried to install some modules.
 
Please see this other issue for the other tests:
https://github.com/warner/python-ecdsa/issues/28

# ./configure --with-gcc="xlc_r -q64" AR="ar -X64" --prefix=/usr/local/Python-2.7.7_64_test

# make

# make test
running build_scripts
        find ./Lib -name '*.py[co]' -print | xargs rm -f
         ./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 220, in <module>
    TEMPDIR = os.path.abspath(tempfile.gettempdir())
  File "/tmp/Python-2.7.7/Lib/tempfile.py", line 269, in gettempdir
    tempdir = _get_default_tempdir()
  File "/tmp/Python-2.7.7/Lib/tempfile.py", line 197, in _get_default_tempdir
    fd = _os.open(filename, flags, 0o600)
OverflowError: signed integer is greater than maximum
make: 1254-004 The error code from the last command is 1.
make: 1254-005 Ignored error code 1 from last command.
         ./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 220, in <module>
    TEMPDIR = os.path.abspath(tempfile.gettempdir())
  File "/tmp/Python-2.7.7/Lib/tempfile.py", line 269, in gettempdir
    tempdir = _get_default_tempdir()
  File "/tmp/Python-2.7.7/Lib/tempfile.py", line 197, in _get_default_tempdir
    fd = _os.open(filename, flags, 0o600)
OverflowError: signed integer is greater than maximum
make: 1254-004 The error code from the last command is 1.


Stop.

----------
components: Build
messages: 222291
nosy: repcsike
priority: normal
severity: normal
status: open
title: Python 2.7.7 Tests fail, and math is faulty
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  4 20:48:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Jul 2014 18:48:13 +0000
Subject: [New-bugs-announce] [issue21918] Convert test_tools to directory
Message-ID: <1404499693.28.0.512453806731.issue21918@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Lib/test/test_tools.py becomes too large. It includes tests of unrelated command-lines tools and scripts. It would be good to convert it to directory containing separate test files for different tools.

----------
components: Tests
messages: 222305
nosy: berker.peksag, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Convert test_tools to directory
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul  4 22:45:25 2014
From: report at bugs.python.org (Eldar Abusalimov)
Date: Fri, 04 Jul 2014 20:45:25 +0000
Subject: [New-bugs-announce] [issue21919] Changing cls.__bases__ must ensure
	proper metaclass	inheritance
Message-ID: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>


New submission from Eldar Abusalimov:

When a new class is constructed Python checks for possible metaclass conflicts within bases and an explicitly specified one, if any, choosing the best available (the most specialized) one. That is the following implication is expected:

    issubclass(B, A) => issubclass(type(B), type(A))

However, changing __bases__ attribute can break this invariant silently without an error.

>>> class O(object):
...     pass
... 
>>> class M(type):
...     pass
... 
>>> class N(type):
...     pass
... 
>>> class A(O, metaclass=M):
...     pass
... 
>>> class B(O, metaclass=N):
...     pass
... 
>>> B.__bases__ = (A,)
>>> B.__mro__
(<class '__main__.B'>, <class '__main__.A'>, <class '__main__.O'>, <class 'object'>)
>>> type(B)
<class '__main__.N'>
>>> type(A)
<class '__main__.M'>
>>> issubclass(B, A)
True
>>> issubclass(type(B), type(A))
False

Trying to derive from B now makes things look pretty weird:

>>> class C(A, metaclass=N):
...     pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
>>> class D(B, A): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
>>> class E(B, metaclass=N):
...     pass
... 
>>> type(E)
<class '__main__.N'>

That is one can extend a class but not its base (and not a class along its base). This effectively allows to bypass metaclass checks (by introducing a dummy class with the default metaclass, deriving it from a desired class with an inappropriate metaclass by changing __bases__ and using it instead of the desired class).

This behavior is observed in 2.7, 3.2 and 3.4.


I would expect the same check for metaclass conflicts when changing __bases__ as upon creating a new class:

>>> # EXPECTED:
... 
>>> B.__bases__ = (A,)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

----------
components: Interpreter Core
messages: 222312
nosy: Eldar.Abusalimov
priority: normal
severity: normal
status: open
title: Changing cls.__bases__ must ensure proper metaclass inheritance
type: behavior
versions: Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Sat Jul  5 10:01:27 2014
From: report at bugs.python.org (Stefan Tatschner)
Date: Sat, 05 Jul 2014 08:01:27 +0000
Subject: [New-bugs-announce] [issue21920] Fixed missing colon in the docs
Message-ID: <1404547287.88.0.816542299349.issue21920@psf.upfronthosting.co.za>


New submission from Stefan Tatschner:

Hi,
i just discovered a missing colon in the docs. I have created a patch for this.

Stefan

----------
assignee: docs at python
components: Documentation
files: fixed-missing-colon.patch
keywords: patch
messages: 222341
nosy: docs at python, rumpelsepp
priority: normal
severity: normal
status: open
title: Fixed missing colon in the docs
versions: Python 3.4
Added file: http://bugs.python.org/file35865/fixed-missing-colon.patch

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

From report at bugs.python.org  Sat Jul  5 10:45:13 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 05 Jul 2014 08:45:13 +0000
Subject: [New-bugs-announce] [issue21921] Example in asyncio event throws
	resource usage warning
Message-ID: <1404549913.45.0.543657172277.issue21921@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

These examples coming from:
https://docs.python.org/3/library/asyncio-eventloop.html#example-hello-world-callback

and

https://docs.python.org/3/library/asyncio-eventloop.html#example-set-signal-handlers-for-sigint-and-sigterm

throw resource usage warning.

One of them gives this output:
Event loop running forever, press CTRL+c to interrupt.
pid 3075: send SIGINT or SIGTERM to exit.
^Cgot signal SIGINT: exit
sys:1: ResourceWarning: unclosed <socket object at 0x7f7124783448>
sys:1: ResourceWarning: unclosed <socket object at 0x7f7124c230e8>

The patch adds closing the loop code in the examples.

----------
assignee: docs at python
components: Documentation, asyncio
files: close_loop_on_example.patch
keywords: patch
messages: 222344
nosy: docs at python, gvanrossum, haypo, vajrasky, yselivanov
priority: normal
severity: normal
status: open
title: Example in asyncio event throws resource usage warning
type: resource usage
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35866/close_loop_on_example.patch

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

From report at bugs.python.org  Sat Jul  5 14:22:24 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sat, 05 Jul 2014 12:22:24 +0000
Subject: [New-bugs-announce] [issue21922] PyLong: use GMP
Message-ID: <1404562944.87.0.0403783440946.issue21922@psf.upfronthosting.co.za>


New submission from Hristo Venev:

I have implemented the PyLong interface using the GMP mpn functions. API/ABI compatibility is retained (except for longintrepr).

It can be enabled by passing --enable-big-digits=gmp to ./configure.

No large performance regressions have been observed for small numbers (a few operations are about 10% slower). For large numbers some operations are a lot faster.

There is also int.__gcd__ which may be used by fractions.gcd.

The GIL is sometimes released. Minimum number of digis for releasing GIL: 
- multiplication - 64
- division - 64,
- modular exponentiation - 16,
- base conversion - 64 (256 for binary bases)
- GCD - 16

The tests for long, float, decimal, fractions, string, unicode, bytes, pickle, marshal and enum pass. The tests for int fail because the error messages are a bit different (when creating int from bytes or bytearray the value is not shown). I may have run other tests and they have not failed. I have not tested on anything but x86-64.

The following testcases yield 42x performace improvement:
- 16384-bit RSA on 8 threads on quad-core with HT # GIL released
- Multiplying 5600000-bit ints
- Dividing 6000000-bit ints
- Converting 300000-character str to int(base=10)
- Converting 1250000-bit int to str

----------
components: Interpreter Core
messages: 222347
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyLong: use GMP
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Sat Jul  5 18:44:20 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 05 Jul 2014 16:44:20 +0000
Subject: [New-bugs-announce] [issue21923]
	distutils.sysconfig.customize_compiler will try to
	read	variable that has not been initialized
Message-ID: <1404578660.09.0.628845153111.issue21923@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

If one invokes some distutils code too early, this function will try to read ``_config_vars`` before it is initialized. http://bpaste.net/show/1DOGhL8sdnkPyLTL06AZ/ is an example traceback that results.

The attached patch uses the public API which guarantees that it is defined.

----------
components: Distutils
files: sysconfig.diff
keywords: patch
messages: 222373
nosy: alex, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.sysconfig.customize_compiler will try to read variable that has not been initialized
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file35870/sysconfig.diff

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

From report at bugs.python.org  Sun Jul  6 02:30:33 2014
From: report at bugs.python.org (Peter Inglesby)
Date: Sun, 06 Jul 2014 00:30:33 +0000
Subject: [New-bugs-announce] [issue21924] Cannot import anything that
	imports tokenize from script	called token.py
Message-ID: <1404606633.02.0.0390950296543.issue21924@psf.upfronthosting.co.za>


New submission from Peter Inglesby:

A script called token.py that imports anything that ends up importing tokenize, such as logging, triggers the following error when the script is run:

$ cat token.py 
import tokenize
$ python3 token.py
Traceback (most recent call last):
  File "token.py", line 1, in <module>
    import tokenize
  File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tokenize.py", line 38, in <module>
    __all__ = token.__all__ + ["COMMENT", "tokenize", "detect_encoding",
AttributeError: 'module' object has no attribute '__all__'

----------
messages: 222386
nosy: inglesp
priority: normal
severity: normal
status: open
title: Cannot import anything that imports tokenize from script called token.py
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul  6 04:49:33 2014
From: report at bugs.python.org (Masami HIRATA)
Date: Sun, 06 Jul 2014 02:49:33 +0000
Subject: [New-bugs-announce] [issue21925] ResouceWarning sometimes doesn't
	display
Message-ID: <1404614973.3.0.388136336832.issue21925@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

It seems that ResouceWarning about unclosed file handles with '-W all' option sometimes doesn't display.
Is this behaviour normal?

$ uname -a
Linux ashrose 3.2.0-65-generic #99-Ubuntu SMP Fri Jul 4 21:03:29 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ python3.4 --version
Python 3.4.1
$ touch spam.txt
$ echo 'a = open("spam.txt")' >test_warning.py
$
$ python3.4 -W all test_warning.py
$ python3.4 -W all test_warning.py
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='spam.txt' mode='r' encoding='UTF-8'>
$ python3.4 -W all test_warning.py
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='spam.txt' mode='r' encoding='UTF-8'>
$ python3.4 -W all test_warning.py
$ python3.4 -W all test_warning.py
$ python3.4 -W all test_warning.py
$ python3.4 -W all test_warning.py
$ python3.4 -W all test_warning.py
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='spam.txt' mode='r' encoding='UTF-8'>
$

----------
components: Interpreter Core
messages: 222390
nosy: msmhrt
priority: normal
severity: normal
status: open
title: ResouceWarning sometimes doesn't display
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul  6 08:04:03 2014
From: report at bugs.python.org (Ben Lucato)
Date: Sun, 06 Jul 2014 06:04:03 +0000
Subject: [New-bugs-announce] [issue21926] Bundle C++ compiler with Python on
	Windows
Message-ID: <1404626643.71.0.229210257111.issue21926@psf.upfronthosting.co.za>


New submission from Ben Lucato:

I am wondering if it is at all on the roadmap to bundle a C compiler with Python on Windows, given that installing libraries with C extensions is very confusing on Windows.

For example, to install NumPy on Windows you end up either having to download the right version of Visual Studio or install it from the list of precompiled libraries at http://www.lfd.uci.edu/~gohlke/pythonlibs/. The problem is, either of those solutions feel quite bloated and aren't easily apparent when searching for fixes online.

BTW, since this is my first issue I looked around for a guide on how to submit issues but I couldn't find one - so I hope I'm raising it right.

----------
components: Windows
messages: 222395
nosy: Ben.Lucato
priority: normal
severity: normal
status: open
title: Bundle C++ compiler with Python on Windows
versions: Python 3.5

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

From report at bugs.python.org  Sun Jul  6 16:39:22 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 06 Jul 2014 14:39:22 +0000
Subject: [New-bugs-announce] [issue21927] BOM appears in stdin when using
	Powershell
Message-ID: <1404657562.39.0.323212380566.issue21927@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Consider this simple example in Powershell (Windows 8.1):

C:\Users\jaraco> cat .\print-input.py
import sys
print(next(sys.stdin))

C:\Users\jaraco> echo foo | .\print-input.py
???foo

The BOM (byte order mark) appears in the standard input stream. When using cmd.exe, the BOM is not present. This behavior occurs in CP1252 as well as CP65001.

I suspect that Python should be detecting/stripping and possibly honoring the BOM when decoding input on stdin.

This issue is present in Python 3.4.0 and Python 3.4.1. I have not tested other Python versions.

----------
components: Unicode, Windows
messages: 222406
nosy: ezio.melotti, haypo, jason.coombs
priority: normal
severity: normal
status: open
title: BOM appears in stdin when using Powershell
versions: Python 3.4

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

From report at bugs.python.org  Mon Jul  7 02:05:51 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Mon, 07 Jul 2014 00:05:51 +0000
Subject: [New-bugs-announce] [issue21928] Incorrect reference to partial()
	in functools.wraps	documentation
Message-ID: <1404691551.32.0.43724066382.issue21928@psf.upfronthosting.co.za>


New submission from Dustin Oprea:

functools.wraps docs say "This is a convenience function for invoking partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated) as a function decorator when defining a wrapper function." The referenced function should be update_wrapper(), not partial().

----------
assignee: docs at python
components: Documentation
messages: 222426
nosy: Dustin.Oprea, docs at python
priority: normal
severity: normal
status: open
title: Incorrect reference to partial() in functools.wraps documentation
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Jul  7 12:35:06 2014
From: report at bugs.python.org (Jeroen de Jong)
Date: Mon, 07 Jul 2014 10:35:06 +0000
Subject: [New-bugs-announce] [issue21929] Rounding properly
Message-ID: <1404729306.28.0.45044219182.issue21929@psf.upfronthosting.co.za>


New submission from Jeroen de Jong:

I ma trying to find a way to round correctly. So far I get unexpected results for some values.

----------
components: Windows
files: Rounding.py
messages: 222444
nosy: jeroen1225
priority: normal
severity: normal
status: open
title: Rounding properly
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35880/Rounding.py

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

From report at bugs.python.org  Mon Jul  7 13:25:24 2014
From: report at bugs.python.org (Pavel Tyslyatsky)
Date: Mon, 07 Jul 2014 11:25:24 +0000
Subject: [New-bugs-announce] [issue21930] new assert raises syntax proposal
Message-ID: <1404732324.49.0.351341465779.issue21930@psf.upfronthosting.co.za>


New submission from Pavel Tyslyatsky:

This proposal look preaty close to pep-463: http://legacy.python.org/dev/peps/pep-0463/, but in assertion context.

Now python test libraries have different aproach for assertions, some try use own implementations, for example, for equality `assertEqual` (`assertEqulas`), `eq_`, some use python `assert` keyword.

`assert` work fine for variables, but requred verbose wrappers for exception raising, for example:

>>> try:
...   do_raise_code()
... except Exception:
...   assert False

Test libraries already have self implementations but it still not pure python like `assert`:

unittest: `self.assertRaises`
py.test: `pytest.raises`
nose: `nose.tools.raises` or `nose.tools.assert_raises`

I propose add pure python implementation for this case because it enough popular, for example:

>>> assert do_raise_code() raises  # ok if `do_raise_code` raise any exception
>>> assert do_raise_code() raises, 'text message'  # ok if `do_raise_code` raise any exception with message
>>> assert do_raise_code() raises Exception  # ok if `do_raise_code` raise specific exception
>>> assert do_raise_code() raises Exception, 'text message'  # ok if `do_raise_code` raise specific exception with message
>>> assert do_raise_code() raises (TypeError, ValueError)  # ok if `do_raise_code` raise one of specific exceptions
>>> assert do_raise_code() raises (TypeError, ValueError), 'text message'  # ok if `do_raise_code` raise one of specific exceptions with message

Test libraries can use tham raises implementations as decorator, this proposal currently ignore similar behaviour.
Test libraries can use them raises implementations as context, this propasal currently ignore similar behaviour.
`unittest` module also has `assertRaisesRegex` method, this proposal currently ignore similar behaviour.
`unittest` module also has `assertWarns` and `assertLogs`, this proposal currently ignore similar behaviour.
Also this proposal currently ignore any access to exception object and it fields.

----------
messages: 222450
nosy: tbicr
priority: normal
severity: normal
status: open
title: new assert raises syntax proposal
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jul  7 14:53:10 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Mon, 07 Jul 2014 12:53:10 +0000
Subject: [New-bugs-announce] [issue21931] Nonsense errors reported by
	msilib.FCICreate for bad	argument
Message-ID: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

The function fcicreate in PC/_msi.c can return nonsense if the list of files passed to msilib.FCICreate does not contains tuples as expected.  To replicate,

import msilib
msilib.FCICreate("test.cab", ["entry.txt"])

The above code will return a ValueError of the format:

ValueError: FCI error 11260524

The error code is meaningless.  If one were to examine the code, you can see in PC/_msi.c:246 (in "current"):


        if (!PyArg_ParseTuple(item, "ss", &filename, &cabname))
            goto err;

If we look at the error handler at PC/_msi.c:262, it assumes that one of the Windows MSI API calls had failed, and will print the contents of the ERF error structure:

err:
    PyErr_Format(PyExc_ValueError, "FCI error %d", erf.erfOper); /* XXX better error type */

In the case where the list does not contain tuples, the value of erf.erfOper was never initialized or set because the error being raised is not due to the Windows MSI API.  The error is highly misleading as it is simply an argument error.

----------
components: Extension Modules
messages: 222458
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Nonsense errors reported by msilib.FCICreate for bad argument
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jul  7 15:37:54 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2014 13:37:54 +0000
Subject: [New-bugs-announce] [issue21932] os.read() must use Py_ssize_t for
	the size parameter
Message-ID: <1404740274.81.0.177768774974.issue21932@psf.upfronthosting.co.za>


New submission from STINNER Victor:

os.read() currently uses the int type for the size parameter, whereas the C function uses a C size_t parameter:

       ssize_t read(int fd, void *buf, size_t count);

The Python function must use the Py_ssize_t type, but truncate to INT_MAX on Windows, as done in FileIO.read(). It would help to implement FileIO in pure Python: issue #21859.

I don't think that this enhancement should be backported to Python 2.7 nor Python 3.4.

----------
files: posix_read_py_ssize_t.patch
keywords: patch
messages: 222462
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: os.read() must use Py_ssize_t for the size parameter
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35882/posix_read_py_ssize_t.patch

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

From report at bugs.python.org  Mon Jul  7 17:18:15 2014
From: report at bugs.python.org (Lita Cho)
Date: Mon, 07 Jul 2014 15:18:15 +0000
Subject: [New-bugs-announce] [issue21933] Allow the user to change font
	sizes with the text pane	of turtledemo
Message-ID: <1404746295.5.0.877343308699.issue21933@psf.upfronthosting.co.za>


New submission from Lita Cho:

Currently, the turtledemo doesn't allow you to change font sizes of the demo code, and the default font size is really small.

I can work on creating a patch to fix this. Best option be to have control-mousewheel change size, as is standard in browsers, as well as Ctrl + and Ctrl - to change sizes (since laptops don't have a mousewheel). 

If tk has a problem with that, a second choice would be a menu entry "Font size with choices such as the current size (9?), 10, 12, 14.

Also, update the Help Text of this new feature.

----------
messages: 222466
nosy: Lita.Cho, jesstess, ned.deily, terry.reedy
priority: normal
severity: normal
status: open
title: Allow the user to change font sizes with the text pane of turtledemo
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jul  7 17:30:13 2014
From: report at bugs.python.org (Daniel Dickman)
Date: Mon, 07 Jul 2014 15:30:13 +0000
Subject: [New-bugs-announce] [issue21934] OpenBSD has no /dev/full device
Message-ID: <1404747013.93.0.393614299649.issue21934@psf.upfronthosting.co.za>


New submission from Daniel Dickman:

There is no /dev/full device on OpenBSD. If you run the 2.7 regress tests as root on OpenBSD, a /dev/full regular file will be created and the "test_write_full" test will fail. (because the subsequent write will succeed in writing to the /dev/full regular file).

To fix, change the test to check that /dev/full exists and is a character device.

Patch attached.

----------
components: Tests
messages: 222467
nosy: Daniel.Dickman
priority: normal
severity: normal
status: open
title: OpenBSD has no /dev/full device
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  7 23:00:23 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Mon, 07 Jul 2014 21:00:23 +0000
Subject: [New-bugs-announce] [issue21935] Implement AUTH command in smtpd.
Message-ID: <1404766823.82.0.391401675174.issue21935@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

I implemented message processing for LOGIN and PLAIN authentication in smtpd. I also patched test_smtplib to make use of this functionality.

The goal for the API is to provide decryption and message processing in the smtpd library and call a externally provided or overwritten function(user, password) to verify credentials.

The patch provided is missing documentation and a proper API to use/activate this feature (and API specific tests of cause). Things which need to be discussed:
a) how shoud AUTH be activated? (when should MAIL etc. require AUTH? when should 'AUTH' be announced in the EHLO response?)
b) how should the programmer change the _verify_user_credentials method?

My idea to solve a and b at once would be to set the verification function by a keyword argument and require/activate AUTH if this kwarg is set.

I didn't implement CRAM-MD5 because it requires the correct password to be available in plain text.

----------
components: email
files: smtpd_AUTH.patch
keywords: patch
messages: 222516
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Implement AUTH command in smtpd.
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35895/smtpd_AUTH.patch

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

From report at bugs.python.org  Mon Jul  7 23:26:34 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2014 21:26:34 +0000
Subject: [New-bugs-announce] [issue21936]
	test_future_exception_never_retrieved() of test_asyncio	fails
	on AMD64 Debian root 3.x
Message-ID: <1404768394.83.0.876638783758.issue21936@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/915/steps/test/logs/stdio

======================================================================
FAIL: test_future_exception_never_retrieved (test.test_asyncio.test_futures.FutureTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/mock.py", line 1152, in patched
    return func(*args, **keywargs)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_asyncio/test_futures.py", line 329, in test_future_exception_never_retrieved
    m_log.error.assert_called_once_with(mock.ANY, exc_info=exc_info)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/mock.py", line 797, in assert_called_once_with
    raise AssertionError(msg)
AssertionError: Expected 'error' to be called once. Called 3 times.

----------
components: Tests, asyncio
keywords: buildbot
messages: 222521
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: test_future_exception_never_retrieved() of test_asyncio fails on AMD64 Debian root 3.x
versions: Python 3.5

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

From report at bugs.python.org  Tue Jul  8 06:42:03 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Jul 2014 04:42:03 +0000
Subject: [New-bugs-announce] [issue21937] IDLE interactive window doesn't
	display unsaved-indicator
Message-ID: <1404794523.71.0.976776826141.issue21937@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

* Open a Python Shell
* Save as session_log.txt
* Type a line of code
* Notice that the asterisk for "unsaved" does not appear

----------
components: IDLE
messages: 222542
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE interactive window doesn't display unsaved-indicator
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jul  8 13:02:00 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 08 Jul 2014 11:02:00 +0000
Subject: [New-bugs-announce] [issue21938] Py_XDECREF statement in
	gen_iternext()
Message-ID: <1404817320.2.0.605121131918.issue21938@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The Py_XDECREF statement in gen_iternext() at Objects/genobject.c is not needed since val is NULL (may be optimized out by the compiler).
Actually, the whole function could be written as:

    return gen_send_ex(gen, NULL, 0);

----------
components: Interpreter Core
messages: 222556
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Py_XDECREF statement in gen_iternext()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Jul  8 16:19:46 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Tue, 08 Jul 2014 14:19:46 +0000
Subject: [New-bugs-announce] [issue21939] IDLE - Test Percolator
Message-ID: <1404829186.29.0.812778916434.issue21939@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Attached is a unittest for idlelib.Percolator.
2.7 version will be added once this is OK.

----------
components: IDLE
files: test_percolator-34.diff
keywords: patch
messages: 222561
nosy: jesstess, sahutd, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - Test Percolator
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35899/test_percolator-34.diff

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

From report at bugs.python.org  Tue Jul  8 16:37:15 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Tue, 08 Jul 2014 14:37:15 +0000
Subject: [New-bugs-announce] [issue21940] IDLE - Test WidgetRedirector
Message-ID: <1404830235.88.0.167497005824.issue21940@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Attached is unittest for idlelib.WidgetRedirector
2.7 version will be uploaded once this is OK.

----------
components: Extension Modules
files: test-widgetredir-34.diff
keywords: patch
messages: 222563
nosy: jesstess, sahutd, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - Test WidgetRedirector
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35900/test-widgetredir-34.diff

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

From report at bugs.python.org  Wed Jul  9 04:46:29 2014
From: report at bugs.python.org (ingrid)
Date: Wed, 09 Jul 2014 02:46:29 +0000
Subject: [New-bugs-announce] [issue21941] Clean up turtle TPen class
Message-ID: <1404873989.47.0.448854632734.issue21941@psf.upfronthosting.co.za>


New submission from ingrid:

There are a lot of methods in the TPen class that are defined but not used because all the child classes overwrite almost all the functions and TPen itself isn't used directly a whole lot. This patch removes the unused code so it's less confusing to read turtle.py.

----------
components: Library (Lib)
files: TPen_cleanup.patch
keywords: patch
messages: 222598
nosy: ingrid, jesstess
priority: normal
severity: normal
status: open
title: Clean up turtle TPen class
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35909/TPen_cleanup.patch

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

From report at bugs.python.org  Wed Jul  9 05:13:14 2014
From: report at bugs.python.org (Eric Galloway)
Date: Wed, 09 Jul 2014 03:13:14 +0000
Subject: [New-bugs-announce] [issue21942] pydoc source not displayed in
	browser on Windows
Message-ID: <1404875594.67.0.480533952364.issue21942@psf.upfronthosting.co.za>


New submission from Eric Galloway:

In Python 3 on Windows, pydoc fails to display source file listings in the browser.

To reproduce in Python 3.4:

   1. start pydoc:
   
   python -m pydoc -p 8888

   2. Navigate to the url: 
   
   http://127.0.0.1:8888/getfile?key=///C:/python34/lib/pydoc.py

The error message:

    getfile?key=///C:/python34/lib/pydoc.py
                FileNotFoundError: [Errno 2] No such file or directory: '///C:/python34/lib/pydoc.py'
            
The url passed to html_getfile needs to be converted into a NT pathname.

----------
components: Library (Lib)
files: diff.txt
messages: 222599
nosy: Eric.Galloway
priority: normal
severity: normal
status: open
title: pydoc source not displayed in browser on Windows
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35910/diff.txt

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

From report at bugs.python.org  Wed Jul  9 11:11:52 2014
From: report at bugs.python.org (Toni Diaz)
Date: Wed, 09 Jul 2014 09:11:52 +0000
Subject: [New-bugs-announce] [issue21943] To duplicate a list has biyective
	properties, not inyective ones
Message-ID: <1404897112.14.0.409769296554.issue21943@psf.upfronthosting.co.za>


New submission from Toni Diaz:

Python 2.7.3 (default, Mar 13 2014, 11:03:55) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a=['dog']
>>> b=a
>>> a
['dog']
>>> b
['dog']
>>> b.remove('dog')
>>> a
[]
>>> b
[]
>>>

When defining a list from another (b=a), in my opinion, I expect that all you do to one doesn't affect to the other one.
However, with the commands .remove & .append I don't see that (the definition b=a is bijective).
Should it work this way?

Thanks

----------
components: Demos and Tools
messages: 222606
nosy: Toni Diaz
priority: normal
severity: normal
status: open
title: To duplicate a list has biyective properties, not inyective ones
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul  9 13:52:09 2014
From: report at bugs.python.org (Robert Lehmann)
Date: Wed, 09 Jul 2014 11:52:09 +0000
Subject: [New-bugs-announce] [issue21944] Allow copying of CodecInfo objects
Message-ID: <1404906729.25.0.633895333058.issue21944@psf.upfronthosting.co.za>


New submission from Robert Lehmann:

CodecInfo objects as retrieved from codecs.lookup currently throw an exception when trying to copy or pickle them.

I have attached a patch with a fix and tests.

----------
components: Library (Lib)
files: copy_codecinfo.patch
keywords: patch
messages: 222609
nosy: lehmannro
priority: normal
severity: normal
status: open
title: Allow copying of CodecInfo objects
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35912/copy_codecinfo.patch

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

From report at bugs.python.org  Wed Jul  9 14:37:55 2014
From: report at bugs.python.org (LtWorf)
Date: Wed, 09 Jul 2014 12:37:55 +0000
Subject: [New-bugs-announce] [issue21945] Wrong grammar in documentation
Message-ID: <1404909475.04.0.739880818459.issue21945@psf.upfronthosting.co.za>


New submission from LtWorf:

[Note: Long-time users of Cookie.py will remember using
    Cookie.Cookie() to create an Cookie object.


I think it should be "a Cookie".


This is from the documentation of the Cookie module.

----------
assignee: docs at python
components: Documentation
messages: 222610
nosy: docs at python, tiposchi
priority: normal
severity: normal
status: open
title: Wrong grammar in documentation
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul  9 14:51:58 2014
From: report at bugs.python.org (Matthias St.Pierre)
Date: Wed, 09 Jul 2014 12:51:58 +0000
Subject: [New-bugs-announce] [issue21946] 'python -u' yields trailing
	carriage return '\r'	(Python2 for Windows)
Message-ID: <1404910318.13.0.0636532194943.issue21946@psf.upfronthosting.co.za>


New submission from Matthias St.Pierre:

raw_input yields trailing carriage return ('\r') when C:\Python27\python.exe is called using the -u option

How to reproduce the error: save the attached file 'input.py' which contains the following lines

-- begin input.py --

i = raw_input("enter y or n: ")
print(repr(i))
print([ord(c) for c in i])

-- end input.py --

then run the two following commands from a windows command shell
	python input.py
	python -u input.py
and compare the output. (see transcript 1 below)

The same bug affects also the interactive mode: start 'python -u' and enter an arbitrary command. You will get a syntax error at the end of line. (see transcript 2 below)


-- begin transcript 1 of cmd session --

C:\Temp>where python
C:\Python27\python.exe

C:\Temp>python --version
Python 2.7.8

C:\Temp>type input.py

i = raw_input("enter y or n: ")
print(repr(i))
print([ord(c) for c in i])

C:\Temp>python input.py
enter y or n: y
'y'
[121]
-- end transcript 1 of cmd session --


-- begin transcript 2 of cmd session --

C:\Temp>python -u input.py
enter y or n: y
'y\r'
[121, 13]

C:\Temp>python -u
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print "hello world"
  File "<stdin>", line 1
    print "hello world"
                       ^
SyntaxError: invalid syntax
>>>

-- end transcript 2 of cmd session --

----------
components: Interpreter Core, Windows
files: input.py
messages: 222613
nosy: msp
priority: normal
severity: normal
status: open
title: 'python -u' yields trailing carriage return '\r'  (Python2 for Windows)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35913/input.py

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

From report at bugs.python.org  Wed Jul  9 16:28:29 2014
From: report at bugs.python.org (hakril)
Date: Wed, 09 Jul 2014 14:28:29 +0000
Subject: [New-bugs-announce] [issue21947] `Dis` module doesn't know how to
	disassemble generators
Message-ID: <1404916109.31.0.935138955837.issue21947@psf.upfronthosting.co.za>


New submission from hakril:

The `dis` module doesn't know how to disassemble generator object because it has no idea about the `gi_code` attribute.
I made a (very) little patch to change this behavior.

If there is a valid reason to not let the `dis` module disassemble generator, I would be glad to know it.

----------
components: Extension Modules
files: dis_generator.patch
keywords: patch
messages: 222619
nosy: hakril
priority: normal
severity: normal
status: open
title: `Dis` module doesn't know how to disassemble generators
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35914/dis_generator.patch

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

From report at bugs.python.org  Wed Jul  9 17:48:18 2014
From: report at bugs.python.org (Roy)
Date: Wed, 09 Jul 2014 15:48:18 +0000
Subject: [New-bugs-announce] [issue21948] Documentation Typo
Message-ID: <1404920898.4.0.99886911495.issue21948@psf.upfronthosting.co.za>


New submission from Roy:

In the documentation in 15.2 (https://docs.python.org/3/library/hmac.html), under hmac.new(key, msg=None, digestmod=None), it says "Paramter digestmod", which should be "Parameter digestmod"

----------
messages: 222623
nosy: thosehippos
priority: normal
severity: normal
status: open
title: Documentation Typo
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jul  9 21:44:44 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Jul 2014 19:44:44 +0000
Subject: [New-bugs-announce] [issue21949] Document the Py_SIZE() macro.
Message-ID: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The Py_SIZE() macro is not documented.  It should be.  It is very useful along with PyList_New(positive_number) after using PyList_SET_ITEM() to fill in up to the first positive_number elements of a list object in the most optimal manner by avoiding numerous redundant array resizes and error checks along the away.

The Py_SIZE() macro was introduced (in 2.6 I believe) and is specifically intended for use as an lvalue (see http://bugs.python.org/issue1724 to confirm that).  It currently has uses in several places in CPython's core and modules as well as within some third party extension modules and tools such as Cython).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 222633
nosy: docs at python, gregory.p.smith
priority: normal
severity: normal
status: open
title: Document the Py_SIZE() macro.
type: performance
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 10 12:00:36 2014
From: report at bugs.python.org (Alejandro)
Date: Thu, 10 Jul 2014 10:00:36 +0000
Subject: [New-bugs-announce] [issue21950] import sqlite3 not running
Message-ID: <1404986436.3.0.183605850141.issue21950@psf.upfronthosting.co.za>


New submission from Alejandro:

We have compile python 3.4.1 in Suse Linux Enterprise Server 11 SP2

We have compiled it using --prefix as args :

./configure --prefix=/soft/pyt341

make 

make install

We check python has been properly installed:

/soft/pyt341/bin/python3 --version
Python 3.4.1


We try to import sqlite3 lib and we get this error:

/soft/pyt341/bin/python3 -c "import sqlite3"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/soft/pyt341/lib/python3.4/sqlite3/__init__.py", line 23, in <module>
    from sqlite3.dbapi2 import *
  File "/soft/pyt341/lib/python3.4/sqlite3/dbapi2.py", line 26, in <module>
    from _sqlite3 import *
ImportError: No module named '_sqlite3'

----------
components: Library (Lib)
messages: 222656
nosy: alexganwd
priority: normal
severity: normal
status: open
title: import sqlite3 not running
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 10 19:38:46 2014
From: report at bugs.python.org (David Edelsohn)
Date: Thu, 10 Jul 2014 17:38:46 +0000
Subject: [New-bugs-announce] [issue21951] tcl test change crashes AIX
Message-ID: <1405013926.74.0.877232363604.issue21951@psf.upfronthosting.co.za>


New submission from David Edelsohn:

The patch for Issue #21881 causes CPython test_tcl to crash on AIX.

$ ./python -m test -v test_tcl
== CPython 3.5.0a0 (default:d1f89eb9ea1e+, Jul 10 2014, 10:21:22) [GCC 4.8.1]
==   AIX-1-00F84C0C4C00-powerpc-32bit big-endian
==   hash algorithm: siphash24 32bit
==   /home/dje/src/cpython/build/test_python_27984522
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_tcl
patchlevel = 8.4.7
testCall (test.test_tcl.TclTest) ... ok
testCallException (test.test_tcl.TclTest) ... ok
testCallException2 (test.test_tcl.TclTest) ... ok
testEval (test.test_tcl.TclTest) ... ok
testEvalException (test.test_tcl.TclTest) ... ok
testEvalException2 (test.test_tcl.TclTest) ... ok
testEvalFile (test.test_tcl.TclTest) ... ok
testEvalFileException (test.test_tcl.TclTest) ... ok
testGetVar (test.test_tcl.TclTest) ... ok
testGetVarArray (test.test_tcl.TclTest) ... ok
testGetVarArrayException (test.test_tcl.TclTest) ... ok
testGetVarException (test.test_tcl.TclTest) ... ok
testLoadWithUNC (test.test_tcl.TclTest) ... skipped 'Requires Windows'
testPackageRequireException (test.test_tcl.TclTest) ... ok
testSetVar (test.test_tcl.TclTest) ... ok
testSetVarArray (test.test_tcl.TclTest) ... ok
testUnsetVar (test.test_tcl.TclTest) ... ok
testUnsetVarArray (test.test_tcl.TclTest) ... ok
testUnsetVarException (test.test_tcl.TclTest) ... ok
test_eval_null_in_result (test.test_tcl.TclTest) ... ok
test_evalfile_null_in_result (test.test_tcl.TclTest) ... ok
test_exprboolean (test.test_tcl.TclTest) ... ok
test_exprdouble (test.test_tcl.TclTest) ... ok
test_exprlong (test.test_tcl.TclTest) ... ok
test_exprstring (test.test_tcl.TclTest) ... ok
test_getboolean (test.test_tcl.TclTest) ... ok
test_getdouble (test.test_tcl.TclTest) ... ok
test_getint (test.test_tcl.TclTest) ... ok
test_passing_values (test.test_tcl.TclTest) ... ok
test_split (test.test_tcl.TclTest) ... ok
test_splitlist (test.test_tcl.TclTest) ... ok
test_user_command (test.test_tcl.TclTest) ... Assertion failed: __EX, file  Objects/methodobject.c, line 94
Fatal Python error: Aborted

Current thread 0x00000001 (most recent call first):
  File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 426 in check
  File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 458 in test_user_command
  File "/home/dje/src/cpython/Lib/unittest/case.py", line 577 in run
  File "/home/dje/src/cpython/Lib/unittest/case.py", line 625 in __call__
  File "/home/dje/src/cpython/Lib/unittest/suite.py", line 125 in run
  File "/home/dje/src/cpython/Lib/unittest/suite.py", line 87 in __call__
  File "/home/dje/src/cpython/Lib/unittest/suite.py", line 125 in run
  File "/home/dje/src/cpython/Lib/unittest/suite.py", line 87 in __call__
  File "/home/dje/src/cpython/Lib/unittest/runner.py", line 168 in run
  File "/home/dje/src/cpython/Lib/test/support/__init__.py", line 1724 in _run_suite
  File "/home/dje/src/cpython/Lib/test/support/__init__.py", line 1758 in run_unittest
  File "/home/dje/src/cpython/Lib/test/test_tcl.py", line 601 in test_main
  File "/home/dje/src/cpython/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/home/dje/src/cpython/Lib/test/regrtest.py", line 978 in runtest
  File "/home/dje/src/cpython/Lib/test/regrtest.py", line 763 in main
  File "/home/dje/src/cpython/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/home/dje/src/cpython/Lib/test/__main__.py", line 3 in <module>
  File "/home/dje/src/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/dje/src/cpython/Lib/runpy.py", line 170 in _run_module_as_main
IOT/Abort trap (core dumped)

----------
components: Interpreter Core, Tkinter
messages: 222680
nosy: David.Edelsohn, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: tcl test change crashes AIX
type: crash
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 10 21:36:07 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jul 2014 19:36:07 +0000
Subject: [New-bugs-announce] [issue21952] fnmatch.py can appear in
	tracemalloc diffs
Message-ID: <1405020967.14.0.385293193823.issue21952@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

When using some filters and comparing snapshots, fnmatch will appear in the statistic diffs, e.g.:

/home/antoine/34/lib/python3.4/fnmatch.py:70: size=824 B (+64 B), count=2 (+1), average=412 B
eeleak.py:37: size=2512 B (+0 B), count=3 (+0), average=837 B
/home/antoine/llvmpy/llvm/ee.py:109: size=976 B (+0 B), count=2 (+0), average=488 B
/home/antoine/llvmpy/llvm/core.py:401: size=904 B (+0 B), count=2 (+0), average=452 B
/home/antoine/34/lib/python3.4/sre_compile.py:488: size=856 B (+0 B), count=1 (+0), average=856 B


Perhaps it would be nice to manually cache the compiled re pattern, instead of going through fnmatch's lru_cache thing which seems to make reports less robust.

----------
components: Library (Lib)
messages: 222692
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: fnmatch.py can appear in tracemalloc diffs
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 11 00:02:05 2014
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jul 2014 22:02:05 +0000
Subject: [New-bugs-announce] [issue21953] pythonrun.c does not check std
	streams the same as	fileio.c
Message-ID: <1405029725.94.0.581966464433.issue21953@psf.upfronthosting.co.za>


New submission from Steve Dower:

In pythonrun.c, the is_valid_fd() function checks whether fileno(std*) are valid before attempting to create IO objects for them. However, the class created also checks using fstat().

In pythonw.exe built with VS 2013 (or 14, maybe 2012), the fstat() check fails while the earlier one succeeds. This prevents pythonw from starting.

The attached patch adds the fstat() check to pythonrun.c so that if the streams are not usable they will simply not be used. I believe this was the original intent, but at some point the invalid streams gained valid file numbers.

(I have no strong opinion about applying this to 3.4, except that it will help out people who rebuild/embed that version of Python with a newer compiler. Thoughts?)

----------
components: IO, Windows
files: pythonrun_fstat.diff
keywords: patch
messages: 222706
nosy: benjamin.peterson, pitrou, steve.dower, stutzbach, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pythonrun.c does not check std streams the same as fileio.c
versions: Python 3.5
Added file: http://bugs.python.org/file35921/pythonrun_fstat.diff

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

From report at bugs.python.org  Fri Jul 11 04:57:23 2014
From: report at bugs.python.org (Dev Player)
Date: Fri, 11 Jul 2014 02:57:23 +0000
Subject: [New-bugs-announce] [issue21954] str(b'text') returns "b'text'" in
	interpreter
Message-ID: <1405047443.55.0.837087456572.issue21954@psf.upfronthosting.co.za>


New submission from Dev Player:

str(b'text') returns double quoted item with b prefix within the str() object as so: "b'text'" in python interpreter. It seems the "b" shouldn't be within the outter quotes or apart of the str() instance data.

Is this a bug or new syntax? I personally haven't see any documentation that this is the correct behavior. Nor did I find any previously register issue tickets.

>>>bchars_list = [b'o', b'n', b'e']
>>>bchars_list
[b'o', b'n', b'e']
>>>[str(x) for x in bchars_list]
["b'o'", "b'n'", "b'e'"]

----------
components: Interpreter Core
files: str bug.bmp
messages: 222718
nosy: devplayer
priority: normal
severity: normal
status: open
title: str(b'text') returns "b'text'" in interpreter
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file35923/str bug.bmp

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

From report at bugs.python.org  Fri Jul 11 11:10:27 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jul 2014 09:10:27 +0000
Subject: [New-bugs-announce] [issue21955] ceval.c: implement fast path for
	integers with a single	digit
Message-ID: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python 2 has fast path in ceval.c for operations (a+b, a-b, etc.) on small integers ("int" type) if the operation does not overflow.

We loose these fast-path in Python 3 when we dropped the int type in favor of the long type.

Antoine Pitrou proposed a fast-path, but only for int singletons (integers in the range [-5; 255]): issue #10044. His patch was rejected because it introduces undefined behaviour.

I propose to reimplemenet Python 2 optimization for long with a single digit, which are the most common numbers.

Pseudo-code for BINARY_ADD:
---
if (PyLong_CheckExact(x) && Py_ABS(Py_SIZE(x)) == 1
    && PyLong_CheckExact(y) && Py_ABS(Py_SIZE(y)) == 1)
{
   stwodigits a = ..., b = ...;
   stwodigits c;
   if (... a+b will not overflow ...) { 
      c = a + b;
      return PyLong_FromLongLong(c);
   }
}
/* fall back to PyNumber_Add() */
---

The code can be copied from longobject.c, there are already fast-path for single digit numbers. See for example long_mul():
---
    /* fast path for single-digit multiplication */
    if (Py_ABS(Py_SIZE(a)) <= 1 && Py_ABS(Py_SIZE(b)) <= 1) {
        ....
    }
---

As any other optimization, it should be proved to be faster with benchmarks.

----------
messages: 222731
nosy: haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: ceval.c: implement fast path for integers with a single digit
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Fri Jul 11 15:07:11 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Fri, 11 Jul 2014 13:07:11 +0000
Subject: [New-bugs-announce] [issue21956] Deleted document should not appear
	in 3.4 docs
Message-ID: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

There was an old document in the "howto" folder whose advice was in many cases flat-out wrong, so Raymond Hettinger performed a wonderful public service by deleting it back in 2011:

http://hg.python.org/cpython/rev/80ff78425419

Unfortunately it looks like the process for publishing Python documentation only adds documents, but never deletes them, so a copy of the documentation is still available under the "3.4" document tree:

https://docs.python.org/3.4/howto/doanddont.html

It should be deleted as soon as possible. Because it is presumed that only the most accurate and up-to-date documentation lives under the URL "3.4", people are reading and debating this document's bad advice as though it is official guidance as to how to use the language. (The only hint that something is wrong, alas, is the tiny detail that the top-left of the page says ?Python v3.3a0 documentation?).

The advice is currently being debated on Twitter and people are sad that they are supposed to stop using ?from foo import bar? in Python.

----------
messages: 222741
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: Deleted document should not appear in 3.4 docs

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

From report at bugs.python.org  Fri Jul 11 16:29:40 2014
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Fri, 11 Jul 2014 14:29:40 +0000
Subject: [New-bugs-announce] [issue21957] ASCII Formfeed (FF) & ASCII
	Vertical Tab (VT) Have	Hexadecimal Representation
Message-ID: <1405088980.95.0.801380317459.issue21957@psf.upfronthosting.co.za>


New submission from Stephen Paul Chappell:

In the string module, the definition of whitespace is ' \t\n\r\v\f'. However, the representation of string.whitespace is ' \t\n\r\x0b\x0c'. Would it be terribly inconvenient to change the representation of '\x0b\x0c' to '\v\f'? The documentation at https://docs.python.org/3.4/reference/lexical_analysis.html#string-and-bytes-literals lists recognized escape sequences, but string represetations seem to diverge slightly from what is recognized. The same "problem" exists with the representation of bytes.

----------
messages: 222749
nosy: Zero
priority: normal
severity: normal
status: open
title: ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal Representation
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 11 19:20:04 2014
From: report at bugs.python.org (Zachary Turner)
Date: Fri, 11 Jul 2014 17:20:04 +0000
Subject: [New-bugs-announce] [issue21958] Allow python 2.7 to compile with
	Visual Studio 2013
Message-ID: <1405099204.33.0.886354272035.issue21958@psf.upfronthosting.co.za>


New submission from Zachary Turner:

VS2013 and beyond implement C99 math functions.  Of interest to Python is the function round().  Python conditionally provides its own implementation of round() based on whether or not HAVE_ROUND is defined, but in no case is HAVE_ROUND ever defined.  This leads to a huge spew of warnings when compiling with VS2013, and presumably it also leads to undefined behavior.

The attached patch conditionally defines HAVE_ROUND based on _MSC_VER, and additionally provides a VS2013 port in the form of a set of native VS2013 solution and project files.

This patch is based against tip of 2.7 release branch.  The same fix may or may not still be needed in 3.x

----------
components: Windows
files: python.patch
keywords: patch
messages: 222766
nosy: Zachary.Turner, steve.dower
priority: normal
severity: normal
status: open
title: Allow python 2.7 to compile with Visual Studio 2013
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file35925/python.patch

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

From report at bugs.python.org  Fri Jul 11 20:25:26 2014
From: report at bugs.python.org (Anselm Kruis)
Date: Fri, 11 Jul 2014 18:25:26 +0000
Subject: [New-bugs-announce] [issue21959] msi product code for 2.7.5150 not
	in Tools/msi/uuids.py
Message-ID: <1405103126.17.0.536868582268.issue21959@psf.upfronthosting.co.za>


New submission from Anselm Kruis:

The file Tools/msi/uuids.py contains the product codes for all recently released Python 2.x versions except 2.7.8. Without this code it is not possible to recreate the MSI installer using Tools\msi\msi.py. 

The product code of https://www.python.org/ftp/python/2.7.8/python-2.7.8.msi is '{61121B12-88BD-4261-A6EE-AB32610A56DD}'.

By the way. We had exactly the same issue with 2.7.5: #18023

----------
components: Windows
messages: 222774
nosy: anselm.kruis, loewis, zach.ware
priority: normal
severity: normal
status: open
title: msi product code for 2.7.5150 not in Tools/msi/uuids.py
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 11 21:10:32 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Jul 2014 19:10:32 +0000
Subject: [New-bugs-announce] [issue21960] Better path handling in Idle find
	in files
Message-ID: <1405105832.92.0.37541050814.issue21960@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

I propose two interrelated changes for path handling in Idle's Find in Files feature (Alt-F3).

1. If I hit Alt-F3 in an editor window, the 'In files:' entry box displays a full path, such as "C:\Programs\Python34\Lib\idlelib\*.py". If I do the same in the shell, the display is "*.py" with the  prefix, the starting directory containing pythonx.exe, suppressed. (In a repository build, the box is blank, perhaps because the executable is not in the directory containing Assuming 2, I would prefer the full path (in a wider dialog box).

1a. In a repository build, the box is blank, perhaps because the executable is not in the directory containing Lib. Starting with the patch to that directory, rather than pcbuild (on Windows) would be more useful than nothing.

2. FiF uses a generic Output Window. It first displays something like
  Searching 'Func' in lib/idlelib/idle_test/*.py ...
where the path is copied from the 'In file:' path. This common prefix is displayed with all hits
  lib/idlelib/idle_test\htest.py: 15: or a wrapper function also work...
  lib/idlelib/idle_test\htest.py: 40:     'msg': "Test editor ... 
  lib/idlelib/idle_test\mock_tk.py: 18: class Mbox_func:
If one starts from the editor window, the common prefix is even longer and more noisy and obnoxious. (It is also slightly worse in my repository setup.)
  C:\Programs\Python34\lib/idlelib/idle_test\htest.py: 15: or a wrapper function also work...
  C:\Programs\Python34\lib/idlelib/idle_test\htest.py: 40:     'msg': "Test editor ... 
  C:\Programs\Python34\lib/idlelib/idle_test\mock_tk.py: 18: class Mbox_func:
which is why I do not especially want change 1 without change 2: delete the common prefix from the listing.
  htest.py: 15: or a wrapper function also work. The name of wrapper functions, like
  htest.py: 40:     'msg': "Test editor functions of interest"
  mock_tk.py: 18: class Mbox_func:
The path prefix would have to be an attribute of the window, which should perhaps be an FiF subclass of OutputWindow anyway. The "Go to file/line" function would append the prefix.

----------
messages: 222779
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: Better path handling in Idle find in files
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 11 21:56:08 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Jul 2014 19:56:08 +0000
Subject: [New-bugs-announce] [issue21961] Add What's New for Idle.
Message-ID: <1405108568.05.0.859499936838.issue21961@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

For the stdlib in general, What's New in x.y.0 is sufficient because there is not supposed to be anything new in bugfix releases except for bugfixes.  2.7 has a security enhancement exemption, and a corresponding section in the 2.7 What's New for security enhancements in maintenance releases.

A similar section for Idle could be added to What's New for each Python version.  But thinking about it, I would rather have a separate document listed in the Idle help menu and advertised in the Idle sign-on message. In particular, I would replace the useless "Type "copyright", "credits" or "license()" for more information." with "See HELP/WHAT'S NEW for information about changes in each release."

----------
assignee: terry.reedy
components: IDLE
messages: 222785
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add What's New for Idle.
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 11 22:23:50 2014
From: report at bugs.python.org (Alexandre JABORSKA)
Date: Fri, 11 Jul 2014 20:23:50 +0000
Subject: [New-bugs-announce] [issue21962] No timeout for
	asyncio.Event.wait() or	asyncio.Condition.wait() ?
Message-ID: <1405110230.82.0.890171299066.issue21962@psf.upfronthosting.co.za>


New submission from Alexandre JABORSKA:

Hi,

  Nor asyncio.Event.wait() neither asyncio.Condition.wait() (or .wait_for()) has a timeout parameter, while threading.Event.wait() has one.

  A timeout can be specified for the whole task using asyncio.wait_for() but it's tricky.

  I guess asyncio implementation could allow a timeout parameter (but I've not looked at the code yet). Maybe is this a feature ?

----------
components: asyncio
messages: 222791
nosy: ajaborsk, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: No timeout for asyncio.Event.wait() or asyncio.Condition.wait() ?
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Jul 11 23:06:05 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 11 Jul 2014 21:06:05 +0000
Subject: [New-bugs-announce] [issue21963] 2.7.8 backport of Issue1856 (avoid
	daemon thread	problems at shutdown) breaks ceph
Message-ID: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za>


New submission from Ned Deily:

doko in msg222768 of Issue1856:

http://tracker.ceph.com/issues/8797 reports that the backport to 2.7 causes a regression in ceph.

----------
messages: 222795
nosy: benjamin.peterson, doko, ned.deily
priority: release blocker
severity: normal
stage: needs patch
status: open
title: 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul 12 01:06:27 2014
From: report at bugs.python.org (hakril)
Date: Fri, 11 Jul 2014 23:06:27 +0000
Subject: [New-bugs-announce] [issue21964] inconsistency in list-generator
	comprehension with	yield(-from)
Message-ID: <1405119987.38.0.925003339613.issue21964@psf.upfronthosting.co.za>


New submission from hakril:

Will playing with generators and `yield from` I found some inconsistency.

list comprehension with yield(-from) would return a generator.
generator comprehension would yield some None in the middle of the expected values.

Examples:
    l = ["abc", range(3)]
    g1 = [(yield from i) for i in l]
    print(g)
    <generator object <listcomp> at 0x7f5ebd58b690>
    print(list(g))
    ['a', 'b', 'c', 0, 1, 2]  # this result is super cool !

    g2 = ((yield from i) for i in l)
    print(g2)
    <generator object <genexpr> at 0x7f5ebd58b6e0>
    print(list(g2))
    ['a', 'b', 'c', None, 0, 1, 2, None]


For `g1`: it returns a generator because the listcomp contains a `yield from`.

For `g2` it append None because it yield the return value of `yield from i`.
It could be rewritten as:
    def comp(x):
        for i in x:
            yield (yield from i)

----------
components: Interpreter Core
messages: 222811
nosy: hakril
priority: normal
severity: normal
status: open
title: inconsistency in list-generator comprehension with yield(-from)
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Jul 12 11:08:54 2014
From: report at bugs.python.org (Geert Jansen)
Date: Sat, 12 Jul 2014 09:08:54 +0000
Subject: [New-bugs-announce] [issue21965] Add support for Memory BIO to _ssl
Message-ID: <1405156134.57.0.513965198344.issue21965@psf.upfronthosting.co.za>


New submission from Geert Jansen:

The attached patch adds a _MemoryBIO type to _ssl, and a _wrap_bio() method to _SSLContext. The patch also includes tests.

For now I kept _wrap_bio() and _MemoryBIO semi-private. The reason is that it returns an _SSLSocket instead of an SSLSocket and this type has not been exposed before as part of the public API. Changing the result of _wrap_bio to return an SSLSocket is not appropriate IMHO because it should not inherit from socket.socket which would waste a file descriptor and None of the IO methods are relevant.

The patch works for me and gives no errors with --with-pydebug. I've also used it in an experimental branch of Gruvi and all the tests pass there too.

----------
files: ssl-memory-bio.patch
keywords: patch
messages: 222833
nosy: geertj
priority: normal
severity: normal
status: open
title: Add support for Memory BIO to _ssl
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35928/ssl-memory-bio.patch

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

From report at bugs.python.org  Sat Jul 12 18:05:23 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jul 2014 16:05:23 +0000
Subject: [New-bugs-announce] [issue21966] InteractiveConsole does not
	support -q option
Message-ID: <1405181123.73.0.894498211412.issue21966@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

When invoked with -q option, python3 prints no banner:
$ python3 -q
>>>

However, code.InteractiveConsole does not implement this feature:
$ python3 -mcode -q
Python 3.4.1 (default, May 19 2014, 13:10:29)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>

----------
keywords: easy
messages: 222850
nosy: belopolsky
priority: normal
severity: normal
status: open
title: InteractiveConsole does not support -q option
type: enhancement

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

From report at bugs.python.org  Sat Jul 12 18:31:09 2014
From: report at bugs.python.org (Anselm Kruis)
Date: Sat, 12 Jul 2014 16:31:09 +0000
Subject: [New-bugs-announce] [issue21967] Interpreter crash upon accessing
	frame.f_restricted of a	frame from a dead thread
Message-ID: <1405182669.73.0.676876650483.issue21967@psf.upfronthosting.co.za>


New submission from Anselm Kruis:

If you store a reference to a frame from a dead thread and then access 
frame.f_restricted python eventually crashed.

I didn't investigate this bug in depth. Here is my preliminary explanation.

The access of frame.f_restricted causes a call of PyFrame_IsRestricted(f). 

PyFrame_IsRestricted is a macro and expands to 
((f)->f_builtins != (f)->f_tstate->interp->builtins) 

Now, if the thread that created f is already dead, the f_tstate points to an invalid structure. Depending on the content of the memory the access of f_tstate->interp causes an access violation. I use a Win32 debug build to reliable reproduce the issue.

----------
components: Interpreter Core
files: crash_on_f_restricted.py
messages: 222852
nosy: anselm.kruis
priority: normal
severity: normal
status: open
title: Interpreter crash upon accessing frame.f_restricted of a frame from a dead thread
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file35931/crash_on_f_restricted.py

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

From report at bugs.python.org  Sat Jul 12 22:26:53 2014
From: report at bugs.python.org (Apple Grew)
Date: Sat, 12 Jul 2014 20:26:53 +0000
Subject: [New-bugs-announce] [issue21968] 'abort' object is not callable
Message-ID: <1405196813.11.0.369629706677.issue21968@psf.upfronthosting.co.za>


New submission from Apple Grew:

I am sometimes getting the following error from imaplib.

Traceback (most recent call last):
  File "client.py", line 105, in get_new_mail_uids
    result, data = retryableCall(lambda : mail.uid('search', None, "UNSEEN"), retries, delay) # search and return uids instead
  File "client.py", line 25, in retryableCall
    return f()
  File "client.py", line 105, in 
    result, data = retryableCall(lambda : mail.uid('search', None, "UNSEEN"), retries, delay) # search and return uids instead
  File "/usr/lib/python2.6/imaplib.py", line 753, in uid
    typ, dat = self._simple_command(name, command, *args)
  File "/usr/lib/python2.6/imaplib.py", line 1060, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python2.6/imaplib.py", line 893, in _command_complete
    self._check_bye()
  File "/usr/lib/python2.6/imaplib.py", line 808, in _check_bye
    raise self.abort(bye[-1])
TypeError: 'abort' object is not callable

----------
components: Library (Lib)
messages: 222879
nosy: Apple Grew
priority: normal
severity: normal
status: open
title: 'abort' object is not callable
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 13 03:20:03 2014
From: report at bugs.python.org (Antony Lee)
Date: Sun, 13 Jul 2014 01:20:03 +0000
Subject: [New-bugs-announce] [issue21969] WindowsPath constructor does not
	check for invalid	characters
Message-ID: <1405214403.71.0.545456092847.issue21969@psf.upfronthosting.co.za>


New submission from Antony Lee:

PureWindowsPath("foo*") returns a path object, even though it is an invalid one (e.g., open("foo*") on Windows throws an OSError for "invalid argument" rather than a FileNotFoundError).  Given the amount of checking that is done in (e.g.) with_name and with_suffix, it seems reasonable to throw an exception in this case too.

----------
components: Library (Lib)
messages: 222899
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: WindowsPath constructor does not check for invalid characters
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jul 13 03:49:21 2014
From: report at bugs.python.org (Martin Panter)
Date: Sun, 13 Jul 2014 01:49:21 +0000
Subject: [New-bugs-announce] [issue21970] Broken code for handling
	file://host in	urllib.request.FileHandler.file_open
Message-ID: <1405216161.05.0.3363234179.issue21970@psf.upfronthosting.co.za>


New submission from Martin Panter:

This isn?t a particularly important problem for me but when reading the code I noticed some bit rot in this function, where a host name in a ?file:? URL would be handled differently than intended.

* The url[:2] == '//' check is probably wrong because it is comparing the URL?s path component (selector), not the prefix for a host name. Compare urlopen("file://host//") and urlopen("file://host/") error messages.

* The req.host is self.get_names() should probably use ?in?, not ?is?. The code author presumably expected urlopen("file://127.0.0.1//dev/null") to work.

* Also it seems odd that urlopen("file://remote/missing") immediately reports ?No such file?, while urlopen("file://remote/") blocks for a host name lookup and then reports ?not on local host?.

----------
components: Library (Lib)
messages: 222901
nosy: vadmium
priority: normal
severity: normal
status: open
title: Broken code for handling file://host in urllib.request.FileHandler.file_open
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul 13 04:19:20 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jul 2014 02:19:20 +0000
Subject: [New-bugs-announce] [issue21971] Index and update turtledemo doc.
Message-ID: <1405217960.27.0.66457016468.issue21971@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The doc section for the turtledemo package do not appear in either the module index or the general index. It should appear in both.
https://docs.python.org/2.7/library/turtle.html#demo-scripts
https://docs.python.org/3.4/library/turtle.html#demo-scripts

This comment about the two-canvases demo, "Therefore it only can be run standalone." was previously obsolete is that it could be run from the demo viewer, but the text did not load. After the fix for #21882, the text load and it works find in the viewer. It should be added to the table and the count adjusted.

----------
messages: 222903
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Index and update turtledemo doc.
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jul 13 05:49:36 2014
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Ren=C3=A9_Rideau?=)
Date: Sun, 13 Jul 2014 03:49:36 +0000
Subject: [New-bugs-announce] [issue21972] Bugs in the lexer and parser
	documentation
Message-ID: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>


New submission from Fran?ois-Ren? Rideau:

The lexer documentation says that the u prefix works on strings since 3.3, but doesn't explain what or how, which is all the more problematic since it explicitly mentions difference from the behavior documented in Python 2.

It also doesn't specify the ELLIPSIS token or the <> future token mentioned in the grammar (that should probably be removed, for PEP 401 is a joke ? unless that's intentional, in which case a smiley might be useful).

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

----------
assignee: docs at python
components: Documentation
messages: 222906
nosy: Fran?ois-Ren?.Rideau, docs at python
priority: normal
severity: normal
status: open
title: Bugs in the lexer and parser documentation
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Jul 13 14:01:45 2014
From: report at bugs.python.org (Thomas Kember)
Date: Sun, 13 Jul 2014 12:01:45 +0000
Subject: [New-bugs-announce] [issue21973] Can't use Idle
Message-ID: <1405252905.33.0.296703763462.issue21973@psf.upfronthosting.co.za>


New submission from Thomas Kember:

I am a retired programmer. I still like to write small programs for my own interest. Python is ideal for this. I prefer to use Idle rather than the command line. For some time now when I click on the Idle shortcut on the home screen, the command line screen flashes and then nothing. I am not able to do anything on Idle. I had been using Python33. So I upgraded to Python34. It was the same thing. I looked at the batch file, idle.bat. This is what it contains.

@echo off
rem Start IDLE using the appropriate Python interpreter
set CURRDIR=%~dp0
start "IDLE" "%CURRDIR%..\..\pythonw.exe" "%CURRDIR%idle.pyw" %1 %2 %3 %4 %5 %6 %7 %8 %9

I don't understand what %~dp0 means. I can't think what changes I have made to the operating system, it is Windows 7, that could cause this problem.

As I say Python is great for what I do. But I am stuck with the command line if I cannot fix this.

Tomk

----------
messages: 222916
nosy: Tomk
priority: normal
severity: normal
status: open
title: Can't use Idle
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul 13 15:46:45 2014
From: report at bugs.python.org (Quan Nguyen)
Date: Sun, 13 Jul 2014 13:46:45 +0000
Subject: [New-bugs-announce] [issue21974] Typo in "Set" in PEP 289
Message-ID: <1405259205.91.0.354050943878.issue21974@psf.upfronthosting.co.za>


New submission from Quan Nguyen:

This statement in the Rationale section:

"s = Set(word  for line in page  for word in line.split())"

"Set" should be "set" (lowercase 's')

----------
assignee: docs at python
components: Documentation
messages: 222924
nosy: Quan.Nguyen, docs at python
priority: normal
severity: normal
status: open
title: Typo in "Set" in PEP 289

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

From report at bugs.python.org  Mon Jul 14 02:01:29 2014
From: report at bugs.python.org (Elizabeth Myers)
Date: Mon, 14 Jul 2014 00:01:29 +0000
Subject: [New-bugs-announce] [issue21975] Using pickled/unpickled
	sqlite3.Row results in segfault	rather than exception
Message-ID: <1405296089.18.0.134297351302.issue21975@psf.upfronthosting.co.za>


New submission from Elizabeth Myers:

Pickling, unpickling, then using an sqlite3.Row object results in a segfault on at least Python 3.3.5, 3.4.0, and 3.4.1. I have attached a test case and a backtrace below.

I know you're not supposed to pickle sqlite3.Row objects, as the given test case below results in an exception to the effect that sqlite3.Row objects cannot be pickled in Python 2.7. I don't think a segfault is the desired behaviour, however...

----------
components: Library (Lib)
files: testcase.py
messages: 222982
nosy: Elizacat
priority: normal
severity: normal
status: open
title: Using pickled/unpickled sqlite3.Row results in segfault rather than exception
type: crash
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file35947/testcase.py

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

From report at bugs.python.org  Mon Jul 14 08:15:58 2014
From: report at bugs.python.org (William Orr)
Date: Mon, 14 Jul 2014 06:15:58 +0000
Subject: [New-bugs-announce] [issue21976] Fix test_ssl.py to handle LibreSSL
	versioning	appropriately
Message-ID: <1405318558.48.0.274142597942.issue21976@psf.upfronthosting.co.za>


New submission from William Orr:

Currently, test_ssl.py requires the version information to match the OpenSSL format exactly, and to be less than 2.0. LibreSSL, a drop-in replacement for OpenSSL, has started its version numbers at 2.0.0, and reports it slightly differently. This patch addresses that.

Tested on Exherbo Linux amd64 with LibreSSL portable 2.0.1.

----------
components: Tests
files: libressl-tests.diff
keywords: patch
messages: 222996
nosy: worr
priority: normal
severity: normal
status: open
title: Fix test_ssl.py to handle LibreSSL versioning appropriately
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35949/libressl-tests.diff

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

From report at bugs.python.org  Mon Jul 14 09:23:21 2014
From: report at bugs.python.org (py.user)
Date: Mon, 14 Jul 2014 07:23:21 +0000
Subject: [New-bugs-announce] [issue21977] In the re's token example OP and
	SKIP regexes can be	improved
Message-ID: <1405322601.6.0.312118432344.issue21977@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/library/re.html#writing-a-tokenizer

There are redundant escapes in the regex:

('OP',      r'[+*\/\-]'),    # Arithmetic operators

Sequence -+*/ is sufficient.

It makes the loop to do all steps on every 4 spaces:

('SKIP',    r'[ \t]'),       # Skip over spaces and tabs

Sequence [ \t]+ is faster.


Applied patch.

----------
assignee: docs at python
components: Documentation, Regular Expressions
files: re_ex_tok.diff
keywords: patch
messages: 223000
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In the re's token example OP and SKIP regexes can be improved
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35951/re_ex_tok.diff

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

From report at bugs.python.org  Mon Jul 14 11:15:03 2014
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 14 Jul 2014 09:15:03 +0000
Subject: [New-bugs-announce] [issue21978] Support index access on
	OrderedDict views (e.g.	o.keys()[7])
Message-ID: <1405329303.68.0.861089422528.issue21978@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Implement `__getitem__` on `OrdredDict.keys`, `OrdredDict.values` and `OrdredDict.items`, so the following code snippet wouldn't error:

    >>> from collections import OrderedDict
    >>> o = OrderedDict(((1, 2), (3, 4), (5, 6)))
    >>> o
    OrderedDict([(1, 2), (3, 4), (5, 6)])
    >>> o.keys()
    KeysView(OrderedDict([(1, 2), (3, 4), (5, 6)]))
    >>> o.keys()[0]
    Traceback (most recent call last):
      File "<string>", line 1, in <fragment>
    builtins.TypeError: 'KeysView' object does not support indexing
    >>> o.values()[0]
    Traceback (most recent call last):
      File "<string>", line 1, in <fragment>
    builtins.TypeError: 'ValuesView' object does not support indexing
    >>> o.items()[0]
    Traceback (most recent call last):
      File "<string>", line 1, in <fragment>
    builtins.TypeError: 'ItemsView' object does not support indexing

----------
components: Library (Lib)
messages: 223006
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Support index access on OrderedDict views (e.g. o.keys()[7])
versions: Python 3.5

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

From report at bugs.python.org  Mon Jul 14 12:33:45 2014
From: report at bugs.python.org (Mika Eloranta)
Date: Mon, 14 Jul 2014 10:33:45 +0000
Subject: [New-bugs-announce] [issue21979] SyntaxError not raised on "0xaor 1"
Message-ID: <1405334025.99.0.201355184316.issue21979@psf.upfronthosting.co.za>


New submission from Mika Eloranta:

The following are expected to raise SyntaxError, but they don't:

>>> 0xfor python is weird in ways
15
>>> [0xaor 1, 0xbor 1, 0xcor 1, 0xdor 1, 0xeor 1, 0xfor 1]
[10, 11, 12, 13, 14, 15]

Verified on v2.7.1 and v3.3.2. Probably affects all versions.

----------
components: Interpreter Core
messages: 223009
nosy: mel
priority: normal
severity: normal
status: open
title: SyntaxError not raised on "0xaor 1"
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Jul 14 13:44:45 2014
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 14 Jul 2014 11:44:45 +0000
Subject: [New-bugs-announce] [issue21980] Implement
	`logging.LogRecord.__repr__`
Message-ID: <1405338285.22.0.129241748219.issue21980@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
components: Library (Lib)
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement `logging.LogRecord.__repr__`
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jul 14 13:52:56 2014
From: report at bugs.python.org (Thomas Kember)
Date: Mon, 14 Jul 2014 11:52:56 +0000
Subject: [New-bugs-announce] [issue21981] Idle problem
Message-ID: <1405338608.49183.YahooMailNeo@web87703.mail.ir2.yahoo.com>


New submission from Thomas Kember:

Hello Terry,

Thank you for your explanation of the bug in Idle. I know Idle has limitations, but it is quite adequate for the programming I want to do. I agree that when this error occurs there should only be a warning, so the user can decide what he wants to do about it. There is however one fault in Idle that would be good if it were fixed. That is, it does not show line numbers. Since errors all indicate the line number the error occured, having the line numbers on the listing would be very useful.

One other thing. Now the problem is solved but it is still showing status 'open' on the problem site, how do I change the status?

Regards,

Thomas

----------
messages: 223016
nosy: Tomk
priority: normal
severity: normal
status: open
title: Idle problem

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

From report at bugs.python.org  Mon Jul 14 16:43:31 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Mon, 14 Jul 2014 14:43:31 +0000
Subject: [New-bugs-announce] [issue21982] Idle: Regression introduced in
	configDialog by rev 91509
Message-ID: <1405349011.77.0.800791635134.issue21982@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

The concerned part : http://hg.python.org/cpython/rev/b836a0cd68f7#l4.15

"NameError: name 'keySet' is not defined."

----------
messages: 223031
nosy: sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: Idle: Regression introduced in configDialog by rev 91509
versions: Python 3.4

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

From report at bugs.python.org  Mon Jul 14 23:53:26 2014
From: report at bugs.python.org (Anthony LaTorre)
Date: Mon, 14 Jul 2014 21:53:26 +0000
Subject: [New-bugs-announce] [issue21983] segfault in ctypes.cast
Message-ID: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za>


New submission from Anthony LaTorre:

I get a segfault when trying to cast a string to a structure. 
>>> import ctypes
>>> class Struct(ctypes.Structure):
...     _fields_ = [('a', ctypes.c_uint32)]
... 
>>> s = '0'*100
>>> ctypes.cast(s,Struct)
Segmentation fault

The docs (https://docs.python.org/2/library/ctypes.html#ctypes.cast) say that `obj` "must be an object that can be interpreted as a pointer", so I assume this should return the same exception you get when trying to cast a list:

>>> ctypes.cast(range(10),Struct)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.4/ctypes/__init__.py", line 488, in cast
    return _cast(obj, obj, typ)
ctypes.ArgumentError: argument 1: <class 'TypeError'>: wrong type

----------
messages: 223062
nosy: Anthony.LaTorre
priority: normal
severity: normal
status: open
title: segfault in ctypes.cast
type: crash
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Jul 15 00:01:00 2014
From: report at bugs.python.org (James Paget)
Date: Mon, 14 Jul 2014 22:01:00 +0000
Subject: [New-bugs-announce] [issue21984] list(itertools.repeat(1)) causes
	the system to hang
Message-ID: <1405375260.64.0.424779344541.issue21984@psf.upfronthosting.co.za>


New submission from James Paget:

In Python 3.4, type:

>>> import itertools
>>> list(itertools.repeat(1))

The system will hang, and a cold reboot is necessary (at least on Windows).  I expected some sort of "infinite list" exception to be thrown.

----------
components: Extension Modules
messages: 223063
nosy: James.Paget
priority: normal
severity: normal
status: open
title: list(itertools.repeat(1)) causes the system to hang
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Jul 16 01:04:27 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jul 2014 23:04:27 +0000
Subject: [New-bugs-announce] [issue21985] test_asyncio prints some junk
Message-ID: <1405465467.27.0.383120820673.issue21985@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It could be nice if it could stay silent (at least in non-verbose mode).

[ 24/390] test_asyncio
Task was destroyed but it is pending!
task: <Task pending coro=<CoroutineGatherTests.wrap_futures.<locals>.coro() running at /home/antoine/cpython/default/Lib/test/test_asyncio/test_tasks.py:1862> cb=[gather.<locals>._done_callback(2)() at /home/antoine/cpython/default/Lib/asyncio/tasks.py:577] wait_for=<Future finished result=3>>
Task was destroyed but it is pending!
task: <Task pending coro=<CoroutineGatherTests.wrap_futures.<locals>.coro() running at /home/antoine/cpython/default/Lib/test/test_asyncio/test_tasks.py:1862> cb=[gather.<locals>._done_callback(3)() at /home/antoine/cpython/default/Lib/asyncio/tasks.py:577] wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task pending coro=<CoroutineGatherTests.wrap_futures.<locals>.coro() running at /home/antoine/cpython/default/Lib/test/test_asyncio/test_tasks.py:1862> cb=[gather.<locals>._done_callback(4)() at /home/antoine/cpython/default/Lib/asyncio/tasks.py:577] wait_for=<Future finished exception=RuntimeError()>>
Task was destroyed but it is pending!
task: <Task pending coro=<sleep() done, defined at /home/antoine/cpython/default/Lib/asyncio/tasks.py:489> wait_for=<Future pending cb=[Task._wakeup()]>>
Read pipe 9 connected: (<_UnixReadPipeTransport fd=9 polling>, <asyncio.streams.StreamReaderProtocol object at 0x7f2c0b358dc0>)
execute program '/home/antoine/cpython/default/python'
process '/home/antoine/cpython/default/python' created: pid 4233
execute program '/home/antoine/cpython/default/python': <_UnixSubprocessTransport pid=4233>
poll took 36.605 ms: 1 events
poll took 6.615 ms: 0 events
process 4233 exited with returncode 0
<_UnixSubprocessTransport pid=4233> exited with return code 0
poll took 0.032 ms: 1 events
<_UnixReadPipeTransport fd=9 polling> was closed by peer

----------
components: Tests
messages: 223156
nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio prints some junk
type: behavior

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

From report at bugs.python.org  Wed Jul 16 02:13:43 2014
From: report at bugs.python.org (ppperry)
Date: Wed, 16 Jul 2014 00:13:43 +0000
Subject: [New-bugs-announce] [issue21986] Pickleability of code objects is
	inconsistent
Message-ID: <1405469623.84.0.281722062447.issue21986@psf.upfronthosting.co.za>


New submission from ppperry:

In IDLE:

>>> code = compile("dummy_code", "<test>", "exec")
>>> pickle.dumps(code)
"cidlelib.rpc\nunpickle_code\np0\n(S'c\\x00\\x00\\x00\\x00\\x00\\x00 \\x00\\x00\\x01\\x00\\x00\\x00@\\x00\\x00\\x00s\\x08\\x00\\x00\\x00e\\x00\\x00\\x01d\\x00\\x00S(\\x01\\x00\\x00\\x00N(\\x01\\x00\\x00\\x00t\\n\\x00\\x00\\x00dummy_code(\\x00\\x00\\x00\\x00(\\x00\\x00\\x00\\x00(\\x00\\x00\\x00\\x00s\\x06\\x00\\x00\\x00<test>t\\x08\\x00\\x00\\x00<module>\\x01\\x00\\x00\\x00s\\x00\\x00\\x00\\x00'\np1\ntp2\nRp3\n."


Outside of IDLE:
>>> code = compile("dummy_code", "<test>", "exec")
>>> pickle.dumps(code)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\pickle.py", line 1374, in dumps
    Pickler(file, protocol).dump(obj)
  File "C:\Python27\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "C:\Python27\lib\pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "C:\Python27\lib\copy_reg.py", line 70, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle code objects



Also, the error probably should be a pickle.PicklingError, not a TypeError.

----------
components: IDLE
messages: 223161
nosy: ppperry
priority: normal
severity: normal
status: open
title: Pickleability of code objects is inconsistent

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

From report at bugs.python.org  Wed Jul 16 05:40:59 2014
From: report at bugs.python.org (Brendan Moloney)
Date: Wed, 16 Jul 2014 03:40:59 +0000
Subject: [New-bugs-announce] [issue21987] TarFile.getmember on directory
	requires trailing slash	iff over 100 chars
Message-ID: <1405482059.28.0.321220843423.issue21987@psf.upfronthosting.co.za>


New submission from Brendan Moloney:

If a directory path is under 100 char you have to omit the trailing slash from the name passed to 'getmember'. If it is over 100 you have to include the trailing slash.

As a work around I can use the private '_getmember' with 'normalize=True'.

I tested on 2.7.2 and searched the release notes looking for a related fix since then. I couldn't find anything there, or here in the issue tracker.

----------
components: Library (Lib)
messages: 223167
nosy: moloney
priority: normal
severity: normal
status: open
title: TarFile.getmember on directory requires trailing slash iff over 100 chars
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 16 11:06:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Jul 2014 09:06:24 +0000
Subject: [New-bugs-announce] [issue21988] Decrease iterating overhead it
	timeit
Message-ID: <1405501584.54.0.115556422233.issue21988@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently timeit has significant iterating overhead when tests fast statements. Such overhead makes hard to measure effects of microoptimizations. To decrease overhead and get more precise results we should repeat tested statement many times:

$ ./python -m timeit -s "x=10"  "x+x"
1000000 loops, best of 3: 0.2 usec per loop
$ ./python -m timeit -s "x=10"  "x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x; x+x"
100000 loops, best of 3: 14.6 usec per loop

Proposed patch makes it automatically for user. It unrolls and vectorize the loop, and decreases iterating overhead 1000 times:

$ ./python -m timeit -s "x=10"  "x+x"
10000000 loops, best of 3: 0.141 usec per loop

An user gets precision value without explicit cumbersome repeating.

----------
components: Library (Lib)
files: timeit_unroll_loops.patch
keywords: patch
messages: 223185
nosy: georg.brandl, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Decrease iterating overhead it timeit
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35966/timeit_unroll_loops.patch

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

From report at bugs.python.org  Wed Jul 16 14:40:19 2014
From: report at bugs.python.org (SylvainDe)
Date: Wed, 16 Jul 2014 12:40:19 +0000
Subject: [New-bugs-announce] [issue21989] Missing (optional) argument
	`start` and `end` in	documentation for list.index
Message-ID: <1405514419.16.0.727549411971.issue21989@psf.upfronthosting.co.za>


New submission from SylvainDe:

>From :

https://docs.python.org/2/tutorial/datastructures.html and
https://docs.python.org/3.4/tutorial/datastructures.html (and all other versions) :

----------------------------
    list.index(x)

        Return the index in the list of the first item whose value is x. It is an error if there is no such item.
----------------------------

>From `help(list)` :

----------------------------
 |  index(...)
 |      L.index(value, [start, [stop]]) -> integer -- return first index of value.
 |      Raises ValueError if the value is not present.
----------------------------

Thus, second and third parameter are undocumented.

----------
assignee: docs at python
components: Documentation
files: list_index_start_end.patch
keywords: patch
messages: 223195
nosy: SylvainDe, docs at python
priority: normal
severity: normal
status: open
title: Missing (optional) argument `start` and `end` in documentation for list.index
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35967/list_index_start_end.patch

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

From report at bugs.python.org  Wed Jul 16 16:28:48 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 16 Jul 2014 14:28:48 +0000
Subject: [New-bugs-announce] [issue21990] saxutils defines an inner class
	where a normal one would	do
Message-ID: <1405520928.93.0.195566496029.issue21990@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This makes things slower than they need to be (yes, even on CPython :-)), and is slightly confusing since usually inner classes are only used when a closure is needed.

Attached patch simply moves the class definition.

----------
components: Library (Lib)
files: sax.diff
keywords: patch
messages: 223209
nosy: alex
priority: normal
severity: normal
status: open
title: saxutils defines an inner class where a normal one would do
versions: Python 2.7
Added file: http://bugs.python.org/file35970/sax.diff

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

From report at bugs.python.org  Wed Jul 16 16:29:58 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Jul 2014 14:29:58 +0000
Subject: [New-bugs-announce] [issue21991] The new email API should use
	MappingProxyType instead of	returning new dicts.
Message-ID: <1405520998.88.0.739114728398.issue21991@psf.upfronthosting.co.za>


New submission from R. David Murray:

There are a few places in the new email API where dicts are returned containing what is conceptually static information.  Currently this is done by returning a copy of the dict from the object, so that user code modifying the dict won't break the object invariants.  It would be better to change these to MappingProxyType objects instead, before the API moves out of provisional status.

This issue is mostly a note to myself, since I'm the most likely to be able to figure out which places in the code need changing, but if anyone else wants to look at it feel free, since it will probably be a while before I get to it.

----------
components: email
keywords: easy
messages: 223211
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The new email API should use MappingProxyType instead of returning new dicts.
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Jul 16 18:13:48 2014
From: report at bugs.python.org (Igor Bronshteyn)
Date: Wed, 16 Jul 2014 16:13:48 +0000
Subject: [New-bugs-announce] [issue21992] New AST node Else() should be
	introduced
Message-ID: <1405527228.32.0.961029538035.issue21992@psf.upfronthosting.co.za>


New submission from Igor Bronshteyn:

Quoting Collin Winter:
"I'd like there to be an Else() node for If.orelse, While.orelse, etc. My motivation is that I need the lineno and col_offset values of the "else" statement for a code-coverage utility; as it is, I have to find the last lineno of the if/while/etc suite and the first lineno of the "else" suite and then search between those two for the "else" statement."

from: http://bugs.python.org/issue1659410
Lack of position for "else" token hampers implementing of even simple static analysis checker that calculates NCNB (non-comment non-blank) lines (e.g. in a function).

----------
components: Interpreter Core
messages: 223229
nosy: Igor.Bronshteyn
priority: normal
severity: normal
status: open
title: New AST node Else() should be introduced
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 16 23:43:37 2014
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 16 Jul 2014 21:43:37 +0000
Subject: [New-bugs-announce] [issue21993] counterintuitive behavior of
	list.index with boolean	values
Message-ID: <1405547017.25.0.264801773086.issue21993@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

>>> l = [False, True]
>>> l.index(True)
1
>>> l.index(False)
0

good, but:

>>> l = ['a', '', {}, 2.7, 1, 0, False, True]
>>> l.index(True)
4
>>> l.index(False)
5

Apparently, True and False get converted to int in comparisons to ints.
I would expect items to be compared either by:

a) object identity or
b) __eq__

but not this inconsistently.

Best,
Wolfgang

----------
components: Interpreter Core
messages: 223284
nosy: wolma
priority: normal
severity: normal
status: open
title: counterintuitive behavior of list.index with boolean values
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 17 00:46:59 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 16 Jul 2014 22:46:59 +0000
Subject: [New-bugs-announce] [issue21994] Syntax error in the ssl module
	documentation
Message-ID: <1405550819.52.0.585557894887.issue21994@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This can be seen at https://docs.python.org/3.4/library/ssl.html#ssl.SSLContext.check_hostname

It looks like the colon should be omitted, and the next line un-indented.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 223291
nosy: alex, christian.heimes, docs at python, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: Syntax error in the ssl module documentation
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 17 00:47:30 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Jul 2014 22:47:30 +0000
Subject: [New-bugs-announce] [issue21995] Idle: pseudofiles have no buffer
	attribute.
Message-ID: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

sys.stdin on 3.4.1 is also 'missing' (among public names) 'line_buffering' (True) and 'mode' ('r'). It seems that these could be trivially added, so the focus of this issue is 'buffer'. The associated 
.detach method is a no-op, (It is also a bit dangerous for interactive operation.)

3.4.1 Console interpreter:
>>> import sys; b = sys.stdin.buffer.readline()
a line
>>> b
b'a line\r\n'

3.4.1 Idle:
>>> import sys; b = sys.stdin.buffer.readline()
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    import sys; b = sys.stdin.buffer.readline()
AttributeError: 'PseudoInputFile' object has no attribute 'buffer'

https://docs.python.org/3/library/sys.html#sys.stdin
presents the idiom. It also warns (too narrowly -- 'if you are writing a library ...') that it might not.

As far as I could find, the Idle doc does not mention the standard streams, let alone Idle specific limitations.

I intentionally wrote the title as a statement of a problematical situation, rather than as a proposed solution, as there are two: change code and change doc.

Code: add .buffer as a bytes-oriented Pseudofile.

Doc: at least mention that standard streams are replaced by objects that ship text between processes, and use gui for input and display, and the consiquences of this.

----------
assignee: docs at python
components: Documentation, IDLE
messages: 223292
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: pseudofiles have no buffer attribute.
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 17 09:52:08 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 17 Jul 2014 07:52:08 +0000
Subject: [New-bugs-announce] [issue21996] gettarinfo method does not handle
	files without text	string names
Message-ID: <1405583528.37.0.553699872308.issue21996@psf.upfronthosting.co.za>


New submission from Martin Panter:

It looks like if you pass a ?fileobj? argument to ?gettarinfo?, it assumes it can use the ?name? as a text string.

>>> import tarfile
>>> with tarfile.open("/dev/null", "w") as tar, open("/bin/sh", "rb") as file: tar.gettarinfo(fileobj=file)
... 
<TarInfo 'bin/sh' at 0x7f13cc937f20>
>>> with tarfile.open("/dev/null", "w") as tar, open(b"/bin/sh", "rb") as file: tar.gettarinfo(fileobj=file)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/media/disk/home/proj/python/cpython/Lib/tarfile.py", line 1767, in gettarinfo
    arcname = arcname.replace(os.sep, "/")
TypeError: expected bytes, bytearray or buffer compatible object
>>> with tarfile.open("/dev/null", "w") as tar, open(0, "rb", closefd=False) as file: tar.gettarinfo(fileobj=file)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/media/disk/home/proj/python/cpython/Lib/tarfile.py", line 1766, in gettarinfo
    drv, arcname = os.path.splitdrive(arcname)
  File "Lib/posixpath.py", line 133, in splitdrive
    return p[:0], p
TypeError: 'int' object is not subscriptable

In my case, my code always sets the final TarInfo.name attribute later on, so the initial name does not matter. Perhaps at least the documentation should say that ?fileobj.name? must be a real unencoded file name string unless ?arcname? is also given. My workaround was to add a dummy arcname argument, a bit like this:

# Explicit dummy name to avoid using file name of bytes
tarinfo = self.tar.gettarinfo(fileobj=file, arcname="")
# . . .
tarinfo.name = "{}/{}".format(self.pkgname, name)

----------
components: Library (Lib)
messages: 223318
nosy: vadmium
priority: normal
severity: normal
status: open
title: gettarinfo method does not handle files without text string names
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 17 17:52:11 2014
From: report at bugs.python.org (ppperry)
Date: Thu, 17 Jul 2014 15:52:11 +0000
Subject: [New-bugs-announce] [issue21997] Pdb.set_trace debugging does not
	end correctly in IDLE
Message-ID: <1405612331.63.0.402043795388.issue21997@psf.upfronthosting.co.za>


New submission from ppperry:

In IDLE:
   >>>def dodebug():
	    pdb.set_trace()
   >>>dodebug()
   --Return--
   > <pyshell#6>(2)dodebug()->None
   (Pdb) s
   --Return--
   > <pyshell#8>(1)<module>()->None
   (Pdb) s
PDB should exit, but it doesn't
   > c:\python27\lib\idlelib\run.py(308)runcode()
   -> interruptable = False
   (Pdb)s
   > c:\python27\lib\idlelib\run.py(322)runcode()
   -> flush_stdout()
Quitting from this state raises an error:
   (Pdb)q

   Traceback (most recent call last):
   ** IDLE Internal Exception: 
        File "C:\Python27\lib\idlelib\run.py", line 100, in main
           ret = method(*args, **kwargs)
        File "C:\Python27\lib\idlelib\run.py", line 322, in runcode
           flush_stdout()
        File "C:\Python27\lib\idlelib\run.py", line 322, in runcode
           flush_stdout()
        File "C:\Python27\lib\bdb.py", line 49, in trace_dispatch
           return self.dispatch_line(frame)
        File "C:\Python27\lib\bdb.py", line 68, in dispatch_line
           if self.quitting: raise BdbQuit
     BdbQuit
The same example outside of IDLE:
     >>>def dodebug():
	    pdb.set_trace()
     >>>dodebug()
     --Return--
     > <stdin>(1)dodebug()->None
     (Pdb) s
     --Return--
     > <stdin>(1)<module>()->None
     (Pdb) s
     [clean pbd exit]
     >>>
Note: this bug does not occur with pdb.run().
OS: Windows XP

----------
components: IDLE, Library (Lib)
messages: 223342
nosy: ppperry
priority: normal
severity: normal
status: open
title: Pdb.set_trace debugging does not end correctly in IDLE
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 17 18:10:45 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jul 2014 16:10:45 +0000
Subject: [New-bugs-announce] [issue21998] asyncio: a new self-pipe should be
	created in the child	process after fork
Message-ID: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like asyncio does not suppport fork() currently: on fork(), the event loop of the parent and the child process share the same "self pipe".

Example:
---
import asyncio, os
loop = asyncio.get_event_loop()
pid = os.fork()
if pid:
    print("parent", loop._csock.fileno(), loop._ssock.fileno())
else:
    print("child", loop._csock.fileno(), loop._ssock.fileno())
---

Output:
---
parent 6 5
child 6 5
---

I'm not sure that it's revelant to use asyncio with fork, but I wanted to open an issue at least as a reminder.

I found the "self pipe" + fork issue when reading the issue #12060, while working on a fix for the signal handling race condition on FreeBSD: issue #21645.

----------
components: asyncio
messages: 223344
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: a new self-pipe should be created in the child process after fork
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 17 18:37:00 2014
From: report at bugs.python.org (Martin Morrison)
Date: Thu, 17 Jul 2014 16:37:00 +0000
Subject: [New-bugs-announce] [issue21999] shlex: bug in posix more handling
	of empty strings
Message-ID: <1405615020.91.0.261812812224.issue21999@psf.upfronthosting.co.za>


New submission from Martin Morrison:

Minimal testcase of the problem situation is tokenising (with posix mode on):

  ''),

Specifically, an empty string, followed by a non-word character, followed by a non-space character. In this case, the token buffer is empty and due to a missing check for (self.posix and quoted), an extra token is consumed and returned in the wrong order:

>>> s = shlex.shlex("'')abc", posix=True)
>>> s.get_token()
'abc'
>>> s.get_token()
')'
>>> s.get_token()
>>> 

I have patches to fix this issue in both default and 2.7. I've also checked there are no other occurrences of the same typo.

----------
files: shlex.default.patch
keywords: patch
messages: 223348
nosy: isoschiz
priority: normal
severity: normal
status: open
title: shlex: bug in posix more handling of empty strings
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35983/shlex.default.patch

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

From report at bugs.python.org  Thu Jul 17 20:38:32 2014
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 17 Jul 2014 18:38:32 +0000
Subject: [New-bugs-announce] [issue22000] cross type comparisons
	clarification
Message-ID: <1405622312.02.0.49093151571.issue22000@psf.upfronthosting.co.za>


New submission from Jim Jewett:

https://docs.python.org/3.5/library/stdtypes.html
says "Objects of different types, except different numeric types, never compare equal."  

Despite the location, this seems to strong a statement, because of subclasses and classes which define __eq__.

A first attempt at rewording:

Existing: """
Objects of different types, except different numeric types, never compare equal. Furthermore, some types (for example, function objects) support only a degenerate notion of comparison where any two objects of that type are unequal. The <, <=, > and >= operators will raise a TypeError exception when comparing a complex number with another built-in numeric type, when the objects are of different types that cannot be compared, or in other cases where there is no defined ordering.

Non-identical instances of a class normally compare as non-equal unless the class defines the __eq__() method.

Instances of a class cannot be ordered with respect to other instances of the same class, or other types of object, unless the class defines enough of the methods __lt__(), __le__(), __gt__(), and __ge__() (in general, __lt__() and __eq__() are sufficient, if you want the conventional meanings of the comparison operators).

The behavior of the is and is not operators cannot be customized; also they can be applied to any two objects and never raise an exception.

Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below).
"""

-->

"""
The is and is not operators can be applied to any pair of objects, and will never raise an exception.  They cannot be customized, as they refer to implementation details.  (For example, "abc" is "abc" may or may not be true.)

Other comparisons refer to an object's meaning, and therefore must be defined by the object's own class.  "abc" == "abc" is always True, because the str class defines equality that way.

The default implementation uses is (object identity) for equality and  raises a TypeError for the ordering comparisons.  Defining the __eq__ method allows different instances to be equivalent; also defining the __lt__ method allows them to be ordered in the normal way.  Some classes will also define __le__, __ne__, __ge__, and __gt__, either for efficiency or to provide unusual behavior.  

Except for numbers, instances of two different standard classes will be unequal, and will raise a TypeError when compared for ordering.

Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below).
"""

----------
assignee: docs at python
components: Documentation
messages: 223353
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: cross type comparisons clarification
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jul 17 21:39:21 2014
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 17 Jul 2014 19:39:21 +0000
Subject: [New-bugs-announce] [issue22001] containers "same" does not always
	mean "__eq__".
Message-ID: <1405625961.78.0.30088981548.issue22001@psf.upfronthosting.co.za>


New submission from Jim Jewett:

https://docs.python.org/3.5/reference/expressions.html#not-in

Containers are permitted to (and generally do) read "same as" as "is or __eq__), which can be confusing -- particularly in the section defining __eq__.

Several suggested changes:

"""
The values float('NaN') and Decimal('NaN') are special. The are identical to themselves, x is x but are not equal to themselves, x != x. Additionally, comparing any value to a not-a-number value will return False. For example, both 3 < float('NaN') and float('NaN') < 3 will return False.
"""
--> ("the" -> "they"; add a comma; add a final sentence) -->
"""
The values float('NaN') and Decimal('NaN') are special. They are identical to themselves, x is x, but are not equal to themselves, x != x. Additionally, comparing any value to a not-a-number value will return False. For example, both 3 < float('NaN') and float('NaN') < 3 will return False.  Note, however, that containers will normally implement item equality as "a is b or a==b", so that [f]==[f] and f in [f] may be true even when f!=f.
"""

also:

"""
Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and the two sequences must be of the same type and have the same length.
"""
--> (re-order; add the NaN workaround) -->
"""
Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, two sequences must be of the same type and have the same length, and each pair of corresponding elements must be identical or compare equal.  (Sequences can assume that identical elements are equal, despite odd cases like float('NaN').)
"""

I *think* it is OK to leave that caveat out of the mapping case, because "have the same (key, value) pairs" would now refer to the above.

----------
assignee: docs at python
components: Documentation
messages: 223362
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: containers "same" does not always mean "__eq__".
type: enhancement

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

From report at bugs.python.org  Thu Jul 17 22:09:20 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 17 Jul 2014 20:09:20 +0000
Subject: [New-bugs-announce] [issue22002] Make full use of test discovery in
	test subpackages
Message-ID: <1405627760.3.0.397447180395.issue22002@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch against 3.4 implementing Serhiy's suggestion in msg223277 and taking it a step further, actually using test discovery in all of the test.test_* subpackages.

To reduce duplication, the patch adds a 'load_package_tests' function to test.support, which is then used in each of the subpackages' load_tests function.

test_json and test_tools should have no visible changes from this patch.  test_asyncio and test_email do have slight differences, but only in verbosity level: pre-patch, `python -m test.test_(asyncio|email)` runs at verbosity=2 (support.run_unittest default); with patch, they run at verbosity=1 (unittest default).  test_asyncio also reports one more skipped test on Windows, due to a module that raises SkipTest on import.

@Brett: test_importlib sees the most changes, and I'd like to be sure that things are as you expect them to be.  It looks like all of the test_suite() stuff is unused leftovers from when "test_importlib" was "importlib.test" and that test_importlib has actually been relying on unittest discovery (but bypassing load_tests and thereby not working with `python -m unittest test.test_importlib`), but I'd like confirmation on that.

A nice bonus with this patch is that (for example) `python -m test.test_importlib.source` works, testing just the named test_importlib subpackage.

----------
components: Tests
files: package_discovery.diff
keywords: patch
messages: 223366
nosy: berker.peksag, brett.cannon, ezio.melotti, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Make full use of test discovery in test subpackages
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35987/package_discovery.diff

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

From report at bugs.python.org  Fri Jul 18 00:25:37 2014
From: report at bugs.python.org (David Wilson)
Date: Thu, 17 Jul 2014 22:25:37 +0000
Subject: [New-bugs-announce] [issue22003] BytesIO copy-on-write
Message-ID: <1405635937.15.0.406925083031.issue22003@psf.upfronthosting.co.za>


New submission from David Wilson:

This is a followup to the thread at https://mail.python.org/pipermail/python-dev/2014-July/135543.html , discussing the existing behaviour of BytesIO copying its source object, and how this regresses compared to cStringIO.StringI.

The goal of posting the patch on list was to try and stimulate discussion around the approach. The patch itself obviously isn't ready for review, and I'm not in a position to dedicate time to it just now (although in a few weeks I'd love to give it full attention!).

Ignoring this quick implementation, are there any general comments around the approach?

My only concern is that it might keep large objects alive in a non-intuitive way in certain circumstances, though I can't think of any obvious ones immediately.

Also interested in comments on the second half of that thread: "a natural extension of this is to do something very similar on the write side: instead of generating a temporary private heap allocation, generate (and freely resize) a private PyBytes object until it is exposed to the user, at which point, _getvalue() returns it, and converts its into an IO_SHARED buffer."

There are quite a few interactions with making that work correctly, in particular:

* How BytesIO would implement the buffers interface without causing the under-construction Bytes to become readonly

* Avoiding redundant copies and resizes -- we can't simply tack 25% slack on the end of the Bytes and then truncate it during getvalue() without likely triggering a copy and move, however with careful measurement of allocator behavior there are various tradeoffs that could be made - e.g. obmalloc won't move a <500 byte allocation if it shrinks by <25%. glibc malloc's rules are a bit more complex though.

Could also add a private _PyBytes_SetSize() API to allow truncation to the final size during getvalue() without informing the allocator. Then we'd simply overallocate by up to 10% or 1-2kb, and write off the loss of the slack space.

Notably, this approach completely differs from the one documented in http://bugs.python.org/issue15381 .. it's not clear to me which is better.

----------
components: Library (Lib)
files: cow.patch
keywords: patch
messages: 223383
nosy: dw
priority: normal
severity: normal
status: open
title: BytesIO copy-on-write
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35988/cow.patch

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

From report at bugs.python.org  Fri Jul 18 08:25:17 2014
From: report at bugs.python.org (Andrew Barnert)
Date: Fri, 18 Jul 2014 06:25:17 +0000
Subject: [New-bugs-announce] [issue22004] io documentation refers to newline
	as newlines
Message-ID: <1405664717.39.0.472140939197.issue22004@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

In at least one place in the io module documentation (io.IOBase.readline), and in the corresponding docstring, the newline parameter to open (and io.open, and io.Foo.__init__) is referred to as "newlines":

> The line terminator is always b'\n' for binary files; for text files, 
> the newlines argument to open() can be used to select the line 
> terminator(s) recognized.

(The newline parameter is closely related to the newlines attribute of the TextIOWrapper that gets created by the open call, but they're not the same thing, and I think were named differently intentionally.)

----------
assignee: docs at python
components: Documentation
messages: 223398
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: io documentation refers to newline as newlines
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 18 14:49:52 2014
From: report at bugs.python.org (Edward Oubrayrie)
Date: Fri, 18 Jul 2014 12:49:52 +0000
Subject: [New-bugs-announce] [issue22005] datetime.__setstate__ fails
	decoding python2 pickle
Message-ID: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>


New submission from Edward Oubrayrie:

pickle.loads raises a TypeError when calling the datetime constructor, (then a UnicodeEncodeError in the load_reduce function).

A short test program & the log, including dis output of both PY2 and PY3 pickles, are available in this gist; and extract on stackoverflow:
https://gist.github.com/eddy-geek/191f15871c1b9f801b76
http://stackoverflow.com/questions/24805105/

I am using pickle.dumps(reply, protocol=2) in PY2 
then pickle._loads(pickled, fix_imports=True, encoding='latin1') in PY3
(tried None and utf-8 without success)

Native cPickle loads decoding fails too, I am only using pure python's _loads for debugging.

Sorry if this is misguided (first time here)
Regards,
Edward

----------
components: Library (Lib)
messages: 223408
nosy: eddygeek
priority: normal
severity: normal
status: open
title: datetime.__setstate__ fails decoding python2 pickle
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jul 18 21:53:27 2014
From: report at bugs.python.org (Dan O'Reilly)
Date: Fri, 18 Jul 2014 19:53:27 +0000
Subject: [New-bugs-announce] [issue22006] thread module documentation
	erroneously(?) states not	all built-in functions release the GIL
Message-ID: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>


New submission from Dan O'Reilly:

Currently, the caveats section of the thread/_thread module has this statement in it:

"Not all built-in functions that may block waiting for I/O allow other threads to run. (The most popular ones (time.sleep(), file.read(), select.select()) work as expected.)"

As far as I know, this isn't the case; all built-in functions that do blocking I/O release the GIL, and therefore do indeed allow other threads to run.

I asked a question about this on stackoverflow recently (http://stackoverflow.com/q/24831458/2073595), and Mark Dickinson helpfully pointed out that this statement was added by Guido way back in 1994, which suggests it's probably just obsolete. If that's the case, the statement should be removed to avoid confusion.

----------
assignee: docs at python
components: Documentation
messages: 223428
nosy: dan.oreilly, docs at python
priority: normal
severity: normal
status: open
title: thread module documentation erroneously(?) states not all built-in functions release the GIL
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 18 23:10:00 2014
From: report at bugs.python.org (Jonathan Stewmon)
Date: Fri, 18 Jul 2014 21:10:00 +0000
Subject: [New-bugs-announce] [issue22007] sys.stdout.write on OS X is not
	EINTR safe
Message-ID: <1405717800.93.0.311765291104.issue22007@psf.upfronthosting.co.za>


New submission from Jonathan Stewmon:

Writing to sys.stdout on OS X can fail with IOError: [Errno 4] Interrupted system call.

I have observed this while trying to write to sys.stdout when SIGCHLD is received. The script below consistently reproduces the problem with python 2.7.2 on OS X 10.9.3.

import sys
import os
import signal
import subprocess
import time


children = {}
def claim_child():
    pid, status = os.wait()
    p = children.pop(pid)

def trap(sig, frame):
    claim_child()

signal.signal(signal.SIGCHLD, trap)

running = 0
max_procs = 70
program = [sys.executable, '-c', 'import sys, time; print sys.version; time.sleep(3)']
f = sys.stdout # crashes with: IOError: [Errno 4] Interrupted system call
# f = file('/tmp/eintr.log', 'w') # works just fine
while True:
    while len(children) < max_procs:
        f.write('starting program: {}\n'.format(program))
        p = subprocess.Popen(program)
        children[p.pid] = p
    time.sleep(0.05)

----------
components: IO
messages: 223435
nosy: jstewmon
priority: normal
severity: normal
status: open
title: sys.stdout.write on OS X is not EINTR safe
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul 19 00:45:49 2014
From: report at bugs.python.org (A Kaptur)
Date: Fri, 18 Jul 2014 22:45:49 +0000
Subject: [New-bugs-announce] [issue22008] Symtable's syntax warning should
	contain the word	"because"
Message-ID: <1405723549.99.0.479599106625.issue22008@psf.upfronthosting.co.za>


New submission from A Kaptur:

The symbol table's syntax error about unqualified exec is missing the word "because".

>>> def foo():
...     exec "a = 1"
...     def bar():
...         print a
... 
  File "<stdin>", line 2
SyntaxError: unqualified exec is not allowed in function 'foo' it contains a nested function with free variables

----------
assignee: docs at python
components: Documentation
files: issue.patch
keywords: patch
messages: 223447
nosy: akaptur, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Symtable's syntax warning should contain the word "because"
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35992/issue.patch

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

From report at bugs.python.org  Sat Jul 19 03:01:50 2014
From: report at bugs.python.org (Silverback Networks)
Date: Sat, 19 Jul 2014 01:01:50 +0000
Subject: [New-bugs-announce] [issue22009] pdb.set_trace() crashes when
	binary data is input via	stdin
Message-ID: <1405731710.65.0.406655018278.issue22009@psf.upfronthosting.co.za>


New submission from Silverback Networks:

sample.py:
import sys, pdb
infile = sys.stdin.buffer
pdb.set_trace()

command line:
python -m pdb sample.py < binary.exe

output:
> c:\users\me\dropbox\sample.py(1)<module>()
-> import sys, pdb
(Pdb) Traceback (most recent call last):
  File "C:\dev\Python\x86\lib\pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "C:\dev\Python\x86\lib\pdb.py", line 1542, in _runscript
    self.run(statement)
  File "C:\dev\Python\x86\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "c:\users\me\dropbox\test.py", line 1, in <module>
    import sys, pdb
  File "c:\users\me\dropbox\test.py", line 1, in <module>
    import sys, pdb
  File "C:\dev\Python\x86\lib\bdb.py", line 48, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\dev\Python\x86\lib\bdb.py", line 66, in dispatch_line
    self.user_line(frame)
  File "C:\dev\Python\x86\lib\pdb.py", line 259, in user_line
    self.interaction(frame, None)
  File "C:\dev\Python\x86\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\dev\Python\x86\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\dev\Python\x86\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
  File "C:\dev\Python\x86\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 72: character maps to <undefined>
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> c:\dev\python\x86\lib\encodings\cp1252.py(23)decode()
-> return codecs.charmap_decode(input,self.errors,decoding_table)[0]
(Pdb) Traceback (most recent call last):
  File "C:\dev\Python\x86\lib\pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "C:\dev\Python\x86\lib\pdb.py", line 1542, in _runscript
    self.run(statement)
  File "C:\dev\Python\x86\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "c:\users\me\dropbox\test.py", line 1, in <module>
    import sys, pdb
  File "c:\users\me\dropbox\test.py", line 1, in <module>
    import sys, pdb
  File "C:\dev\Python\x86\lib\bdb.py", line 48, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\dev\Python\x86\lib\bdb.py", line 66, in dispatch_line
    self.user_line(frame)
  File "C:\dev\Python\x86\lib\pdb.py", line 259, in user_line
    self.interaction(frame, None)
  File "C:\dev\Python\x86\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\dev\Python\x86\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\dev\Python\x86\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
  File "C:\dev\Python\x86\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 72: character maps to <undefined>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\dev\Python\x86\lib\runpy.py", line 171, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\dev\Python\x86\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\dev\Python\x86\lib\pdb.py", line 1685, in <module>
    pdb.main()
  File "C:\dev\Python\x86\lib\pdb.py", line 1677, in main
    pdb.interaction(None, t)
  File "C:\dev\Python\x86\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\dev\Python\x86\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\dev\Python\x86\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
  File "C:\dev\Python\x86\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 57: character maps to <undefined>

python version:
Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:24:06) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

----------
components: Windows
messages: 223453
nosy: silverbacknet
priority: normal
severity: normal
status: open
title: pdb.set_trace() crashes when binary data is input via stdin
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Jul 19 03:16:49 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jul 2014 01:16:49 +0000
Subject: [New-bugs-announce] [issue22010] Idle: better management of Shell
	window output
Message-ID: <1405732609.92.0.860307850836.issue22010@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Some of these ideas are in other issues, but possibly as side-thoughts. Any issues that directly address one of them can be added as dependency.

The appropriate place for menu entries would be the Shell menu, which currently has only 2, 1 of which I have never used. I don't necessarily think everything needs a key shortcut. There are already too many for me to remember.

1. Clear/restart shell. The same as restart, but also clear after. If the shell is burdened with unwanted lines of text, let someone start over without quitting and restarting.

2. Move last output to output window. Long help output, as for classes, would be a prime example use.  I am sure this idea has been mentioned, at least as a side note.

3. Delete last output. In the editor and while editing a statement, Undo undoes the effect of one or more of the last keypresses. I propose that in the shell, after <enter> submits a statement for processing, prints the output, and a new prompt, that Undo ^Z erase the new prompt, erase the output, and put the cursor at the end of the previously entered statement so it can be edited. (Idea prompted by Rick Johnson.)

One use case for this is to correct syntax and logic errors, especially when one is using Idle to prepare examples to copy and paste elsewhere. I do this constantly and manually filtering out bad input and output is a major nuisance. Another use case to simply delete unwanted output, especially if long. In the latter case, one would not want the new prompt deleted, but ^Z can only act one way, and I don't think we need two new commands.

4. We need one or more custom cut methods, as proposed in #11838 "make interactive code savable as a runnable script".  Such issues will depend on how we replace tabs in #7676.

----------
assignee: terry.reedy
messages: 223454
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: better management of Shell window output
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jul 19 18:10:07 2014
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Sat, 19 Jul 2014 16:10:07 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue22011=5D_=E2=80=9Cmake_test?=
 =?utf-8?q?=E2=80=9D_fails_with_3=2E4=2E1_on_Ubuntu_12=2E04?=
Message-ID: <1405786207.71.0.923118203201.issue22011@psf.upfronthosting.co.za>


New submission from Yannick Duch?ne:

`make test` fails with Python 3.4.1 on Ubuntu 12.04 Intel 32 bits.

The single `./configure` option used, was `--prefix=$HOME/.local`.

As attached file, an archive containing both standard output and standard error outputs.

Not some important error notifications appears only in standard output, not in standard error: ?OSError: [Errno 28] No space left on device?.

The latter is surprising as there was 11GiB free space.

----------
components: Build
files: test-logs.tar.gz
messages: 223468
nosy: Hibou57
priority: normal
severity: normal
status: open
title: ?make test? fails with 3.4.1 on Ubuntu 12.04
versions: Python 3.4
Added file: http://bugs.python.org/file35996/test-logs.tar.gz

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

From report at bugs.python.org  Sat Jul 19 20:30:28 2014
From: report at bugs.python.org (Tyler Wade)
Date: Sat, 19 Jul 2014 18:30:28 +0000
Subject: [New-bugs-announce] [issue22012] struct.unpack('?',
	'\x02') returns (False, ) on Mac OSX
Message-ID: <1405794628.01.0.592426531891.issue22012@psf.upfronthosting.co.za>


New submission from Tyler Wade:

On Mac OSX, struct.unpack incorrectly handles bools.

Python 3.4.1 (default, May 19 2014, 13:10:29)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.unpack('????', b'\x00\x01\x02\x03')
(False, True, False, True)

----------
assignee: ronaldoussoren
components: Macintosh
messages: 223470
nosy: ronaldoussoren, wayedt
priority: normal
severity: normal
status: open
title: struct.unpack('?', '\x02') returns (False,) on Mac OSX
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jul 20 08:56:34 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Jul 2014 06:56:34 +0000
Subject: [New-bugs-announce] [issue22013] Add at least minimal support for
	thread groups
Message-ID: <1405839394.09.0.812488093428.issue22013@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Currently, threading.Thread requires that group=None pending implementation of a ThreadGroup class such as that described in http://www.javaworld.com/article/2074481

This has been an open todo for very long time, possibly because it may be too big of a task to implement all the features including subgroups.

I think we can implement a small but useful set of features without too much difficultly:

path_explorers = threading.ThreadGroup('path_explorers')
for path in paths:
    threading.Thread(path_explorers, explore, (path,))
for thread in path_explorers: # enumerate unfinished explorers
    print(thread)
path_explorers.start()        # begin parallel search
path_explorers.join()         # wait for group to finish
print("Result:", best_path)

----------
components: Library (Lib)
messages: 223498
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add at least minimal support for thread groups
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Jul 20 09:00:24 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Jul 2014 07:00:24 +0000
Subject: [New-bugs-announce] [issue22014] Add summary table for OS exception
	<-> errno mapping
Message-ID: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

It would be handy if the main OS exception docs at https://docs.python.org/3/library/exceptions.html#os-exceptions included a summary table mapping between exception types and errno names, akin to the one in the original PEP (http://www.python.org/dev/peps/pep-3151/#new-exception-classes)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 223499
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Add summary table for OS exception <-> errno mapping
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jul 20 11:37:48 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Jul 2014 09:37:48 +0000
Subject: [New-bugs-announce] [issue22015] C signal handler doesn't
	save/restore errno
Message-ID: <1405849068.72.0.598999866788.issue22015@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The signal module has a wakefd feature which calls write(fd) in a signal handler, but the signal handler replaces errno without saving/restoring it.

See "Practice 4" in this article:
http://www.ibm.com/developerworks/linux/library/l-reent/index.html

Attached patch fixes the issue for Python 3.5. The bug should be fixed in Python 2.7, 3.4 and 3.5.

----------
files: signal_errno.patch
keywords: patch
messages: 223504
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: C signal handler doesn't save/restore errno
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36000/signal_errno.patch

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

From report at bugs.python.org  Sun Jul 20 13:19:14 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Jul 2014 11:19:14 +0000
Subject: [New-bugs-announce] [issue22016] Add a new 'surrogatereplace'
	output only error handler
Message-ID: <1405855154.64.0.953436457536.issue22016@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

This would be along the same lines as xmlcharrefreplace and backslashreplace, but only affect surrogate escaped characters.

Unlike surrogate escape, which reproduces the escaped characters directly in the data stream, this would follow the 'replace' error handler and insert an appropriately encoded '?' character in the output stream.

The use case would be any context where losing the escaped characters is preferred to either potentially injecting arbitrary binary data into the output (surrogateescape), failing with an exception (strict), or any of the other existing codecs.

It would differ from 'replace' in that normal code points that can't be encoded at all would still trigger an error.

----------
components: Interpreter Core, Library (Lib)
messages: 223508
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add a new 'surrogatereplace' output only error handler
versions: Python 3.5

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

From report at bugs.python.org  Sun Jul 20 18:24:34 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 20 Jul 2014 16:24:34 +0000
Subject: [New-bugs-announce] [issue22017] Bad reference counting in the
	_warnings module
Message-ID: <1405873474.62.0.40643670319.issue22017@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

$ ./python
Python 2.7.8+ (2.7:5563f895b215, Jul 20 2014, 18:10:28) 
[GCC 4.9.0 20140521 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.defaultaction = 'default'
>>> warnings.warn('some warning')
__main__:1: UserWarning: some warning
>>> exit()
Fatal Python error: Objects/dictobject.c:519 object at 0x7fce2013e2e0 has negative ref count -2604246222170760230
Aborted (core dumped)

The following patch fixes this: the new string object is referenced both by the static variable '_default_action' and the module attribute 'default_action'.
Python 3.5 handles this correctly.
The same kind of fix should also be applied to '_once_registry' and '_filters'.

diff --git a/Python/_warnings.c b/Python/_warnings.c
--- a/Python/_warnings.c
+++ b/Python/_warnings.c
@@ -903,6 +903,7 @@
         return;
 
     _default_action = PyString_FromString("default");
+    Py_INCREF(_default_action);
     if (_default_action == NULL)
         return;
     if (PyModule_AddObject(m, "default_action", _default_action) < 0)

----------
components: Interpreter Core
messages: 223519
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Bad reference counting in the _warnings module
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 20 21:47:13 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Jul 2014 19:47:13 +0000
Subject: [New-bugs-announce] [issue22018] signal: accept socket for
	signal.set_wakeup_fd()
Message-ID: <1405885633.45.0.930815175926.issue22018@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi,

I'm working on asyncio, someone asked why asyncio cannot be interrupted by CTRL+c (SIGINT):
https://code.google.com/p/tulip/issues/detail?id=191

On Windows, select.select() is not interrupted by CTRL+c. To get a reliable behaviour, interrupt select.select() on a signal, we can use signal.set_wakeup_fd(). New problem: on Windows, select.select() only supports sockets.

I propose to modify signal.set_wakeup_fd() to not only support files (use write), but also sockets (use send). Attached patch implements that.

This issue is part of a global PEP to modify how Python handles EINTR. I'm writing a PEP on that with Charles-Fran?ois Natali. The idea to retry on EINTR in some cases, like write(), so we need a way to wakeup the code on a signal, on all platforms.


Questions:

- I had to modify the pythoncore Visual Studio project to add a dependency to the WinSock library ("ws2_32.lib"). Is it a bad thing? We may split the _signal module into a new project, to only put the dependency there. What do you think? I'm not sure that it makes sense because the _signal module is always imported at Python startup, by initsigs() (search for the call to PyOS_InitInterrupts()).


- PySignal_SetWakeupFd() returns the old file descriptor, which is -1 by default. The API is not written to report errors. I chose to return -2 and clear the Python exception. Should we add a new function raising a Python exception on error? Ex: "int PySignal_SetWakeupFdWithError(int fd, int *old_fd)" returns 0 on success, -1 on error.


+        /* Import the _socket module to call WSAStartup() */
+        mod = PyImport_ImportModuleNoBlock("_socket");

I chose to import the _socket module because calling WSAStartup() requires also to call WSACleanup() at exit. I don't want to have two modules responsible for that.

I'm using "getsockopt(fd, SOL_SOCKET, SO_ERROR, ...)" to check if fd is a socket. Is there a better function to check if a file descriptor or handle is a socket?

According to the documentation, "GetFileType(handle) == FILE_TYPE_PIPE" is true for sockets, but also for (named and anonymous) pipes.

----------
components: Windows, asyncio
files: signal_socket.patch
keywords: patch
messages: 223532
nosy: gvanrossum, haypo, loewis, neologix, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: signal: accept socket for signal.set_wakeup_fd()
versions: Python 3.5
Added file: http://bugs.python.org/file36006/signal_socket.patch

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

From report at bugs.python.org  Mon Jul 21 02:49:15 2014
From: report at bugs.python.org (StupidHod)
Date: Mon, 21 Jul 2014 00:49:15 +0000
Subject: [New-bugs-announce] [issue22019] ntpath.join() error with Chinese
	character Path
Message-ID: <1405903755.61.0.322854383415.issue22019@psf.upfronthosting.co.za>


New submission from StupidHod:

When ntpath.join() works with a path that with Chinese character ,a unicode Decode error will happen.
detailes as:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xb2 in position 0: ordinal not in range(128)

As the interparter said,it happened at
result_path = result_path + p_path line 84.

as I modif this expression with "result_path = str(result_path) + str(p_path)",it works well.

----------
components: Library (Lib)
messages: 223552
nosy: StupidHod
priority: normal
severity: normal
status: open
title: ntpath.join() error with Chinese character Path
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 21 08:03:20 2014
From: report at bugs.python.org (Albert Ho)
Date: Mon, 21 Jul 2014 06:03:20 +0000
Subject: [New-bugs-announce] [issue22020] tutorial 9.10. Generators
	statement error
Message-ID: <1405922600.06.0.736556450587.issue22020@psf.upfronthosting.co.za>


New submission from Albert Ho:

https://docs.python.org/3/tutorial/classes.html
>>> for char in reverse('golf'):

I found that reverse didnt work
and i check the doc
https://docs.python.org/3.4/library/functions.html#reversed
>>> reversed(seq)?

I guess it just forget to change the statement

----------
messages: 223560
nosy: rt135792005
priority: normal
severity: normal
status: open
title: tutorial 9.10. Generators statement error
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Mon Jul 21 11:50:13 2014
From: report at bugs.python.org (Weinan Li)
Date: Mon, 21 Jul 2014 09:50:13 +0000
Subject: [New-bugs-announce] [issue22021] shutil.make_archive() root_dir do
	not work
Message-ID: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>


New submission from Weinan Li:

set root_dir do not work

output:
=====================================================
Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import shutil
>>> shutil.make_archive("tmp.tar.gz", "gztar", "c:/xjtu", "c:/tmp")
'C:\\Python34\\tmp.tar.gz.tar.gz'
=====================================================

source code of make_archive()
=====================================================
756    save_cwd = os.getcwd()
757    if root_dir is not None:
758        if logger is not None:
759            logger.debug("changing into '%s'", root_dir)
760        base_name = os.path.abspath(base_name)
761        if not dry_run:
762            os.chdir(root_dir)
...
...
782    try:
783        filename = func(base_name, base_dir, **kwargs)
784    finally:
=====================================================

base_name is set before chdir, so the archive always be created in cwd, whether set root_dir or not.
so, line 760 should be move below line 762

----------
components: Library (Lib)
messages: 223568
nosy: DemoHT
priority: normal
severity: normal
status: open
title: shutil.make_archive()  root_dir do not work
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jul 21 18:05:04 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jul 2014 16:05:04 +0000
Subject: [New-bugs-announce] [issue22022] test_pathlib: shutil.rmtree()
	sporadic failures on	Windows
Message-ID: <1405958704.27.0.741808263621.issue22022@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Sometimes, test_pathlib fails because shutil.rmtree() cannot remove a test directory. Example:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4833/steps/test/logs/stdio

======================================================================
ERROR: test_touch_common (test.test_pathlib.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 477, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 367, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 376, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 374, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_3444\\@test_3444_tmp\\dirB'

The error comes from this cleanup function:

        self.addCleanup(shutil.rmtree, BASE)

I don't understand how rmtree() can fail with "The directory is not empty".

Note: this buildbot runs 4 tests in parallel using the "-j4" command line option of regrtest.

----------
components: Tests, Windows
keywords: buildbot
messages: 223584
nosy: haypo
priority: normal
severity: normal
status: open
title: test_pathlib: shutil.rmtree() sporadic failures on Windows
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jul 21 19:38:29 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 21 Jul 2014 17:38:29 +0000
Subject: [New-bugs-announce] [issue22023] PyUnicode_FromFormat is broken on
	python 2
Message-ID: <1405964309.44.0.884917870385.issue22023@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

http://hg.python.org/cpython/file/2.7/Objects/unicodeobject.c#l840

Specifically it calls "PyObject_Str", which will return a PyStringObject * (cast to a PyObject *), and then calls "PyUnicode_GET_SIZE", which is of course totally incorrect.

This code was originally back-ported from 3.0 -> 2.6, so I imagine no one caught the bug then.

----------
components: Interpreter Core, Unicode
messages: 223594
nosy: alex, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormat is broken on python 2
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 21 22:00:08 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 21 Jul 2014 20:00:08 +0000
Subject: [New-bugs-announce] [issue22024] Add to shutil the ability to wait
	until files are	definitely deleted
Message-ID: <1405972808.55.0.924744488039.issue22024@psf.upfronthosting.co.za>


New submission from Zachary Ware:

As suggested by Martin in msg170717, shutil should grow some way to block until a given file/directory is actually deleted, due to Windows' scheme of not actually deleting a file until all handles to it are closed.

This could take the form of a 'wait=False' parameter to rmtree that causes rmtree to block until the file/dir is gone (which could mean blocking indefinitely), or a new function "wait_until_deleted(name, timeout=None)".

Related issues: #15946, #7443, #19629

----------
components: Library (Lib)
keywords: easy
messages: 223604
nosy: zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Add to shutil the ability to wait until files are definitely deleted
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jul 21 22:16:02 2014
From: report at bugs.python.org (Dan O'Reilly)
Date: Mon, 21 Jul 2014 20:16:02 +0000
Subject: [New-bugs-announce] [issue22025] webbrowser.get(command_line) does
	not support	Windows-style path separators
Message-ID: <1405973762.56.0.905297116521.issue22025@psf.upfronthosting.co.za>


New submission from Dan O'Reilly:

Currently, when webbrowser.get() is passed a "using" argument that consists of a command line string like "C:\Users\dan\AppData\Local\Google\Chrome\Application\chrome.exe %s", it will use shlex.split(command_line) to tokenize the string. However, when given Windows-style path separators (as is likely to be the case on Windows), shlex.split returns the path with all the separators removed:

>>> cmd = "C:\\Users\\oreild1\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe %s"
>>> shlex.split(cmd)
['C:Usersoreild1AppDataLocalGoogleChromeApplicationchrome.exe', '%s']

Of course, this means the browser object returned is useless. I'm not sure what the preferred way to fix this is: either document that POSIX-style path separators are required (even on Windows), or pass posix=False to shlex.split if we're running Windows.

----------
components: Library (Lib)
messages: 223606
nosy: dan.oreilly
priority: normal
severity: normal
status: open
title: webbrowser.get(command_line) does not support Windows-style path separators
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jul 21 22:22:04 2014
From: report at bugs.python.org (Les Bothwell)
Date: Mon, 21 Jul 2014 20:22:04 +0000
Subject: [New-bugs-announce] [issue22026] 2.7.8 ttk Button text display
	problem
Message-ID: <1405974124.93.0.889625077741.issue22026@psf.upfronthosting.co.za>


New submission from Les Bothwell:

My system: Windows 7 64 bit.  Python 2.7.8 (32 bit)
There's a problem with ttk button label text truncation when using large fonts on 2.7.8.  2.7.6 works Ok.  With 2.7.6, increasing the font size in a ttk style makes the button large enough to display the text properly.  With 2.7.8 the button seems to be large enough but the text is truncated on the right.  See attached file for pics.
Since issue 21665 is not closed yet, is this a side effect of ttk build problems?

This displays the problem..
from Tkinter import *
import ttk

from oxogame import *

class MainWindow(Frame):
    def __init__(self, master=None):
        " Initialise main window with controls "
        Frame.__init__(self, master)
        master.title('Font problem')
        ttk.Style().configure('Square.TButton', font='Arial 24 bold', width=1, height=1, padding=(6,0))

        ttk.Button(self, state=NORMAL, text='X', style='Square.TButton').pack(side=LEFT)
        ttk.Button(self, state=NORMAL, text='O', style='Square.TButton').pack(side=LEFT)
        self.pack(side=LEFT, fill=None, expand=0)

if __name__ == "__main__":
    root = Tk()
    root.resizable(0, 0)
    root.attributes("-toolwindow", 1)
    MainWindow(root).mainloop()

----------
components: Tkinter
files: ttk_font.pdf
messages: 223607
nosy: les.bothwell
priority: normal
severity: normal
status: open
title: 2.7.8 ttk Button text display problem
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36013/ttk_font.pdf

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

From report at bugs.python.org  Mon Jul 21 23:29:00 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Mon, 21 Jul 2014 21:29:00 +0000
Subject: [New-bugs-announce] [issue22027] RFC 6531 (SMTPUTF8) support in
	smtplib
Message-ID: <1405978140.81.0.388141454985.issue22027@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

This patch is related to and depends on issue 21725. I put it here for review, it can be applied (maybe with small changes) as soon as issue 21725 is fixed.

----------
components: email
files: smtplib_smtputf8_issue21725-dependent.patch
keywords: patch
messages: 223610
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: RFC 6531 (SMTPUTF8) support in smtplib
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36015/smtplib_smtputf8_issue21725-dependent.patch

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

From report at bugs.python.org  Tue Jul 22 04:04:26 2014
From: report at bugs.python.org (Jim Conyngham)
Date: Tue, 22 Jul 2014 02:04:26 +0000
Subject: [New-bugs-announce] [issue22028] Python 3.4.1 Installer ended
	prematurely (Windows msi)
Message-ID: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za>


New submission from Jim Conyngham:

Python will not install on my Windows 7 (64-bit) OS.

I have repeatedly tried the install with variations (specifying an install directly vs. taking the default; running as admininstrator vs. not; with and without logging) and with multiple downloads python-3.4.1.msi, python-3.4.1.amd64.msi, and python-3.4.0.amd64.msi.  No matter what, it always fails with the same symptoms.

msiexec log file is attached.  There are a number of errors indicated on the log, but the one that's fatal seems to be this one:

MSI (s) (24:8C) [14:46:34:848]: Executing op: CustomActionSchedule(Action=UpdatePip,ActionType=3090,Source=F:\Shared.W7\Python34\python.exe,Target=-m ensurepip -U --default-pip,)
CustomAction UpdatePip returned actual error code 3 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (24:8C) [14:46:34:957]: Note: 1: 1722 2: UpdatePip 3: F:\Shared.W7\Python34\python.exe 4: -m ensurepip -U --default-pip 
MSI (s) (24:8C) [14:46:34:957]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action UpdatePip, location: F:\Shared.W7\Python34\python.exe, command: -m ensurepip -U --default-pip 
MSI (s) (24:8C) [14:46:41:292]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (24:8C) [14:46:41:292]: Product: Python 3.4.1 -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action UpdatePip, location: F:\Shared.W7\Python34\python.exe, command: -m ensurepip -U --default-pip 

Action ended 14:46:41: InstallFinalize. Return value 3.

The same text, "There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." appears in a message box at the point of failure.

----------
components: Installation
files: python.log
messages: 223621
nosy: DieInSente
priority: normal
severity: normal
status: open
title: Python 3.4.1 Installer ended prematurely (Windows msi)
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file36020/python.log

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

From report at bugs.python.org  Tue Jul 22 06:46:53 2014
From: report at bugs.python.org (paul j3)
Date: Tue, 22 Jul 2014 04:46:53 +0000
Subject: [New-bugs-announce] [issue22029] argparse - CSS white-space: like
	control for individual	text blocks
Message-ID: <1406004413.12.0.04362068929.issue22029@psf.upfronthosting.co.za>


New submission from paul j3:

A number of the issues seek to customize the wrapping behavior in HelpFormatter - beyond what the current Formatter subclasses offer.

http://bugs.python.org/issue13923 and http://bugs.python.org/issue12806 - want a wrapping method that preserves existing \n, while still wrapping long lines.

http://bugs.python.org/issue12806#msg144353 - suggests that this formatter is similar to CSS property white-space: pre-wrap.

http://bugs.python.org/issue9399 - wants to write a pre-formatted 'license' text using a 'version'-like Action.
 -
http://bugs.python.org/issue13023  - wants to use 2 HelpFormatter subclasses at the same time (Raw and Defaults).

http://bugs.python.org/issue13023#msg144475: "Yeah, adding a formatter instance seems overkill for the usual case of wanting to preserve formatting of the epilog."

http://bugs.python.org/issue12284 - wants to put formatted examples in the epilog.

It might be easier to handle these issues if the user could designate how an individual text block (description, epilog, help) is to be formatted.  

HTML has a '<pre>' tag, CSS has 'white-space:' attribute (with 5 styles of wrapping and white-space handling).

The usage example might be something like:

    parser = ArgumentParser(prog='PROG',
        description = NoWrap('This is a description...'),
        epilog = PreWrap('Multipoint epilog with examples...'),
        )
    parser.add_argument('-f', help='help with normal wrapping')

----------
components: Library (Lib)
messages: 223625
nosy: BreamoreBoy, GraylinKim, bethard, denilsonsa, eric.araujo, jonash, paul.j3
priority: normal
severity: normal
status: open
title: argparse - CSS white-space: like control for individual text blocks
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Jul 22 09:32:08 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Jul 2014 07:32:08 +0000
Subject: [New-bugs-announce] [issue22030] Use calloc in set resizing
Message-ID: <1406014328.9.0.576652284701.issue22030@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Victor, how does this look?

----------
assignee: haypo
files: set_calloc.diff
keywords: patch
messages: 223638
nosy: haypo, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Use calloc in set resizing
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file36024/set_calloc.diff

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

From report at bugs.python.org  Tue Jul 22 10:50:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jul 2014 08:50:42 +0000
Subject: [New-bugs-announce] [issue22031] Hexadecimal id in reprs
Message-ID: <1406019042.04.0.51382116159.issue22031@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Default repr of an instance looks as:

>>> object()
<object object at 0xb71a14a8>

Many specialized reprs follow a pattern <... at {hexadecimal id}...>. But there are few deviations:

1. Reprs of WeakValueDictionary and WeakKeyDictionary in the weakref module output decimal id.

2. reprlib and reprs of CDLL in the ctypes module and DateTime and MultiCall in the xmlrpc.client module output hexadecimal id but without the "0x" prefix.

Proposed patch makes these cases to conform with other reprs.

----------
components: Library (Lib)
files: repr_hex_id.diff
keywords: patch
messages: 223647
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Hexadecimal id in reprs
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file36025/repr_hex_id.diff

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

From report at bugs.python.org  Tue Jul 22 11:02:36 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jul 2014 09:02:36 +0000
Subject: [New-bugs-announce] [issue22032] Use __qualname__ together with
	__module__
Message-ID: <1406019756.34.0.140996851672.issue22032@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Often when class name is reported in stdlib (e.g. in reprs), it used together with module name: '%s.%s' % (self.__class__.__module__, self.__class__.__name__). But this code is wrong when a class is nested. The __qualname__ attribute should be used instead of just __name__ (and it is already used in multiple places).

Proposed patch replaces __name__ to __qualname__ when it used together with module name to format full class name.

----------
components: Library (Lib)
files: repr_qualname.diff
keywords: patch
messages: 223649
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use __qualname__ together with __module__
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36026/repr_qualname.diff

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

From report at bugs.python.org  Tue Jul 22 11:08:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jul 2014 09:08:04 +0000
Subject: [New-bugs-announce] [issue22033] Subclass friendly reprs
Message-ID: <1406020084.96.0.790015152809.issue22033@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some reprs in stdlib are subclass friendly. They contains class name or even fully qualified class name and substitute appropriate subclass name in subclasses. But some reprs contains hardcoded either class name, or module name, or fully qualified class name. Proposed patch makes multiple reprs in stdlib more subclass friendly.

See also issue22032.

----------
components: Library (Lib)
files: repr_subclass_friendly.diff
keywords: patch
messages: 223650
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Subclass friendly reprs
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36027/repr_subclass_friendly.diff

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

From report at bugs.python.org  Tue Jul 22 11:33:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jul 2014 09:33:29 +0000
Subject: [New-bugs-announce] [issue22034] posixpath.join() and bytearray
Message-ID: <1406021609.78.0.443791365349.issue22034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

posixpath.join() raises misleading exception in case when all arguments are bytearrays:

>>> import posixpath
>>> posixpath.join(bytearray(b'foo'), bytearray(b'bar'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/posixpath.py", line 91, in join
    "components.") from None
TypeError: Can't mix strings and bytes in path components.

This bug was introduced in issue15377 and misleading test which provoked it was added in issue15180.

I proposed two patches. Patch for 3.4 only eliminates wrong specialcasing of bytearray (none of os.path methods work with bytearray). Patch for 3.5 also adds better error messages for wrong argument types of posixpath.join (of course we can apply it to 3.4 too).

----------
components: Library (Lib)
files: posixpath_join_bytearray-3.4.diff
keywords: patch
messages: 223654
nosy: hynek, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: posixpath.join() and bytearray
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36028/posixpath_join_bytearray-3.4.diff

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

From report at bugs.python.org  Tue Jul 22 12:20:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jul 2014 10:20:40 +0000
Subject: [New-bugs-announce] [issue22035] Fatal error in dbm.gdbm
Message-ID: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It is possible to crash Python by breaking opened gdbm database.

>>> import _gdbm as dbm
>>> db = dbm.open('x.db', 'n')
>>> open('x.db', 'wb').close()
>>> db[b'a'] = b'b'
gdbm fatal: read error

Proposed patch tries to convert fatal gdbm into regular exception or in Python fatal error (which at least produces traceback).

>>> import _gdbm as dbm
>>> db = dbm.open('x.db', 'n')
>>> open('x.db', 'wb').close()
>>> db[b'a'] = b'b'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_gdbm.error: gdbm fatal: read error

----------
components: Extension Modules
files: dbm_gdbm_fatal_error.patch
keywords: patch
messages: 223658
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fatal error in dbm.gdbm
type: crash
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36031/dbm_gdbm_fatal_error.patch

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

From report at bugs.python.org  Tue Jul 22 17:20:42 2014
From: report at bugs.python.org (Martin Matusiak)
Date: Tue, 22 Jul 2014 15:20:42 +0000
Subject: [New-bugs-announce] [issue22036] Obsolete reference to stringobject
	in comment
Message-ID: <1406042442.28.0.89298124162.issue22036@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

bits shared by the stringobject and unicodeobject implementations (and
possibly other modules, in a not too distant future).

"stringobject" should be "bytesobject"

----------
components: Interpreter Core
files: fix_typo_stringlib.diff
keywords: patch
messages: 223669
nosy: numerodix
priority: normal
severity: normal
status: open
title: Obsolete reference to stringobject in comment
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36034/fix_typo_stringlib.diff

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

From report at bugs.python.org  Tue Jul 22 18:51:51 2014
From: report at bugs.python.org (Aaron Hill)
Date: Tue, 22 Jul 2014 16:51:51 +0000
Subject: [New-bugs-announce] [issue22037] Poor grammar in asyncio TCP echo
	client example
Message-ID: <1406047911.63.0.907095249067.issue22037@psf.upfronthosting.co.za>


New submission from Aaron Hill:

The last sentence in the explanation of the TCP echo client currently reads: 

"At run_until_complete() exit, the loop is no more running, so there is no need to stop the loop in case of an error".

The grammar should be improved to something like "...the loop is no longer running", or "...the loop has stopped running"

The current documentation can be found here: https://docs.python.org/3/library/asyncio-protocol.html#echo-client

----------
assignee: docs at python
components: Documentation
messages: 223673
nosy: Aaron1011, docs at python
priority: normal
severity: normal
status: open
title: Poor grammar in asyncio TCP echo client example

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

From report at bugs.python.org  Tue Jul 22 19:24:12 2014
From: report at bugs.python.org (Vitor de Lima)
Date: Tue, 22 Jul 2014 17:24:12 +0000
Subject: [New-bugs-announce] [issue22038] Implement atomic operations on
	non-x86 platforms
Message-ID: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za>


New submission from Vitor de Lima:

The atomic operations listed in the pyatomic.h header file were implemented only for the x86 architecture, this patch uses the atomic bultins available in GCC >= 4.7 to implement such operations, allowing it to work properly in other platforms.

----------
components: Interpreter Core
files: atomic.patch
keywords: patch
messages: 223676
nosy: Vitor.de.Lima
priority: normal
severity: normal
status: open
title: Implement atomic operations on non-x86 platforms
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36035/atomic.patch

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

From report at bugs.python.org  Tue Jul 22 19:56:30 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jul 2014 17:56:30 +0000
Subject: [New-bugs-announce] [issue22039] PyObject_SetAttr doesn't mention
	value = NULL
Message-ID: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

PyObject_SetAttr, when called with value == NULL, actually deletes the attribute, but the documentation doesn't say it. It mentions PyObject_DelAttr, but it is only a macro and can therefore not be looked up using e.g. ctypes.

----------
assignee: docs at python
components: Documentation
messages: 223678
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: PyObject_SetAttr doesn't mention value = NULL
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jul 22 21:54:30 2014
From: report at bugs.python.org (Paul Moore)
Date: Tue, 22 Jul 2014 19:54:30 +0000
Subject: [New-bugs-announce] [issue22040] Add a "force" parameter to
	shutil.rmtree
Message-ID: <1406058870.67.0.270826115135.issue22040@psf.upfronthosting.co.za>


New submission from Paul Moore:

It would be useful for shutil.rmtree to have a "force" argument that overrode read-only permission issues, essentially replicating the behaviour of the -f flag in rm -rf (Unix) and the -force parameter of del (Windows Powershell).

It's possible to use the onerror callback to implement this, but it's tricky to get right in a cross-platform manner. See http://stackoverflow.com/questions/2656322, which recommends

def onerror(func, path, exc_info):
    if not os.access(path, os.W_OK):
        os.chmod(path, stat.S_IWUSR)
        func(path)
    else:
        raise

and http://stackoverflow.com/questions/1889597 which recommends

def remove_readonly(func, path, excinfo):
    os.chmod(path, stat.S_IWRITE)
    func(path)

It's not clear whether either of these is portable, though (the former looks to me like it's Unix-specific and the latter like it's for Windows, but I'm not sure).

Having the functionality available in the standard library function directly avoids having people write tricky and potentially buggy code for what is a pretty common situation. (In particular, this comes up a lot in code that deletes git checkouts on Windows, where git makes parts of the .git directory readonly).

----------
components: Library (Lib)
messages: 223685
nosy: pmoore
priority: normal
severity: normal
status: open
title: Add a "force" parameter to shutil.rmtree
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Jul 22 22:19:20 2014
From: report at bugs.python.org (Alejandro MJ)
Date: Tue, 22 Jul 2014 20:19:20 +0000
Subject: [New-bugs-announce] [issue22041] http POST request with python 3.3
	through web proxy
Message-ID: <1406060360.4.0.822886887897.issue22041@psf.upfronthosting.co.za>


New submission from Alejandro MJ:

I'm trying this specific method with python, in order to use a different ip source, to do a POST request: 

import http.client, urllib.parse
data = urllib.parse.urlencode({'QLastname': 'DIAZ HERNANDEZ', 'QFirstname': 'JAIME'})
headers = {"Content-type": "application/x-www-form-urlencoded","Accept": "text/plain"}
conn = http.client.HTTPConnection("www.infobel.com",80, source_address=("16.19.109.51", 0))
conn.request("POST", "/es/spain/people.aspx", data, headers)
response = conn.getresponse()
print(response.status, response.reason)
data = response.read()
conn.close()

It works perfectly when I test it without a proxy, but when I try with proxy connection, I receive this error:

>>> conn.request("POST", "/es/spain/people.aspx", data, headers)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\http\client.py", line 1090, in request
    self._send_request(method, url, body, headers)
  File "C:\Python34\lib\http\client.py", line 1128, in _send_request
    self.endheaders(body)
  File "C:\Python34\lib\http\client.py", line 1086, in endheaders
    self._send_output(message_body)
  File "C:\Python34\lib\http\client.py", line 924, in _send_output
    self.send(msg)
  File "C:\Python34\lib\http\client.py", line 859, in send
    self.connect()
  File "C:\Python34\lib\http\client.py", line 836, in connect
    self.timeout, self.source_address)
  File "C:\Python34\lib\socket.py", line 509, in create_connection
    raise err
  File "C:\Python34\lib\socket.py", line 500, in create_connection
    sock.connect(sa)

TimeoutError: [WinError 10060] Se produjo un error durante el intento...

How could I follow proxy configuration in this script? 

This is the code I made to test with proxy (following the documentation of Python):

import http.client, urllib.parse
data = urllib.parse.urlencode({'QLastname': 'DIAZ HERNANDEZ', 'QFirstname': 'JAIME'})
headers={"Content-Type":"application/x-www-form-urlencoded","Accept":"text/plain"}
conn = http.client.HTTPConnection(proxy_url,8080, source_address=(ipAddress, 0))
conn.set_tunnel("www.infobel.com")
conn.request("POST", "/es/spain/people.aspx", data, headers)
response = conn.getresponse()
print(response.status, response.reason)
data = response.read()
conn.close()

I could't make it work in this SO:
SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 2 

The message that proxy give us is this:

2014-07-22 08:31:49 87 16.19.109.51 23.2.2.22 - - - PROXIED "none" -  200 TCP_ACCELERATED CONNECT - tcp www.infobel.com 80 / - - - 23.2.2.22 39 39 - 
2014-07-22 08:31:49 1  16.19.109.51 23.2.2.22 - - dns_unresolved_hostname PROXIED "none" -  404 TCP_ERR_MISS POST - http cachebdvg1.igrupobbva 8080 /es/spain/people.aspx - aspx - 23.2.2.22 815 230 - 

So I tried to prove it in other SO, such as Windows, in a different computer. A curious thing... I've tried this with Python3.4.1 in Windows, and it didn't work. But when I proved with Python3.3.5 it works!! 

Thanks for help.

----------
components: Windows
messages: 223688
nosy: AlexMJ
priority: normal
severity: normal
status: open
title: http POST request with python 3.3 through web proxy
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul 23 02:49:30 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jul 2014 00:49:30 +0000
Subject: [New-bugs-announce] [issue22042] signal.set_wakeup_fd(fd): set the
	fd to non-blocking mode
Message-ID: <1406076570.98.0.190305939229.issue22042@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I think that signal.set_wakeup_fd(fd) must set the file descriptor to the non-blocking mode, instead of requiring the file descriptor mode to be non-blocking.

Atttached patch implements this idea.

See also the issue #22018 which proposes to support sockets in signal.set_wakeup_fd(fd) on Windows.

We have to decide if signal.set_wakeup_fd() is supposed to support files or not on Windows. Non-blocking mode does not exist for files on Windows, only for sockets.

I didn't test my patch on Windows yet.

Note: the new _Py_set_blocking() function tries to use ioctl() instead of fnctl() when available to only use one syscall instead of two. I used the same optimization in _Py_set_inheritable().

----------
files: signal_nonblock.patch
keywords: patch
messages: 223710
nosy: haypo
priority: normal
severity: normal
status: open
title: signal.set_wakeup_fd(fd): set the fd to non-blocking mode
versions: Python 3.5
Added file: http://bugs.python.org/file36039/signal_nonblock.patch

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

From report at bugs.python.org  Wed Jul 23 04:10:01 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jul 2014 02:10:01 +0000
Subject: [New-bugs-announce] [issue22043] Use a monotonic clock to compute
	timeouts
Message-ID: <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, socket methods (ex: accept, recv, recvfrom, recvmsg, send, sendto, sendmsg), threading.Lock.acquire() and threading.RLock.acquire() use the system clock to compute their timeout. It's fine for the first call. But if the call is interrupted and the timeout need to be recomputed, it can wait too short or too long. Timeouts must use a monotonic clock, not the system clock. See the PEP 418 for more information.

Python modules were already patched to use the time.monotonic() function implemented in Python 3.3.

Attached patch fixes also functions which still use the system clock to compute timeouts.

A major change of the patch is that a monotonic clock is now require to use Python 3.5. Last time I checked, there was only one OS without monotonic clock: GNU Hurd. Hurd maintainers can patch Python 3.5 to fallback on the system clock until Hurd provides a monotonic clock.

Another important change is that Python now depends on the librt on Solaris and on Linux with glibc older than 2.17 (clock_gettime is now available directly in the libc since glibc 2.17).

----------
files: pymonotonic.patch
keywords: patch
messages: 223715
nosy: haypo
priority: normal
severity: normal
status: open
title: Use a monotonic clock to compute timeouts
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36041/pymonotonic.patch

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

From report at bugs.python.org  Wed Jul 23 06:53:02 2014
From: report at bugs.python.org (Tom Flanagan)
Date: Wed, 23 Jul 2014 04:53:02 +0000
Subject: [New-bugs-announce] [issue22044] Premature Py_DECREF while
	generating a TypeError in	call_tzinfo_method
Message-ID: <1406091182.12.0.549229771581.issue22044@psf.upfronthosting.co.za>


New submission from Tom Flanagan:

call_tzinfo_method in Modules/_datetimemodule.c:900 calls Py_DECREF(offset)
before trying to use offset to generate a TypeError message.

This causes a crash if that was the last reference to offset and Py_DECREF clears it.

----------
components: Library (Lib)
files: python_bug.diff
keywords: patch
messages: 223722
nosy: Knio, belopolsky
priority: normal
severity: normal
status: open
title: Premature Py_DECREF while generating a TypeError in call_tzinfo_method
type: crash
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36042/python_bug.diff

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

From report at bugs.python.org  Wed Jul 23 14:17:42 2014
From: report at bugs.python.org (Shannon Kerr)
Date: Wed, 23 Jul 2014 12:17:42 +0000
Subject: [New-bugs-announce] [issue22045] Python make issue
Message-ID: <1406117862.23.0.135696000898.issue22045@psf.upfronthosting.co.za>


New submission from Shannon Kerr:

If you execute the following commands on a system that doesn?t already have Python 2.7.X installed on it, it will result in bloated libs that statically link libpythyon2.7.a instead of the locally built libpython2.7.so:

./configure
make
sudo make install
./configure ?enable-shared
make
sudo make install


Due to the library search path order in the Python build tools being:
-L /usr/local/lib -L .
the first lib found is in /usr/local/lib and it is the static library, so this is used to link.  This results in, for example, cPickle.so being 4.9M instead of 188K.

Shouldn't the just-built local library be used before anything on the system?

----------
components: Build
messages: 223736
nosy: skerr
priority: normal
severity: normal
status: open
title: Python make issue
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 23 14:20:23 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 23 Jul 2014 12:20:23 +0000
Subject: [New-bugs-announce] [issue22046] ZipFile.read() should mention that
	it might throw	NotImplementedError
Message-ID: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>


New submission from Jason Heeris:

As per issue 5701, the zipfile.ZipFile.read() method will throw a NotImplementedError if the compression scheme is not supported. However, there is no mention of this possibility in the documentation for the read() method. I would suggest, say, "Calling read() on a ZipFile that uses an unsupported compression scheme (eg. implode) will raise a NotImplementedError."

It looks like you can use the testzip() method to check that this won't happen (ie. after you open the file but before you extract an entry). If that is really the expected way to check for this kind of condition, it would be nice to mention that too (under either method).

----------
assignee: docs at python
components: Documentation
messages: 223737
nosy: detly, docs at python
priority: normal
severity: normal
status: open
title: ZipFile.read() should mention that it might throw NotImplementedError
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Jul 23 18:03:44 2014
From: report at bugs.python.org (Sam Kerr)
Date: Wed, 23 Jul 2014 16:03:44 +0000
Subject: [New-bugs-announce] [issue22047] argparse improperly prints
	mutually exclusive options	when they are in a group
Message-ID: <1406131424.14.0.0235697032218.issue22047@psf.upfronthosting.co.za>


New submission from Sam Kerr:

The following code:

   import argparse
   parser = argparse.ArgumentParser()
   group1 = parser.add_mutually_exclusive_group()
   group2 = group1.add_mutually_exclusive_group()
   group2.add_argument('-hello',action='store_true', help="A flag")
   args = parser.parse_args()

produces this output:

   skerr at gravel:~$ python bug.py -h
   usage: bug.py [-h] [[-hello]

   optional arguments:
        -h, --help  show this help message and exit
        -hello      A flag
   skerr at gravel:~$ 

Note the double [[ around hello, but there is no double ]] to close it. This is the error.

----------
components: Library (Lib)
messages: 223744
nosy: Sam.Kerr
priority: normal
severity: normal
status: open
title: argparse improperly prints mutually exclusive options when they are in a group
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 23 19:08:19 2014
From: report at bugs.python.org (Dmitry Korchemny)
Date: Wed, 23 Jul 2014 17:08:19 +0000
Subject: [New-bugs-announce] [issue22048] Add weighted random choice to
	random package
Message-ID: <1406135299.72.0.385494554352.issue22048@psf.upfronthosting.co.za>


New submission from Dmitry Korchemny:

Need to have a function for weighted randomization:

given a dictionary: key -> weight (= non-negative number), return a key of the dictionary with the probability proportional to its weight. This capability is basic and is badly missing.

----------
components: Library (Lib)
messages: 223746
nosy: dkorchem
priority: normal
severity: normal
status: open
title: Add weighted random choice to random package
versions: Python 3.5

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

From report at bugs.python.org  Wed Jul 23 19:16:22 2014
From: report at bugs.python.org (Chris Bruner)
Date: Wed, 23 Jul 2014 17:16:22 +0000
Subject: [New-bugs-announce] [issue22049] argparse: type=<callable> doesn't
	honor nargs > 1
Message-ID: <1406135782.37.0.476079892774.issue22049@psf.upfronthosting.co.za>


New submission from Chris Bruner:

>From the documentation, I think that argparse should pass the entire nargs-long string to the "type=" callable. Instead, it only passes the first argument (of nargs), making it impossible within argparse's framework to check for a tuple of mixed types, e.g., 2 ints and a float (my case), or a string and three numbers, etc.

See attached reproducer.

----------
files: argparse_typedef_bug.py
messages: 223748
nosy: Chris.Bruner
priority: normal
severity: normal
status: open
title: argparse: type=<callable> doesn't honor nargs > 1
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36048/argparse_typedef_bug.py

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

From report at bugs.python.org  Wed Jul 23 19:59:39 2014
From: report at bugs.python.org (Chris Bruner)
Date: Wed, 23 Jul 2014 17:59:39 +0000
Subject: [New-bugs-announce] [issue22050] argparse: read nargs > 1 options
	from file doesn't work
Message-ID: <1406138379.67.0.283419872247.issue22050@psf.upfronthosting.co.za>


New submission from Chris Bruner:

When reading options from a file, argparse should read all <nargs> values from each line. Instead, it complains of there not being enough options.

python file:
#!/usr/bin/env python
import argparse

p = argparse.ArgumentParser(description='Reproduce argparse nargs file bug',
    fromfile_prefix_chars='@')
p.add_argument('-t', '--triple', metavar='N', nargs=3)

args = p.parse_args(['@input.opts'])
print args

input.opts:
--triple 1 2 3
-t 2 2 32


Output:
bernoulli:myclu cwbrune$ argparse_nargs_file_bug.py 
usage: argparse_nargs_file_bug.py [-h] [-t N N N]
argparse_nargs_file_bug.py: error: argument -t/--triple: expected 3 argument(s)

----------
files: argparse_nargs_file_bug.py
messages: 223753
nosy: Chris.Bruner
priority: normal
severity: normal
status: open
title: argparse: read nargs > 1 options from file doesn't work
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36049/argparse_nargs_file_bug.py

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

From report at bugs.python.org  Wed Jul 23 21:57:46 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Jul 2014 19:57:46 +0000
Subject: [New-bugs-announce] [issue22051] Turtledemo: stop reloading demos
Message-ID: <1406145466.97.0.661318262793.issue22051@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

I propose to remove the following two lines with 'reload' from turtledemo.__main__.py.

from importlib import reload
...
... def loadfile(self, filename):
...
        reload(self.module)

Reloading modules each time a demo is run allows and even encourages module level code that initializes variables (other than classes) and has system side-effects. In particular, some such calls created the test problems reported in #21882. Code that needs to be run each time the required main() is called should be inside main.  Indeed, reforming the two_canvases demo (see patch for #21882) made two_canvases work properly within the demo driver.

With the demos patched, I tried them all twice after commenting out the reload. I did not notice any difference, except possibly faster response.

I already edited the help text to tell users to initialize in main().

----------
assignee: terry.reedy
keywords: patch
messages: 223771
nosy: gregorlingl, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Turtledemo: stop reloading demos
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul 23 23:03:30 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Jul 2014 21:03:30 +0000
Subject: [New-bugs-announce] [issue22052] Comparison operators called in
	reverse order for	subclasses with no override.
Message-ID: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

As reported in a StackOverflow question [1]: the order in which the special comparison methods are called seems to be contradictory to the docs [2].  In the following snippet, __eq__ is called with reversed operands first:

>>> class A:
...     def __eq__(self, other):
...         print(type(self), type(other))
...         return True
... 
>>> class B(A):
...     pass
... 
>>> A() == B()
<class '__main__.B'> <class '__main__.A'>
True

However, the docs note that:

"""If the right operand?s type is a subclass of the left operand?s type and that subclass provides the reflected method for the operation, this method will be called before the left operand?s non-reflected method. This behavior allows subclasses to override their ancestors? operations."""

... which suggests that this reversal should only happen when the subclass B *overrides* A's definition of __eq__ (and indeed that's the usual behaviour for arithmetic operations like __add__).

Looking more closely, that statement in the docs is in the 'numeric-types' section, so it's not clear that its rules should apply to the comparison operators.  But either way, some doc clarification could be useful.


[1] http://stackoverflow.com/q/24919375/270986
[2] https://docs.python.org/3.5/reference/datamodel.html#emulating-numeric-types

----------
assignee: docs at python
components: Documentation
messages: 223778
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Comparison operators called in reverse order for subclasses with no override.
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul 23 23:24:33 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Jul 2014 21:24:33 +0000
Subject: [New-bugs-announce] [issue22053] turtledemo: clean up start and
	stop, fix warning
Message-ID: <1406150673.05.0.480577347652.issue22053@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The patch adds a main function with the minimum needed to start the mainloop. It omits the 'while RUN' loop and development code for catching exceptions while running. They should never happen, and silently suppressing tracebacks is a bad idea.

The patch also deletes the unneeded sys.exit() call from _destroy. In 3.x debug builds, this call results in the following clipped warning being printed in the startup console.

    while executing
"46111032_destroy"
    (command for "WM_DELETE_WINDOW" window manager protocol) 

These no longer occur when sys.exit() is removed.

Turtledemo works fine with these changes.

----------
assignee: terry.reedy
files: turdemo_start_stop.diff
keywords: patch
messages: 223780
nosy: terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: turtledemo: clean up start and stop, fix warning
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36051/turdemo_start_stop.diff

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

From report at bugs.python.org  Wed Jul 23 23:30:14 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jul 2014 21:30:14 +0000
Subject: [New-bugs-announce] [issue22054] Add os.get_blocking() and
	os.set_blocking() functions
Message-ID: <1406151014.25.0.918263340821.issue22054@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Antoine suggested me to add these functions in the issue #22042.

Here is a patch to implement these functions and use them in various places.

----------
files: os_blocking.patch
keywords: patch
messages: 223782
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Add os.get_blocking() and os.set_blocking() functions
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36052/os_blocking.patch

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

From report at bugs.python.org  Thu Jul 24 08:29:17 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Thu, 24 Jul 2014 06:29:17 +0000
Subject: [New-bugs-announce] [issue22055] Incomplete sentence in asyncio
	BaseEventLoop doc
Message-ID: <1406183357.8.0.942140002589.issue22055@psf.upfronthosting.co.za>


Changes by Saimadhav Heblikar <saimadhavheblikar at gmail.com>:


----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio-eventloop-doc-incomplete-sent.diff
keywords: patch
nosy: docs at python, gvanrossum, haypo, sahutd, yselivanov
priority: normal
severity: normal
status: open
title: Incomplete sentence in asyncio BaseEventLoop doc
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36060/asyncio-eventloop-doc-incomplete-sent.diff

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

From report at bugs.python.org  Thu Jul 24 15:59:49 2014
From: report at bugs.python.org (Alon Mishne)
Date: Thu, 24 Jul 2014 13:59:49 +0000
Subject: [New-bugs-announce] [issue22057] The doc say all globals are copied
	on eval(), but only __builtins__ is copied
Message-ID: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>


New submission from Alon Mishne:

According to the documentation of eval():

> If the globals dictionary is present and lacks '__builtins__', the current globals are copied into globals before expression is parsed.

However in practice only the __builtins__ items are copied, see:

http://hg.python.org/cpython/file/2.7/Python/bltinmodule.c#l655

See http://stackoverflow.com/q/24934908/242762

----------
assignee: docs at python
components: Documentation
messages: 223837
nosy: amishne, docs at python
priority: normal
severity: normal
status: open
title: The doc say all globals are copied on eval(), but only __builtins__ is copied
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 24 16:41:32 2014
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 24 Jul 2014 14:41:32 +0000
Subject: [New-bugs-announce] [issue22058] datetime.datetime() should accept
	a datetime.date as	constructor
Message-ID: <1406212892.92.0.452471397422.issue22058@psf.upfronthosting.co.za>


New submission from Facundo Batista:

Currently (tested on py3.4):

>>> from datetime import datetime, date
>>> d = datetime.now()
>>> date(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required (got type datetime.datetime)

IMO, it's like doing int(float), a truncation of some info. For example, this is what I want to happen:

>>> d
datetime.datetime(2014, 7, 24, 11, 38, 44, 966613)
>>> date(d)
datetime.date(2014, 7, 24)

----------
messages: 223840
nosy: facundobatista
priority: normal
severity: normal
status: open
title: datetime.datetime() should accept a datetime.date as constructor
versions: Python 3.5

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

From report at bugs.python.org  Thu Jul 24 16:46:50 2014
From: report at bugs.python.org (Hoxily)
Date: Thu, 24 Jul 2014 14:46:50 +0000
Subject: [New-bugs-announce] [issue22059] incorrect type conversion from str
	to bytes in asynchat	module in asynchat.py
Message-ID: <1406213210.3.0.145864066025.issue22059@psf.upfronthosting.co.za>


New submission from Hoxily:

refer to  http://hg.python.org/cpython/file/5d70ac83d104/Lib/asynchat.py#l123

----------
components: Library (Lib)
hgrepos: 265
messages: 223842
nosy: brett.cannon, hoxily, tim.peters
priority: normal
severity: normal
status: open
title: incorrect type conversion from str to bytes in asynchat module in asynchat.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 24 22:32:05 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 24 Jul 2014 20:32:05 +0000
Subject: [New-bugs-announce] [issue22060] Clean up ctypes.test,
	use unittest test discovery
Message-ID: <1406233925.87.0.452498118491.issue22060@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Attached is a patch that aims to clean up the ctypes tests a bit, namely by removing the custom resource management (which conflicts with regrtest), the custom test discovery (which is better left to unittest), and the custom test running (which is better covered by unittest and regrtest).  The one thing I'm not entirely confident about removing is the custom refleak testing, but it does not seem to work correctly in 3.x anyway (though in 2.7, the custom refleak hunter reports "leaks" that the regrtest refleak hunter does not).

There were only a few uses of the custom resource management, all of which were replaced or removed.  test_SEH in test_win32 used "requires('SEH')", but that test should now be sufficiently guarded with unittest skip decorators (only trying the test on Windows, with Python built in Release configuration by MSVC).  test_PyLong_Long in test_python_api used "requires('refcount')", but that should be covered by the @support.refcount_test decorator (added long after the 'requires' call).  Two instances of "is_resource_enabled('printing')" were replaced by "if test.support.verbose".

The same number of tests run (all successfully) on Windows, I have not yet tested on any other platforms.

----------
components: Tests, ctypes
files: ctypes.test-cleanup.diff
keywords: patch
messages: 223891
nosy: amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Clean up ctypes.test, use unittest test discovery
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36073/ctypes.test-cleanup.diff

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

From report at bugs.python.org  Thu Jul 24 23:43:23 2014
From: report at bugs.python.org (Lita Cho)
Date: Thu, 24 Jul 2014 21:43:23 +0000
Subject: [New-bugs-announce] [issue22061] turtledemo doesn't launch due to
	changes in tkinter
Message-ID: <1406238203.8.0.482945967482.issue22061@psf.upfronthosting.co.za>


New submission from Lita Cho:

I updated my source code, and it looks like turtledemo doesn't launch anymore. I get the following error:

Traceback (most recent call last):
  File "/Users/litacho/Development/cpython/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/Users/litacho/Development/cpython/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/litacho/Development/cpython/Lib/turtledemo/__main__.py", line 328, in <module>
    main()
  File "/Users/litacho/Development/cpython/Lib/turtledemo/__main__.py", line 324, in main
    demo = DemoWindow()
  File "/Users/litacho/Development/cpython/Lib/turtledemo/__main__.py", line 124, in __init__
    self.mBar.tk_menuBar(self.ExamplesBtn, self.OptionsBtn)
AttributeError: 'Frame' object has no attribute 'tk_menuBar'

I dug into it and it looks like tk_menuBar was removed due to a fix in issue4350. If tk_menuBar needs to be removed, what method does turtledemo need to call instead to propagate its panels?

----------
messages: 223899
nosy: Lita.Cho, jesstess, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: turtledemo doesn't launch due to changes in tkinter
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 25 00:11:02 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jul 2014 22:11:02 +0000
Subject: [New-bugs-announce] [issue22062] Fix pathlib.Path.(r)glob doc
	glitches.
Message-ID: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

1. The pattern argument for .(r)glob must be relative. I think the docstrings and doc should say so. /pattern/relative pattern/

For rglob: '''This is like calling glob() with ?**? added in front of the given pattern:'''

2. Currently "glob()" links to the glob module, which does not recognize '**'. It should link to back up to the Pathlib.glob entry, where the effect of '**' is defined. (I don't currently know the markup for that.)

3. I interpret '''?**? added in front of the given pattern:''' to mean '**' + pattern, so that '*.py' would become '***.py'. It actually becomes the equivalent of '**/*.p'. So I think '**' should be either '**/' or 'a "**" component'.

----------
messages: 223902
nosy: pitrou, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix pathlib.Path.(r)glob doc glitches.
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 25 01:24:17 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jul 2014 23:24:17 +0000
Subject: [New-bugs-announce] [issue22063] asyncio: sock_xxx() methods of
	event loops should make	the socket non-blocking
Message-ID: <1406244257.84.0.711370901169.issue22063@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The sock_xxx() methods of asyncio.BaseEventLoop don't make the socket non-blocking, and the documentation doesn't require that sockets are already set to non-blocking mode.

It looks like a bug, at least in the documentation.

If these methods should make the sockets non-blocking, should they also restore the previous timeout (blocking mode) at exit? ssl.SSLSocket.do_handshake(block=True) makes temporary the socket blocking, and then restore the previous timeout.

----------
components: asyncio
messages: 223909
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: sock_xxx() methods of event loops should make the socket non-blocking
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 25 08:20:22 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Jul 2014 06:20:22 +0000
Subject: [New-bugs-announce] [issue22064] Misleading message from 2to3 when
	skipping optional	fixers
Message-ID: <1406269222.0.0.185162448191.issue22064@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

>From https://stackoverflow.com/questions/5499897/converting-selenium-py-to-python-3-by-2to3, 2to3 prints the following messages when run:

===============
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
===============

That message is rather misleading - those four are the *optional* fixers that are only run when selected explicitly. Unlike the other fixers, they're essentially the *opposite* of implicit :)

Given that limiting the fixes to a specific subset (e.g. "-f dict") silences all such messages, and explicitly excluding an actual implicit fixer (e.g. "-x dict") doesn't generate a warning, I suggest the simplest fix is to just change the message to instead say "Skipping optional fixer".

----------
keywords: easy
messages: 223919
nosy: ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Misleading message from 2to3 when skipping optional fixers
type: behavior

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

From report at bugs.python.org  Fri Jul 25 09:45:42 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jul 2014 07:45:42 +0000
Subject: [New-bugs-announce] [issue22065] Update turtledemo menu creation
Message-ID: <1406274342.14.0.580030811774.issue22065@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

On #22061, Serhiy Storchaka posted turtledemo_menu.patch, which is unrelated to that issue. Issues in that patch.
* It mistakenly includes the tkinter_restore_empty_methods.patch that does belongs to 22061.
* It will not apply any more, especially to 3.4 as it is now.
* Removing the gridding of the Menu seems like a mistake, or else the rest of the grid code should be revised.  I will test this.

Serhiy claims the patch "replaces obsolete and non-working menu creation code by modernized code. Now menu should be correctly displayed on MacOS."

'Obsolete' is correct' The current code uses Menubutton, "obsolete since Tk8.0". Updating, even for 2.7, would probably be a good idea.

As for 'non-working': the current code works on Windows, but I have no idea on Linux or Mac. Can either of you comment?  I certainly would want an updated patch tested on more than Windows.

----------
assignee: terry.reedy
messages: 223927
nosy: Lita.Cho, ned.deily, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update turtledemo menu creation
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 25 15:52:23 2014
From: report at bugs.python.org (juj)
Date: Fri, 25 Jul 2014 13:52:23 +0000
Subject: [New-bugs-announce] [issue22066] subprocess.communicate() does not
	receive full output	from the called process.
Message-ID: <1406296343.93.0.498702649636.issue22066@psf.upfronthosting.co.za>


New submission from juj:

When Python 2.7 executes a Node .js application that prints to stdout and subsequently exits, Python does not capture full output printed by that application.

Steps to repro:
1. Download and unzip http://clb.demon.fi/bugs/python_proc_bug.zip
2. Run run_test.bat

Observed result: The .bat script prints:

Executing 'node jsfile.js' directly from command line. The js file outputs:
Line 1
Line 2

Executing 'jsfile.js' via a python script that calls 'node jsfile.js'. Now the js file outputs:
Line 1

Expected result: The second run via invoking from python should also print "Line 2".

Tested on Python v2.7.8 64-bit and Node v0.10.28 on Windows 7 64-bit.

----------
components: Library (Lib)
messages: 223950
nosy: juj
priority: normal
severity: normal
status: open
title: subprocess.communicate() does not receive full output from the called process.
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 25 17:05:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Jul 2014 15:05:06 +0000
Subject: [New-bugs-announce] [issue22067] time_test fails after strptime()
Message-ID: <1406300706.97.0.297116152609.issue22067@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

time_test fails when running after any test which uses strptime().

The bug can be easily reproduced by running test_time twice:

$ TZ=Europe/Kiev ./python -m test.regrtest -ugui -v test_time test_time
...
======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-2.7/Lib/test/test_time.py", line 120, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'MSK' input.

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

All works on 3.x and with TZ=UTC.

May be this is related to issue13309.

----------
components: Extension Modules, Tests
messages: 223955
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: time_test fails after strptime()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 25 17:34:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Jul 2014 15:34:59 +0000
Subject: [New-bugs-announce] [issue22068] test_gc fails after test_idle
Message-ID: <1406302499.67.0.809982435329.issue22068@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -ugui -v test_idle test_gc
...
======================================================================
FAIL: test_saveall (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-2.7/Lib/test/test_gc.py", line 200, in test_saveall
    self.assertEqual(gc.garbage, [])
AssertionError: Lists differ: [<Tkinter.StringVar instance a... != []

First list contains 24 additional elements.
First extra element 0:
PY_VAR0

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

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

----------
components: IDLE, Tests
messages: 223958
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: test_gc fails after test_idle
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 25 18:43:43 2014
From: report at bugs.python.org (Akira Li)
Date: Fri, 25 Jul 2014 16:43:43 +0000
Subject: [New-bugs-announce] [issue22069] TextIOWrapper(newline="\n",
	line_buffering=True) mistakenly treat \r as a newline
Message-ID: <1406306623.81.0.633771356606.issue22069@psf.upfronthosting.co.za>


New submission from Akira Li:

TextIOWrapper(b, newline="\n", line_buffering=True) object calls flush() 
while writing "\r". See test_line_buffering() method in 
Lib/test/test_io.py:2114

The documentation says [1]:

> If line_buffering is True, flush() is implied when a call to write contains
> a newline character.

i.e., writing \r shouldn't force flush() if newline="\n"

[1] https://docs.python.org/3.4/library/io.html#io.TextIOWrapper

----------
components: IO
messages: 223965
nosy: akira
priority: normal
severity: normal
status: open
title: TextIOWrapper(newline="\n", line_buffering=True) mistakenly treat \r as a newline
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 25 18:46:19 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Jul 2014 16:46:19 +0000
Subject: [New-bugs-announce] [issue22070] Use the _functools module to speed
	up	functools.total_ordering
Message-ID: <1406306779.79.0.561653436369.issue22070@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Getting functools.total_ordering to handle NotImplemented correctly in issue 10042 came at the cost of slowing it down dramatically, as the simple use of normal operator syntax had to be replaced by explicit method calls. It also introduced the quirk of going through "self.method" lookup rather than "type(self).method" slot lookup (I didn't actually notice that part during the patch review).

It would be nice if we could regain some of that lost speed, and the most readily available approach would seem to be making use of the _functools accelerator module to move the slot dispatch down into C where it can compete with the eval loop based implementation used prior to 3.4.

Raymond, I recall you were doing some speed comparisons between writing out the methods manually and using functools.total_ordering, do you have a handy micro-benchmark readily available?

----------
messages: 223967
nosy: ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Use the _functools module to speed up functools.total_ordering
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Fri Jul 25 18:51:38 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Fri, 25 Jul 2014 16:51:38 +0000
Subject: [New-bugs-announce] [issue22071] Remove long-time deprecated
	attributes from smtpd
Message-ID: <1406307098.0.0.954478358175.issue22071@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

I made a patch removing deprecated attributes from smtpd (as suggested by r.david.murray).

----------
components: Library (Lib)
files: smtpd_remove_deprecated_attrs.patch
keywords: patch
messages: 223969
nosy: jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Remove long-time deprecated attributes from smtpd
versions: Python 3.5
Added file: http://bugs.python.org/file36090/smtpd_remove_deprecated_attrs.patch

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

From report at bugs.python.org  Fri Jul 25 20:27:17 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 25 Jul 2014 18:27:17 +0000
Subject: [New-bugs-announce] [issue22072] Fix typos in SSL's documentation
Message-ID: <1406312837.87.0.669904436457.issue22072@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Attached patch fixes a pair of typos.

----------
assignee: docs at python
components: Documentation
files: ssl-docs.diff
keywords: easy, needs review, patch
messages: 223982
nosy: alex, docs at python
priority: normal
severity: normal
status: open
title: Fix typos in SSL's documentation
versions: Python 3.5
Added file: http://bugs.python.org/file36091/ssl-docs.diff

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

From report at bugs.python.org  Fri Jul 25 20:40:10 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 25 Jul 2014 18:40:10 +0000
Subject: [New-bugs-announce] [issue22073] Reference links in PEP466 are
	broken
Message-ID: <1406313610.77.0.0816993092292.issue22073@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Specifically, the links in the "Acknowledgements" section http://legacy.python.org/dev/peps/pep-0466/#acknowledgements

----------
messages: 223985
nosy: alex, ncoghlan
priority: normal
severity: normal
status: open
title: Reference links in PEP466 are broken

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

From report at bugs.python.org  Sat Jul 26 01:08:25 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 25 Jul 2014 23:08:25 +0000
Subject: [New-bugs-announce] [issue22074] Lib/test/make_ssl_certs.py fails
	with NameError
Message-ID: <1406329705.02.0.672506438124.issue22074@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This is on default:


$ python3 Lib/test/make_ssl_certs.py
creating cert for localhost
Generating a 1024 bit RSA private key
.++++++
....................................................++++++
writing new private key to '/var/folders/fm/57qdjdrx6gzgcq1zlym0xwfc0000gn/T/tmpbfrqx7mo'
-----
password protecting ssl_key.pem in ssl_key.passwd.pem
writing RSA key
writing RSA key
Traceback (most recent call last):
  File "Lib/test/make_ssl_certs.py", line 158, in <module>
    make_ca()
  File "Lib/test/make_ssl_certs.py", line 118, in make_ca
    r.write("00")
NameError: name 'r' is not defined


I can't see anything that ought to be assigning `r`, perhaps it's supposed to be `f`?

----------
components: Library (Lib), Tests
messages: 224011
nosy: alex
priority: normal
severity: normal
status: open
title: Lib/test/make_ssl_certs.py fails with NameError
versions: Python 3.5

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

From report at bugs.python.org  Sat Jul 26 04:00:11 2014
From: report at bugs.python.org (wilson campusano)
Date: Sat, 26 Jul 2014 02:00:11 +0000
Subject: [New-bugs-announce] [issue22075] Lambda,
	enumerate and list comprehensins crash
Message-ID: <1406340011.09.0.682256920065.issue22075@psf.upfronthosting.co.za>


New submission from wilson campusano:

SO: Ubuntu 14.04

When i run this code my pc crash

----------
components: Interpreter Core
files: test_c.py
messages: 224015
nosy: wilsoncampusano
priority: normal
severity: normal
status: open
title: Lambda, enumerate and list comprehensins crash
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file36097/test_c.py

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

From report at bugs.python.org  Sat Jul 26 10:39:07 2014
From: report at bugs.python.org (Martin Matusiak)
Date: Sat, 26 Jul 2014 08:39:07 +0000
Subject: [New-bugs-announce] [issue22076] csv module bad grammar in
	exception message
Message-ID: <1406363947.96.0.930759215871.issue22076@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

The csv module has an exception message with bad grammar:

- delimiter" must be an 1-character string

"an" should be "a"

----------
components: Library (Lib)
files: csv_grammar_fix.diff
keywords: patch
messages: 224028
nosy: haypo, numerodix, serhiy.storchaka
priority: normal
severity: normal
status: open
title: csv module bad grammar in exception message
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36103/csv_grammar_fix.diff

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

From report at bugs.python.org  Sat Jul 26 10:52:10 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 26 Jul 2014 08:52:10 +0000
Subject: [New-bugs-announce] [issue22077] Improve the error message for
	various sequences
Message-ID: <1406364730.89.0.733726269195.issue22077@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

For a couple of sequences (bytes, list, tuple, bytearray), the error when using an invalid sequence index is misleading, because it says that only integers are allowed, while slices are allowed too.

>>> a = []
>>> a['python']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str
>>>

For instance, here's how range does it:

>>> range(1)['a']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: range indices must be integers or slices, not str


The attached patch improves these error messages.

----------
files: proper_error.patch
keywords: patch
messages: 224029
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Improve the error message for various sequences
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36104/proper_error.patch

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

From report at bugs.python.org  Sat Jul 26 13:20:54 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 26 Jul 2014 11:20:54 +0000
Subject: [New-bugs-announce] [issue22078] io.BufferedReader hides
	ResourceWarnings when garbage	collected
Message-ID: <1406373654.18.0.791588376314.issue22078@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Given the following example, Python 3.5 doesn't emit any resource warning:

import io, gc
f = open("a")
bufio = io.BufferedReader(f)
gc.collect()


Here's a small patch that enables this.

----------
components: IO
files: buffered_io_resource_warning.patch
keywords: patch
messages: 224040
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: io.BufferedReader hides ResourceWarnings when garbage collected
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file36107/buffered_io_resource_warning.patch

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

From report at bugs.python.org  Sat Jul 26 14:36:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Jul 2014 12:36:39 +0000
Subject: [New-bugs-announce] [issue22079] Ensure in PyType_Ready() that base
	class of static type	is static
Message-ID: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It would be good if PyType_Ready() will check that base class of static type is static.

----------
components: Interpreter Core
messages: 224049
nosy: alex, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Ensure in PyType_Ready() that base class of static type is static
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jul 26 14:39:33 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 26 Jul 2014 12:39:33 +0000
Subject: [New-bugs-announce] [issue22080] Add windows_helper module helper
Message-ID: <1406378373.46.0.337360125553.issue22080@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hi. This patch adds a new test helper module, initially added in issue21518, for controlling various aspects on Windows platform, like acquiring / releasing privileges etc. At the same time, it contains a modification in test.support.skip_unless_symlink, so that it tries to acquire the privilege, failing otherwise. The only downside is that acquiring SeCreateSymbolicLinkPrivilege is only possible for admins and it seems to be that they have the privilege by default. On the other hand, for SeBackupPrivilege must be explicitly acquired, so the purpose of this module isn't redundant.

The part of acquiring a privilege using ctypes is based on similar code by Jason R. Coombs.

----------
components: Tests
files: windows_helper.patch
keywords: patch
messages: 224050
nosy: Claudiu.Popa, zach.ware
priority: normal
severity: normal
status: open
title: Add windows_helper module helper
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36108/windows_helper.patch

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

From report at bugs.python.org  Sat Jul 26 15:06:02 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Jul 2014 13:06:02 +0000
Subject: [New-bugs-announce] [issue22081] Backport repr(socket.socket) from
	Python 3.5 to Python	2.7
Message-ID: <1406379962.85.0.838709000205.issue22081@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, the C module _socket has an useful representation of socket: it gives the file descriptor, family, type, etc. The Python socket module only shows the memory address. Example:

$ ./python -c 'import _socket; s=_socket.socket(); print(repr(s));'
<socket object, fd=3, family=2, type=1, protocol=0>

$ ./python -c 'import socket; s=socket.socket(); print(repr(s));'
<socket._socketobject object at 0x7fad1fdcbba0>

I propose to backport repr(socket.socket) from Python 3.5 to Python 2.7. With the patch, the Python socket even contains *more* information than the C module (laddr and raddr). Example with the patch applied:

$ ./python -c 'import socket; s=socket.socket(); print(repr(s));'
<socket._socketobject fd=3, family=2, type=1, proto=0, laddr=('0.0.0.0', 0)>

In Python 2.7, when a socket is closed, it drops the underlying C _socket object. So it's not possible to provide a better representation than:

$ ./python -c 'import socket; s=socket.socket(); s.close(); print(repr(s));'
<socket._socketobject[closed]>

I don't want to change the design of the Python module, Python 2.7 is very stable. I don't want to take the risk of breaking anything.

----------
files: socket_repr.patch
keywords: patch
messages: 224053
nosy: haypo
priority: normal
severity: normal
status: open
title: Backport repr(socket.socket) from Python 3.5 to Python 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file36109/socket_repr.patch

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

From report at bugs.python.org  Sat Jul 26 16:42:49 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 26 Jul 2014 14:42:49 +0000
Subject: [New-bugs-announce] [issue22082] Clear interned strings listed in
	slotdefs
Message-ID: <1406385769.4.0.261949014577.issue22082@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

I'm chasing objects left at shutdown. I found that the string objects in slotdefs are still around at the end; this patch removes them.

----------
files: type.diff
keywords: patch
messages: 224058
nosy: loewis
priority: normal
severity: normal
status: open
title: Clear interned strings listed in slotdefs
Added file: http://bugs.python.org/file36111/type.diff

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

From report at bugs.python.org  Sat Jul 26 17:06:23 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sat, 26 Jul 2014 15:06:23 +0000
Subject: [New-bugs-announce] [issue22083] Refactor PyShell's breakpoint
	related methods
Message-ID: <1406387183.56.0.280615170045.issue22083@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

This refactoring is required to enable setting/clearing breakpoints, using linenumbering( whether using a Canvas implementation or a Text implementation http://bugs.python.org/issue17535)
The patch ensures consistency between the set_breakpoint(_here) and
clear_breakpoint(_here) methods. The clear_breakpoint_here, which is not present currently has been added.
No functionality has been added or removed, so I think it should be safe to go forward.

----------
components: IDLE
files: pyshell-breakpoint-refactor.diff
keywords: patch
messages: 224062
nosy: jesstess, sahutd, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: Refactor PyShell's breakpoint related methods
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36112/pyshell-breakpoint-refactor.diff

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

From report at bugs.python.org  Sat Jul 26 17:52:21 2014
From: report at bugs.python.org (Aaron Brady)
Date: Sat, 26 Jul 2014 15:52:21 +0000
Subject: [New-bugs-announce] [issue22084] Mutating while iterating
Message-ID: <1406389941.41.0.168391014696.issue22084@psf.upfronthosting.co.za>


New submission from Aaron Brady:

Hi, I asked about the inconsistency of the "RuntimeError" being raised when mutating a container while iterating over it here [1], "set and dict iteration" on Aug 16, 2012.

[1] http://www.gossamer-threads.com/lists/python/python/1004659

I posted a patch on the ML but never submitted it.  People's reaction seemed ambivalent.  Now I have an idea for a different implementation.  I'd like to take another shot at it.

It's one of the worst silent errors, since there's an error in the *iterator* when we call a *set* method.  We're going to add something to make it safer, at least in the sense of getting a clear failure, if the programmer does something that's always been ill-advised.

We have a number of options for the implementation.  We still have the option to introduce "IterationError", possibly a subclass of "RuntimeError".  These options are still applicable:

1) Collection of iterators
. Invalidate all "open" iterators on mutating
. a) Linked list
.. i) Uncounted references
.. ii) Counted references
.. iii) Weak references
. b) Weak set
2) Version index / timestamp / "memo"
. Iterators check whether the container has been mutated
    since they were created
. a) No overflow - Python longs
.. i) Reset index if no iterators left
. b) Overflow - C ints / shorts (silent error)
3) Iterator count
. Raise exception on mutation, not iteration

The new option is:

2d) Use a dedicated empty *object* for a timestamp or "memo".  A new memo is created on every mutation.  Before advancing, the iterator checks whether the current memo is a different object than it was when it was created.

Costs: The existing silent error is fairly rare.  The container gains a pointer to its current memo.  The iterator loses the cached length but gains a pointer to a memo.  The memos are blank objects: a "Py ssize t" and a pointer with certain flags at time of writing.  Speed is the same: comparing the lengths is replaced with comparing the memos.

Some caveats: The memory manager is used to obtain perpetually unique IDs.  A unique algorithm could be used instead of the memory manager, though the memo needs to contain a reference count more or less regardless.  There can at most be one memo per iterator.  The approach is outlined in pseudocode here [2]. Implementation could be optimized slightly by only creating new memos if iterators have been opened, shown here [3].

[2] http://home.comcast.net/~castironpi-misc/irc-0168%20mutating%20while%20iterating%20markup.html

[3] http://home.comcast.net/~castironpi-misc/irc-0168%20mutating%20while%20iterating%202%20markup.html

----------
components: Library (Lib)
messages: 224071
nosy: castironpi
priority: normal
severity: normal
status: open
title: Mutating while iterating
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jul 26 19:33:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Jul 2014 17:33:27 +0000
Subject: [New-bugs-announce] [issue22085] Update deprecated Tcl commands in
	Tkinter
Message-ID: <1406396007.9.0.890469508876.issue22085@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Command used to monitor Tcl variable access ("trace variable", "trace vdelete", "trace vinfo") are deprecated and will likely be removed in a future version of Tcl. Proposed patch replaces them to modern equivalents.

The problem is that new commands was introduced in Tcl 8.4, but minimal supported by Tkinter version is 8.3. This patch should wait until dropping support of Tcl 8.3.

----------
components: Tkinter
messages: 224080
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Update deprecated Tcl commands in Tkinter
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Jul 26 19:34:20 2014
From: report at bugs.python.org (Erik Andersen)
Date: Sat, 26 Jul 2014 17:34:20 +0000
Subject: [New-bugs-announce] [issue22086] Tab indent no longer works in
	interpreter
Message-ID: <1406396060.4.0.777513387491.issue22086@psf.upfronthosting.co.za>


New submission from Erik Andersen:

Please see http://bugs.python.org/issue5845, especially the last two comments: http://bugs.python.org/issue5845#msg215784, which requested that a new bug report be opened for this issue.

To summarize, the previous bug was to enable tab completion in the interpreter. There was discussion and it was figured out that it could be arranged that tab indentation and completion could work at the same time. (If you are at the start of a line, possibly a "... " prompt line, tab should indent. If you are to the right of any non-whitespace character, then you should tab complete).

>From the other bug:

"This issue [tab indent] should have gone back to being a release blocker after the alpha release to fix the tab-as-indent issue, but obviously that didn't happen (I forgot about it myself).  Please open a new issue requesting a fix for this bug (that tab doesn't work as indent at the ... prompt), referencing the discussion in this issue."

----------
components: Library (Lib)
messages: 224081
nosy: Azendale
priority: normal
severity: normal
status: open
title: Tab indent no longer works in interpreter
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jul 26 20:01:10 2014
From: report at bugs.python.org (Dan O'Reilly)
Date: Sat, 26 Jul 2014 18:01:10 +0000
Subject: [New-bugs-announce] [issue22087] _UnixDefaultEventLoop policy
	should either create a new	loop or explicilty fail when
	get_event_loop() is called from a	multiprocessing child process
Message-ID: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za>


New submission from Dan O'Reilly:

On non-Windows platforms, if a user attempts to use asyncio.get_event_loop() in a child process created by multiprocessing.Process using the fork context, and an asyncio event loop is also being used in the main process, the same _UnixSelectorEventLoop object will be used by both processes. This, of course, won't work properly; the child will raise a "RuntimeError: Event loop is running" exception as soon as it tries using the loop object.

However, this may or may not actually make it back to the parent: If the parent is expecting to get items from a queue from that child publishes to, rather than yielding from it immediately, the program will deadlock. Even if the child is yielded from, it may not be immediately obvious why "Event loop is running" was raised, and the behavior is inconsistent with the behavior if a method other than os.fork is used to create the child process, since the child will get a new event loop in that case.

So, it'd be better if _UnixDefaultEventLoopPolicy detected that get_event_loop was being called in a child process, and either 

1) Created a new loop for the child (this would make the behavior appear consistent no matter what platform/method for launching children is used)
2) Raised an exception stating that no default event loop exists for this process, similar to the assert used for threads currently.

I've attached a test script that demonstrates the different between forked/spawned processes, and a patch that implements #1 above.

----------
components: asyncio
files: handle_mp_unix.diff
keywords: patch
messages: 224082
nosy: dan.oreilly, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: _UnixDefaultEventLoop policy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36116/handle_mp_unix.diff

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

From report at bugs.python.org  Sun Jul 27 00:44:09 2014
From: report at bugs.python.org (Julian Berman)
Date: Sat, 26 Jul 2014 22:44:09 +0000
Subject: [New-bugs-announce] [issue22088] base64 module still ignores
	non-alphabet characters
Message-ID: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za>


New submission from Julian Berman:

The base64 module documentation claims that decode methods raise exceptions for non-base64 input, but they do not.

There was a patch for Py3 done in issue1466065, but the documentation was not updated for Py2. I have not read that ticket carefully enough to be able to tell what the expected resolution was for Py2 (fixing the bug or just updating the docs).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 224089
nosy: Julian, docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: base64 module still ignores non-alphabet characters
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 27 08:06:34 2014
From: report at bugs.python.org (Roy Wellington)
Date: Sun, 27 Jul 2014 06:06:34 +0000
Subject: [New-bugs-announce] [issue22089] collections.MutableSet does not
	provide update method
Message-ID: <1406441194.56.0.0212102514052.issue22089@psf.upfronthosting.co.za>


New submission from Roy Wellington:

Inheriting from collections.MutableSet mixes in several methods, however, it does not mix in a .update method. This can cause a variety of confusion if you expect a MutableSet to act like a set. Moreover, MutableMapping does provide a .update method, which makes me think this is a bug.

I've attached a file that creates a bare-bones MutableSet, and shows the difference.

Is this a bug, or is there some reason that MutableSet doesn't provide an update method?

----------
components: Library (Lib)
files: ms.py
messages: 224105
nosy: roy.wellington
priority: normal
severity: normal
status: open
title: collections.MutableSet does not provide update method
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file36125/ms.py

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

From report at bugs.python.org  Sun Jul 27 12:08:43 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jul 2014 10:08:43 +0000
Subject: [New-bugs-announce] [issue22090] Decimal and float formatting treat
	'%' differently for	infinities and nans.
Message-ID: <1406455723.52.0.997283705437.issue22090@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

There's a minor inconsistency between Decimal and float formatting for the `%` format type when handling infinities and nans:

>>> from decimal import Decimal
>>> format(float('inf'), '.2%')  # includes trailing '%'
'inf%'
>>> format(Decimal('inf'), '.2%')  # no trailing '%'
'Infinity'

I think the Decimal result should have a '%' on it.

----------
messages: 224114
nosy: eric.smith, mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Decimal and float formatting treat '%' differently for infinities and nans.
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Jul 27 13:32:00 2014
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 27 Jul 2014 11:32:00 +0000
Subject: [New-bugs-announce] [issue22091] __debug__ in compile(optimize=1)
Message-ID: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za>


New submission from Armin Rigo:

The documentation of the built-in compile() function is not 100% clear but I think it says that giving the "optimize=1" argument turns "__debug__" to false in the compiled code ( https://docs.python.org/3.5/library/functions.html?highlight=compile#compile ).  It doesn't work this way in practice, though:

    python3.5
    >>> exec(compile("print(__debug__)", "exec", "exec", optimize=1))
    True

I'd recommend to fix either the documentation or the source code.

----------
messages: 224119
nosy: arigo
priority: normal
severity: normal
status: open
title: __debug__ in compile(optimize=1)

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

From report at bugs.python.org  Sun Jul 27 16:50:45 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 27 Jul 2014 14:50:45 +0000
Subject: [New-bugs-announce] [issue22092] Executing some tests inside
	Lib/unittest/test	individually throws Error
Message-ID: <1406472645.11.0.803987239444.issue22092@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

For examples:

$ ./python Lib/unittest/test/test_runner.py 
Traceback (most recent call last):
  File "Lib/unittest/test/test_runner.py", line 10, in <module>
    from .support import LoggingResult, ResultWithNoStartTestRunStopTestRun
SystemError: Parent module '' not loaded, cannot perform relative import

$ ./python Lib/unittest/test/test_program.py 
..................E
======================================================================
ERROR: test_discovery_from_dotted_path (__main__.Test_TestProgram)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/unittest/test/test_program.py", line 15, in test_discovery_from_dotted_path
    expectedPath = os.path.abspath(os.path.dirname(unittest.test.__file__))
AttributeError: module 'unittest' has no attribute 'test'

----------------------------------------------------------------------
Ran 19 tests in 0.331s

FAILED (errors=1)


Here is the patch.

----------
components: Tests
files: fix_test_inside_unittest.patch
keywords: patch
messages: 224136
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Executing some tests inside Lib/unittest/test individually throws Error
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36132/fix_test_inside_unittest.patch

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

From report at bugs.python.org  Mon Jul 28 06:35:02 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 28 Jul 2014 04:35:02 +0000
Subject: [New-bugs-announce] [issue22093] Compiling python on OS X gives
	warning about compact	unwind
Message-ID: <1406522102.91.0.00091279814431.issue22093@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

OS X version 10.9.4.

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix

This is the warning:

...
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/_ctypes.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/callbacks.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/callproc.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/stgdict.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/cfield.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/malloc_closure.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/darwin/dlfcn_simple.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/ffi.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/x86/darwin64.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/x86/x86-darwin.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/x86/x86-ffi64.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin_closure.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.o build/temp.macosx-10.9-x86_64-3.5-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.o -L/usr/local/lib -o build/lib.macosx-10.9-x86_64-3.5-pydebug/_ctypes.so
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame

Python build finished successfully!

----------
messages: 224151
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Compiling python on OS X gives warning about compact unwind
versions: Python 3.5

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

From report at bugs.python.org  Mon Jul 28 12:29:20 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 28 Jul 2014 10:29:20 +0000
Subject: [New-bugs-announce] [issue22094] test_ossaudiodev fails
	unnecessarily
Message-ID: <1406543360.46.0.562125681265.issue22094@psf.upfronthosting.co.za>


New submission from Akira Li:

$ ./python -mtest -uaudio test_ossaudiodev
[1/1] test_ossaudiodev
test test_ossaudiodev failed -- Traceback (most recent call last):
  File "./Lib/test/test_ossaudiodev.py", line 148, in test_playback
    self.play_sound_file(*sound_info)
  File "./Lib/test/test_ossaudiodev.py", line 89, in play_sound_file
    (elapsed_time, expected_time))
AssertionError: False is not true : elapsed time (0.0590214729309082) > 10% off of expected time (3.5127309036445333)

1 test failed:
    test_ossaudiodev

The failure is caused by dsp.write(data) that doesn't write all data
on my machine.  If it is replaced with dsp.writeall(data) then the test
passes.

The docs [1] say that dsp.write() should write all data by default:

  oss_audio_device.write(data)
  Write the Python string data to the audio device and return the
  number of bytes written. If the audio device is in blocking mode
  (the default), the entire string is always written

[1] https://docs.python.org/3.4/library/ossaudiodev.html


The comments in Modules/ossaudiodev.c suggest that dsp.write(data) should
write *all* data unless dsp.nonblock() is called:

    /* Open with O_NONBLOCK to avoid hanging on devices that only allow
       one open at a time.  This does *not* affect later I/O; OSS
       provides a special ioctl() for non-blocking read/write, which is
       exposed via oss_nonblock() below. */
    fd = _Py_open(devicename, imode|O_NONBLOCK);
    ...
    /* And (try to) put it back in blocking mode so we get the
       expected write() semantics. */
    if (fcntl(fd, F_SETFL, 0) == -1) {
        close(fd);
        PyErr_SetFromErrnoWithFilename(PyExc_IOError, devicename);
        return NULL;
    }

----------
components: Tests
messages: 224159
nosy: akira
priority: normal
severity: normal
status: open
title: test_ossaudiodev fails unnecessarily
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jul 28 20:09:43 2014
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 28 Jul 2014 18:09:43 +0000
Subject: [New-bugs-announce] [issue22095] Use of set_tunnel with default
	port results in incorrect	post value in host header
Message-ID: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za>


New submission from Demian Brecht:

Creating this bug for clarity, but was encountered while investigating 22041 (now set as not a bug).

When using set_tunnel with default port, the port value in the host header is set to "None":

"send: b'POST [PATH] HTTP/1.1\r\nHost: [HOST]:None\r\nAccept-Encoding: identity\r\nContent-Length: 41\r\nAccept: text/plain\r\nContent-type: application/x-www-form-urlencoded\r\n\r\n[FORM_DATA]'"

This issue seems to have been introduced in 3.4 when _tunnel_host and _tunnel_port were introduced to decouple the destination host and port from the proxy host and port.

----------
components: Library (Lib)
messages: 224175
nosy: demian.brecht
priority: normal
severity: normal
status: open
title: Use of set_tunnel with default port results in incorrect post value in host header
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jul 28 23:02:31 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 28 Jul 2014 21:02:31 +0000
Subject: [New-bugs-announce] [issue22096] Argument Clinic: add ability to
	specify an existing impl	function
Message-ID: <1406581351.41.0.878887990882.issue22096@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: Demos and Tools
nosy: larry, zach.ware
priority: normal
severity: normal
status: open
title: Argument Clinic: add ability to specify an existing impl function
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jul 28 23:30:29 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2014 21:30:29 +0000
Subject: [New-bugs-announce] [issue22097] Linked list API for ordereddict
Message-ID: <1406583029.35.0.857255601544.issue22097@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Right now Python doesn't have an ordered container which allows O(1) insertion at any place. It would be nice to have such an API on ordered dicts (e.g. insert_after() / insert_before()).

----------
messages: 224191
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Linked list API for ordereddict
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jul 28 23:58:29 2014
From: report at bugs.python.org (Florian Dold)
Date: Mon, 28 Jul 2014 21:58:29 +0000
Subject: [New-bugs-announce] [issue22098] Behavior of Structure inconsistent
	with	BigEndianStructure when using __slots__
Message-ID: <1406584709.24.0.956833774104.issue22098@psf.upfronthosting.co.za>


New submission from Florian Dold:

Habimg __slots__ = [] on a class inheriting from ctypes.Structure prevents undefined fields from being set, as expected.

When inheriting from ctypes.BigEndianStructure, however, it is possible to set undefined fields.

See the attached file for small test case for the behavior.

----------
components: ctypes
files: bug-ctypes-slots.py
messages: 224195
nosy: Florian.Dold
priority: normal
severity: normal
status: open
title: Behavior of Structure inconsistent with BigEndianStructure when using __slots__
versions: Python 3.4
Added file: http://bugs.python.org/file36146/bug-ctypes-slots.py

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

From report at bugs.python.org  Tue Jul 29 01:40:41 2014
From: report at bugs.python.org (Adam Kimbrough)
Date: Mon, 28 Jul 2014 23:40:41 +0000
Subject: [New-bugs-announce] [issue22099] Two "Save As" Windows
Message-ID: <1406590841.29.0.686223159208.issue22099@psf.upfronthosting.co.za>


New submission from Adam Kimbrough:

I am on a Mac running Mavericks 10.9.4. Whenever I press shift+command+s to save a file as a specific name, it opens two windows. But, if I "Save As" through the button in the menu bar, it only opens one window.

----------
components: IDLE
messages: 224204
nosy: Adam.Kimbrough
priority: normal
severity: normal
status: open
title: Two "Save As" Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 29 17:34:02 2014
From: report at bugs.python.org (Shiz)
Date: Tue, 29 Jul 2014 15:34:02 +0000
Subject: [New-bugs-announce] [issue22100] Use $HOSTPYTHON when determining
	candidate interpreter	for $PYTHON_FOR_BUILD.
Message-ID: <1406648042.0.0.0162670058613.issue22100@psf.upfronthosting.co.za>


New submission from Shiz:

Currently, when cross-compiling, the configure script doesn't take $HOSTPYTHON into account when determining $PYTHON_FOR_BUILD. This can lead to a wrong Python interpreter being used for several critical cross-compilation stages, leading to compilation errors[1].

Attached is a patch which makes it take $HOSTPYTHON into account, thus solving said issues, diffed against the current hg tip, 723e0a7c4914.

[1]: https://github.com/rave-engine/python3-android/issues/1 (the last issue in the report)

----------
components: Cross-Build
files: Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection.patch
keywords: patch
messages: 224230
nosy: shiz
priority: normal
severity: normal
status: open
title: Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36150/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection.patch

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

From report at bugs.python.org  Tue Jul 29 23:28:19 2014
From: report at bugs.python.org (Akira Li)
Date: Tue, 29 Jul 2014 21:28:19 +0000
Subject: [New-bugs-announce] [issue22101] collections.abc.Set doesn't
	provide copy() method
Message-ID: <1406669299.88.0.807816572925.issue22101@psf.upfronthosting.co.za>


New submission from Akira Li:

The documentation for standard types says [1]:

  clear() and copy() are included for consistency with the interfaces of
  mutable containers that don?t support slicing operations (such as dict
  and set)

  New in version 3.3: clear() and copy() methods.

[1] https://docs.python.org/3.4/library/stdtypes.html#immutable-sequence-types

but collections.abc documentation mentions only clear() method.

I've uploaded a patch that implements Set.copy() method, mentions it in
Set's documentation, and adds a sanity test.

----------
components: Library (Lib)
files: set-copy.patch
keywords: patch
messages: 224255
nosy: akira
priority: normal
severity: normal
status: open
title: collections.abc.Set doesn't provide copy() method
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36153/set-copy.patch

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

From report at bugs.python.org  Tue Jul 29 23:42:10 2014
From: report at bugs.python.org (Guillaume Carre)
Date: Tue, 29 Jul 2014 21:42:10 +0000
Subject: [New-bugs-announce] [issue22102] Zipfile generates Zipfile error in
	zip with 0 total	number of disk in Zip64 end of central
	directory locator
Message-ID: <1406670130.27.0.606950005482.issue22102@psf.upfronthosting.co.za>


New submission from Guillaume Carre:

I've got a zip file with a Zip64 end of central directory locator in which:
- total number of disks = 0000
- number of the disk with the start of the zip64 end of central directory = 0000

According to the test line 176 in zipfile.py this fails:
    if diskno != 0 or disks != 1:
        raise BadZipfile("zipfiles that span multiple disks are not supported")

I believe the test should be changed to  
    if diskno != 0 or disks > 1:

----------
components: Library (Lib)
messages: 224257
nosy: Guillaume.Carre
priority: normal
severity: normal
status: open
title: Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 29 23:44:12 2014
From: report at bugs.python.org (=?utf-8?q?Michael_B=C3=BCsch?=)
Date: Tue, 29 Jul 2014 21:44:12 +0000
Subject: [New-bugs-announce] [issue22103] bdist_wininst does not run install
	script
Message-ID: <1406670252.28.0.0982043111898.issue22103@psf.upfronthosting.co.za>


New submission from Michael B?sch:

The bdist_wininst installer does not run the specified --install-script.

Attached is an example project foo.zip.
setup.py is invoked as follows:
py setup.py bdist_wininst --install-script foo_postinstall.py

The installer shows that it successfully ran the install script, but it did not do this. The file C:\foo.txt is not created. If I add print()s to the install script, these messages are not shown either.

I tested this on Python 3.4, 64-bit (Win7) and 32-bit (XP)

----------
components: Installation
files: foo.zip
messages: 224258
nosy: mb_
priority: normal
severity: normal
status: open
title: bdist_wininst does not run install script
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file36154/foo.zip

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

From report at bugs.python.org  Wed Jul 30 02:31:21 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jul 2014 00:31:21 +0000
Subject: [New-bugs-announce] [issue22104] test_asyncio unstable in refleak
	mode
Message-ID: <1406680281.17.0.949528846195.issue22104@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

test_asyncio doesn't give usable results when looking for refleaks:

$ ./python -m test -R 2:4 test_asyncio
[1/1] test_asyncio
beginning 6 repetitions
123456
......
test_asyncio leaked [212, -106, 265, -6360] references, sum=-5989
test_asyncio leaked [59, -29, 76, -1799] memory blocks, sum=-1693
1 test failed:
    test_asyncio

----------
components: Tests
messages: 224280
nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: test_asyncio unstable in refleak mode
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul 30 05:04:05 2014
From: report at bugs.python.org (Joe Gaspard)
Date: Wed, 30 Jul 2014 03:04:05 +0000
Subject: [New-bugs-announce] [issue22105] Hang during File "Save As"
Message-ID: <1406689445.5.0.172130301576.issue22105@psf.upfronthosting.co.za>


New submission from Joe Gaspard:

Python 3.4.1 hang while trying to save a file on  29 July 2014 5Pm.  The computer was a "DIY" i7/WIN7-64 bit/INTEL DZ87KLT-75 Motherboard (w/ Intel i7-4770-K 3.5 GHz processor).   IDLE was operating on "G:\python.exe 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014 10:45:13) [MSC v.1600 64 bit (AMD64] on win 32"
The hang occurred when  a "file save as" operation was attempted.  The file was a display of a "print" of a 400,000 line result from a 3-loop nested "while" count ".py" program.  NOTE: The "make test" set was run a few days earlier and did not result in any messages (all ok).  Thanks - "py" is a great proram and excellent docs.   

Description:
  A problem caused this program to stop interacting with Windows.

Problem signature:
  Problem Event Name:	AppHangB1
  Application Name:	pythonw.exe
  Application Version:	0.0.0.0
  Application Timestamp:	5378731e
  Hang Signature:	7efa
  Hang Type:	2048
  OS Version:	6.1.7601.2.1.0.768.3
  Locale ID:	1033
  Additional Hang Signature 1:	7efa98bee311c458b7449fe89d922f8b
  Additional Hang Signature 2:	271f
  Additional Hang Signature 3:	271ff7b6e5aa15e9ab2854edd8b040b6
  Additional Hang Signature 4:	7efa
  Additional Hang Signature 5:	7efa98bee311c458b7449fe89d922f8b
  Additional Hang Signature 6:	271f
  Additional Hang Signature 7:	271ff7b6e5aa15e9ab2854edd8b040b6

----------
components: IDLE
messages: 224286
nosy: Joe
priority: normal
severity: normal
status: open
title: Hang during File "Save As"
versions: Python 3.4

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

From report at bugs.python.org  Wed Jul 30 12:47:09 2014
From: report at bugs.python.org (Charles Newey)
Date: Wed, 30 Jul 2014 10:47:09 +0000
Subject: [New-bugs-announce] [issue22106] Python 2 docs 'control flow/pass'
	section contains bad	example
Message-ID: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>


New submission from Charles Newey:

URL: https://docs.python.org/2/tutorial/controlflow.html#pass-statements

Quoted verbatim:
"""
The pass statement does nothing. It can be used when a statement is required syntactically but the program requires no action. For example:
>>>

>>> while True:
...     pass  # Busy-wait for keyboard interrupt (Ctrl+C)
...

"""

While the example illustrates the point, it *may* give bad ideas to novice programmers reading it - "while True: pass" is an antipattern as it's very inefficient.

----------
assignee: docs at python
components: Documentation
messages: 224296
nosy: Charles.Newey, docs at python
priority: normal
severity: normal
status: open
title: Python 2 docs 'control flow/pass' section contains bad example
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 30 14:40:41 2014
From: report at bugs.python.org (Roger Upole)
Date: Wed, 30 Jul 2014 12:40:41 +0000
Subject: [New-bugs-announce] [issue22107] tempfile module misinterprets
	access denied error on	Windows
Message-ID: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>


New submission from Roger Upole:

_mkstemp_inner assumes that an access denied error means that it
has generated a filename that matches an existing foldername.
However, in the case of a folder for which you don't have permissions to
create a file, this means it will loop thru the maximum possible number of files.
This causes it to hang for several seconds and eventually return a bogus
FileExistsError.

Similar behaviour exists in 2.7.7, but it throws an IOError instead.

http://bugs.python.org/issue18849 seems to be where this was introduced.

----------
components: Windows
messages: 224304
nosy: rupole
priority: normal
severity: normal
status: open
title: tempfile module misinterprets access denied error on Windows
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Jul 30 19:10:42 2014
From: report at bugs.python.org (Jonas Jelten)
Date: Wed, 30 Jul 2014 17:10:42 +0000
Subject: [New-bugs-announce] [issue22108] python c api wchar_t*/char*
	passing contradiction
Message-ID: <1406740242.49.0.577134590981.issue22108@psf.upfronthosting.co.za>


New submission from Jonas Jelten:

The documentation and the code example at
https://docs.python.org/3.5/extending/embedding.html#very-high-level-embedding

#include <Python.h>

int
main(int argc, char *argv[])
{
  Py_SetProgramName(argv[0]);  /* optional but recommended */
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
                     "print('Today is', ctime(time()))\n");
  Py_Finalize();
  return 0;
}

contradicts the actual implementation of the code:
http://hg.python.org/cpython/file/tip/Include/pythonrun.h#l25

which leads to compiler errors. To fix them, ugly wchar_t to char conversions are needed.

Also, I was hoping, Python 3.3 finally switched from wchar_t to char and UTF-8.
at least that's how I understood PEP 393 http://python.org/dev/peps/pep-0393/

see also:

http://stackoverflow.com/questions/21591908/python-3-3-c-string-handling-wchar-t-vs-char


=> Are the docs wrong (which i hope are not, the example is straightforward and simple-stupid with a char*),
or is cpython wrong?

----------
components: Unicode
messages: 224327
nosy: ezio.melotti, haypo, thejj
priority: normal
severity: normal
status: open
title: python c api wchar_t*/char* passing contradiction
type: compile error
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul 30 20:00:28 2014
From: report at bugs.python.org (Cory Klein)
Date: Wed, 30 Jul 2014 18:00:28 +0000
Subject: [New-bugs-announce] [issue22109] Python failing in markupsafe
	module when running ansible
Message-ID: <1406743228.93.0.711963705177.issue22109@psf.upfronthosting.co.za>


New submission from Cory Klein:

After installing ansible and python using homebrew, if I run ansible it crashes after calling into python's markupsafe:

$ ansible
Traceback (most recent call last):
  File "/usr/local/Cellar/ansible/1.6.10/libexec/bin/ansible", line 5, in <module>
    pkg_resources.run_script('ansible==1.6.10', 'ansible')
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 492, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 1350, in run_script
    execfile(script_filename, namespace, namespace)
  File "/usr/local/Cellar/ansible/1.6.10/lib/python2.7/site-packages/ansible-1.6.10-py2.7.egg/EGG-INFO/scripts/ansible", line 25, in <module>
    from ansible.runner import Runner
  File "/usr/local/Cellar/ansible/1.6.10/lib/python2.7/site-packages/ansible-1.6.10-py2.7.egg/ansible/runner/__init__.py", line 32, in <module>
    import jinja2
  File "/usr/local/Cellar/ansible/1.6.10/libexec/lib/python2.7/site-packages/Jinja2-2.7.1-py2.7.egg/jinja2/__init__.py", line 33, in <module>
    from jinja2.environment import Environment, Template
  File "/usr/local/Cellar/ansible/1.6.10/libexec/lib/python2.7/site-packages/Jinja2-2.7.1-py2.7.egg/jinja2/environment.py", line 13, in <module>
    from jinja2 import nodes
  File "/usr/local/Cellar/ansible/1.6.10/libexec/lib/python2.7/site-packages/Jinja2-2.7.1-py2.7.egg/jinja2/nodes.py", line 18, in <module>
    from jinja2.utils import Markup
  File "/usr/local/Cellar/ansible/1.6.10/libexec/lib/python2.7/site-packages/Jinja2-2.7.1-py2.7.egg/jinja2/utils.py", line 520, in <module>
    from markupsafe import Markup, escape, soft_unicode
  File "/Library/Python/2.7/site-packages/markupsafe/__init__.py", line 14, in <module>
    from markupsafe._compat import text_type, string_types, int_types, \
ImportError: No module named _compat

----------
assignee: ronaldoussoren
components: Macintosh
messages: 224331
nosy: coryfklein, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python failing in markupsafe module when running ansible
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 30 23:51:41 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 30 Jul 2014 21:51:41 +0000
Subject: [New-bugs-announce] [issue22110] enable extra compilation warnings
Message-ID: <1406757101.06.0.990367547704.issue22110@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

The patch attached enables -Wsign-compare and -Wunreachable-code if supported by the compiler.
AFAICT, mixed sign comparison warning is automatically enabled by Microsoft's compiler, and is usually a good thing.
It does add some warnings though.

As for unreachable code, it's also usually a good thing, since it can be a source of bugs. Note that it's not enabled in debug mode, since in debug mode the code paths aren't the same.

----------
components: Build
files: extra_warnings.diff
keywords: patch
messages: 224349
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: enable extra compilation warnings
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36169/extra_warnings.diff

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

From report at bugs.python.org  Thu Jul 31 02:42:38 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Thu, 31 Jul 2014 00:42:38 +0000
Subject: [New-bugs-announce] [issue22111] Improve imaplib testsuite.
Message-ID: <1406767358.21.0.322738125164.issue22111@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

The status quo of test_imaplib is a bit frustrating: 4 test functions out of 31 get executed by default while only few seem to need any resources.

I tried to solve this in the attached patch. Did I get something wrong or was that checking for network resources just a mistake?

----------
components: Tests
files: imaplib_test.patch
keywords: patch
messages: 224367
nosy: jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Improve imaplib testsuite.
versions: Python 3.5
Added file: http://bugs.python.org/file36170/imaplib_test.patch

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

From report at bugs.python.org  Thu Jul 31 04:40:18 2014
From: report at bugs.python.org (Daniel Greenfeld)
Date: Thu, 31 Jul 2014 02:40:18 +0000
Subject: [New-bugs-announce] [issue22112] '_UnixSelectorEventLoop' object
	has no attribute	'create_task'
Message-ID: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>


New submission from Daniel Greenfeld:

Problem
========

The documentation on asyncio provides an example of a parallel execution of tasks. The code is at: https://docs.python.org/3/library/asyncio-task.html#example-parallel-execution-of-tasks

``` python
import asyncio
 
@asyncio.coroutine
def factorial(name, number):
    f = 1
    for i in range(2, number+1):
        print("Task %s: Compute factorial(%s)..." % (name, i))
        yield from asyncio.sleep(1)
        f *= i
    print("Task %s: factorial(%s) = %s" % (name, number, f))
 
loop = asyncio.get_event_loop()
tasks = [
    loop.create_task(factorial("A", 2)),
    loop.create_task(factorial("B", 3)),
    loop.create_task(factorial("C", 4))]
loop.run_until_complete(asyncio.wait(tasks))
loop.close()
```

Unfortunately, when I try to run this sample code on Python 3.4.1, I run into an error. Specifically, the `loop.create_task()` method does not exist:

``` python
Traceback (most recent call last):
  File "what_me_asynicio.py", line 14, in <module>
    loop.create_task(factorial("A", 2)),
AttributeError: '_UnixSelectorEventLoop' object has no attribute 'create_task'
```

When I perform a dir() on the `loop` object, no `create_task` item is in the result.

System Information
====================

Python Version: 3.4.1
Operating System: OSX 10.9.3
(Also confirmed on Python 3.4.0 in Ubuntu 14.04)

----------
assignee: docs at python
components: Documentation, Macintosh, asyncio
messages: 224374
nosy: docs at python, gvanrossum, haypo, pydanny, yselivanov
priority: normal
severity: normal
status: open
title: '_UnixSelectorEventLoop' object has no attribute 'create_task'
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 31 10:31:11 2014
From: report at bugs.python.org (Clayton Stangeland)
Date: Thu, 31 Jul 2014 08:31:11 +0000
Subject: [New-bugs-announce] [issue22113] memoryview and struct.pack_into
Message-ID: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za>


New submission from Clayton Stangeland:

I expect struct.pack_into to work for a memoryview. Currently struct.pack_into throws an exception.

>>> import struct
>>> buf = bytearray(10)
>>> struct.pack_into("<B", buf, 0, 99)
>>> buf[0]
99
>>> view = memoryview(buf)
>>> view.readonly
False
>>> struct.pack_into("<B", view, 0, 88)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: expected a writeable buffer object
>>> view[0:1] = 'a'
>>> view[0]
'a'
>>> buf[0]
97
>>> chr(buf[0])
'a'

The memoryview is writeable and from what I can tell from the documentation it implements the buffer interface, but struct.pack_into will not use it.

----------
files: struct_pack_into.py
messages: 224386
nosy: stangelandcl
priority: normal
severity: normal
status: open
title: memoryview and struct.pack_into
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36175/struct_pack_into.py

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

From report at bugs.python.org  Thu Jul 31 13:58:59 2014
From: report at bugs.python.org (Amrith Kumar)
Date: Thu, 31 Jul 2014 11:58:59 +0000
Subject: [New-bugs-announce] [issue22114] You cannot call communicate()
	safely after receiving	EAGAIN
Message-ID: <1406807939.82.0.812223355091.issue22114@psf.upfronthosting.co.za>


New submission from Amrith Kumar:

Environment:
- Linux (Ubuntu 14.04 LTS, x64) running Python 2.7.
- Code uses eventlet.green.subprocess

Code establishes subprocess as:

   subprocess.Popen(command,
                    stdin=subprocess.PIPE,
                    stdout=subprocess.PIPE,
                    stderr=subprocess.PIPE, ...)

It then calls communicate()

communicate() throws EAGAIN

The code calls communicate() again

This fails with "ValueError: I/O operation on closed file"

This exception comes from eventlet/greenio.py because an operation (flush) has been attempted on a closed file.

The complete explanation of this failure is this.

When communicate() is called in this way (WITH NO INPUT but with all three handles stdin, stdout, stderr), code in communicate() bypasses the "1 handle optimization" and goes directly to _communicate()

_communicate() will first send any input on stdin along, and flush and close stdin(). 

>From that point forward, if anything to do with stderr and stdout returns EAGAIN, an attempt to call communicate() again will fail because stdin has now been closed().

This is because the code in _communicate() preemptively closes stdin if there is no input but does not reset stdin.

       def _communicate(self, input):
            if self.stdin:
                # Flush stdio buffer.  This might block, if the user has
                # been writing to .stdin in an uncontrolled fashion.
                self.stdin.flush()
                if not input:
                    self.stdin.close()

The fix for this is relatively straightforward (conceptually).

       def _communicate(self, input):
            if self.stdin:
                # Flush stdio buffer.  This might block, if the user has
                # been writing to .stdin in an uncontrolled fashion.
                self.stdin.flush()
                if not input:
                    self.stdin.close()
                    self.stdin = None # This should take care of it.

However, a partial workaround from the client perspective is this.

1. If you have no input, set stdin to None
2. If you do have input and you get EAGAIN, you cannot safely retry because your input may have already been completely or partially sent to the subprocess; you have to assume failure.

--------------------
Backtrace:

Traceback (most recent call last):
	File "/opt/stack/trove/trove/tests/unittests/guestagent/test_mongodb_manager.py", line 58, in test_prepare_from_backup
		self._prepare_dynamic(backup_id='backup_id_123abc')
	File "/opt/stack/trove/trove/tests/unittests/guestagent/test_mongodb_manager.py", line 91, in _prepare_dynamic
		backup_info=backup_info)
	File "trove/guestagent/datastore/mongodb/manager.py", line 66, in prepare
		operating_system.update_owner('mongodb', 'mongodb', mount_point)
	File "trove/guestagent/common/operating_system.py", line 109, in update_owner
		run_as_root=True, root_helper="sudo")
	File "trove/common/utils.py", line 278, in execute_with_timeout
		return execute(*args, **kwargs)
	File "trove/openstack/common/processutils.py", line 186, in execute
		result = obj.communicate()
	File "/usr/lib/python2.7/subprocess.py", line 799, in communicate
		return self._communicate(input)
	File "/usr/lib/python2.7/subprocess.py", line 1396, in _communicate
		self.stdin.flush()
	File "/opt/stack/trove/.tox/py27/local/lib/python2.7/site-packages/eventlet/greenio.py", line 419, in _operationOnClosedFile
		raise ValueError("I/O operation on closed file")

ValueError: I/O operation on closed file

----------
components: IO
messages: 224398
nosy: amrith
priority: normal
severity: normal
status: open
title: You cannot call communicate() safely after receiving EAGAIN
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 31 16:47:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Jul 2014 14:47:51 +0000
Subject: [New-bugs-announce] [issue22115] Add new methods to trace Tkinter
	variables
Message-ID: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Command used to monitor Tcl variable access ("trace variable", "trace vdelete", "trace vinfo") are deprecated and will likely be removed in a future version of Tcl. Replacements ("trace add variable", "trace remove variable", "trace info variable") use slightly different syntax (operations are specified as a list of words "array", "read", "write" and "unset" instead of a string containing characters "a", "r", "w" and "u"). Therefore we need new set of methods.

Proposed preliminary patch adds trace_add, trace_remove and trace_info methods to the Variable class. It will be changed after applying issue22068 patch. Tests for old methods will be backported to older Python versions.

----------
components: Tkinter
files: tkinter_trace_variable_2.patch
keywords: patch
messages: 224407
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add new methods to trace Tkinter variables
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36179/tkinter_trace_variable_2.patch

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

From report at bugs.python.org  Thu Jul 31 19:51:31 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2014 17:51:31 +0000
Subject: [New-bugs-announce] [issue22116] Weak reference support for C
	function objects
Message-ID: <1406829091.92.0.589773315049.issue22116@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently, it is not possible to take a weakref to a PyCFunction object. However, those objects already have full GC support, so it wouldn't be silly to add weakref support to them.

(this came in the context of numba, which generates such C functions on-the-fly)

----------
components: Interpreter Core
messages: 224432
nosy: pitrou
priority: normal
severity: normal
status: open
title: Weak reference support for C function objects
type: enhancement
versions: Python 3.5

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