From report at bugs.python.org  Mon Feb  1 00:24:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 01 Feb 2016 05:24:35 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <1454304275.04.0.390891088479.issue26173@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  1 00:42:58 2016
From: report at bugs.python.org (Thomas Caswell)
Date: Mon, 01 Feb 2016 05:42:58 +0000
Subject: [issue24266] raw_input + readline: Ctrl+C during search breaks
 readline
In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za>
Message-ID: <1454305378.15.0.213028286318.issue24266@psf.upfronthosting.co.za>


Thomas Caswell added the comment:

For reference https://github.com/ludwigschwardt/python-gnureadline/pull/47 is what a back-port of the functionality looks like.

----------

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

From report at bugs.python.org  Mon Feb  1 01:21:21 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Feb 2016 06:21:21 +0000
Subject: [issue26254] ssl server doesn't work with ECC certificates
In-Reply-To: <1454291417.3.0.6306970178.issue26254@psf.upfronthosting.co.za>
Message-ID: <1454307681.97.0.586567418338.issue26254@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

ECC certs using named curves have to have the OPENSSL_EC_NAMED_CURVE flag set. Pass -pkeyopt ec_param_enc:named_curve to the openssl req.

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Feb  1 04:39:09 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 01 Feb 2016 09:39:09 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454319549.11.0.329492478575.issue26110@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
nosy: +alecsandru.patrascu

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

From report at bugs.python.org  Mon Feb  1 04:57:05 2016
From: report at bugs.python.org (Luke Schubert)
Date: Mon, 01 Feb 2016 09:57:05 +0000
Subject: [issue26255] symtable.Symbol.is_referenced() returns false for valid
 use
Message-ID: <1454320625.23.0.218294172463.issue26255@psf.upfronthosting.co.za>


New submission from Luke Schubert:

If the following function is saved in listcomp.py:

def encode(inputLetters):
    code = {'C':'D', 'F':'E'}
    return set(code[x] for x in inputLetters)

and the following code is used to create a symtable for this function:

import symtable

if __name__ == "__main__":
    fileName = 'listcomp.py'
    f = open(fileName, 'r')
    source = f.read()
    table = symtable.symtable(source, fileName, 'exec')
    children = table.get_children()
    for childTable in children:
        symbols = childTable.get_symbols()
        for s in symbols:
            if (not s.is_referenced()):
                print ("Unused symbol '%s' in function '%s'"
                       % (s.get_name(), childTable.get_name()))

then is_referenced() returns false for the 'code' symbol.

If the following function is saved instead:

def encode2(inputLetters):
    code = {'C':'D', 'F':'E'}
    return [ code[x] for x in inputLetters ]

then is_referenced() returns true for the 'code' symbol.

Possibly I'm misunderstanding what is_referenced() means, but I thought it should return true in both cases?

----------
messages: 259316
nosy: luke.schubert
priority: normal
severity: normal
status: open
title: symtable.Symbol.is_referenced() returns false for valid use
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  1 05:21:37 2016
From: report at bugs.python.org (Tiago Peixoto)
Date: Mon, 01 Feb 2016 10:21:37 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1454322097.1.0.00283083422697.issue23735@psf.upfronthosting.co.za>


Changes by Tiago Peixoto <tiago at skewed.de>:


----------
nosy: +count0

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

From report at bugs.python.org  Mon Feb  1 05:28:34 2016
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Mon, 01 Feb 2016 10:28:34 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
Message-ID: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

Inspired by the recently new discovered 49th Mersenne prime number I wrote a module to do high speed long/int to decimal conversion. I can now output the new Mersenne number in 18.5 minutes (instead of several hours) on my machine.
For numbers longer than about 100000 bits, this routine it is faster than str(number) thanks to the Karatsuba multiplication in CPython.
The module supports all number bases 2 through 36, and is written in pure python (both 2 and 3).
There is a simple way to save more time by reusing the conversion object (saving about half the time for later calls).
My suggestion is to incorporate this into some library, since Python still lacks a routine to convert to any number base. Ideally, it could be incorporated in the builtin str function, but this would need more work. 
When converting to C, it is recommended to optimize bases 4 and 32 the same way as oct, hex and bin do (which isn't easily accessible from Python).

Hope you like it. At least, it was a lot of fun to write...

Hope you like it.

----------
components: Library (Lib)
files: fastStr.py
messages: 259317
nosy: jneb
priority: normal
severity: normal
status: open
title: Fast decimalisation and conversion to other bases
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41770/fastStr.py

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

From report at bugs.python.org  Mon Feb  1 05:49:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 01 Feb 2016 10:49:55 +0000
Subject: [issue26257] Eliminate buffer_tests.py
Message-ID: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>


New submission from Martin Panter:

This sort of follows on from other cleanup of test_bytes.py in Issue 19587.

Currently buffer_tests defines one base test class, MixinBytesBufferCommonTests, which is used by test_bytes.py to test bytearray (but not bytes!). However there are other tests defined in test_bytes.py, or string_tests.py, which are run, or could be run, for both bytearray and bytes. I haven?t checking too closely, but I think all the methods in buffer_tests could be merged with other methods and collected into string_tests.BaseTest. Then they would get run for bytes, bytearray, str, and UserString.

The following methods are probably redundant with class string_tests.MixinStrUnicodeUserStringTest (only run for str and UserString). It looks like there is no bytes version of these tests:

* test_islower/upper/title/space/alpha/alnum/digit()
* test_title()
* test_splitlines()

test_capitalize() looks redundant with half of the method in string_tests.CommonTest (also only run for str and UserString). Again there doesn?t seem to be a bytes version of it. I think the common part could be moved into BaseTest, and the unicode-specific part left where it is.

The following are probably also redundant with class string_tests.CommonTest:

* test_ljust/rjust/center()
* test_swapcase()
* test_zfill()

For ljust(), rjust() and center(), there are also tests run for bytes and bytearray in test_bytes.BaseBytesTest that could also be merged at the same time. But swapcase() and zfill() don?t seem to be currently tested for bytes.

----------
components: Tests
messages: 259318
nosy: martin.panter
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate buffer_tests.py
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Feb  1 05:51:56 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 01 Feb 2016 10:51:56 +0000
Subject: [issue26255] symtable.Symbol.is_referenced() returns false for valid
 use
In-Reply-To: <1454320625.23.0.218294172463.issue26255@psf.upfronthosting.co.za>
Message-ID: <1454323916.27.0.993409865964.issue26255@psf.upfronthosting.co.za>


Changes by Xiang Zhang <18518281186 at 126.com>:


----------
nosy: +xiang.zhang

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

From report at bugs.python.org  Mon Feb  1 06:01:29 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 01 Feb 2016 11:01:29 +0000
Subject: [issue26255] symtable.Symbol.is_referenced() returns false for valid
 use
In-Reply-To: <1454320625.23.0.218294172463.issue26255@psf.upfronthosting.co.za>
Message-ID: <1454324489.81.0.198074943427.issue26255@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components: +Extension Modules, Library (Lib)
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Feb  1 06:08:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Feb 2016 11:08:51 +0000
Subject: [issue19587] Remove empty tests in test_bytes.FixedStringTest
In-Reply-To: <1384451242.84.0.0741219651505.issue19587@psf.upfronthosting.co.za>
Message-ID: <20160201110830.62662.53743@psf.io>


Roundup Robot added the comment:

New changeset 22c2dd04a3d3 by Martin Panter in branch '3.5':
Issue #19587: Remove masked and redundant tests in test_bytes
https://hg.python.org/cpython/rev/22c2dd04a3d3

New changeset 8545a082fcaa by Martin Panter in branch 'default':
Issue #19587: Merge test_bytes cleanup from 3.5
https://hg.python.org/cpython/rev/8545a082fcaa

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  1 06:43:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 01 Feb 2016 11:43:10 +0000
Subject: [issue19587] Remove empty tests in test_bytes.FixedStringTest
In-Reply-To: <1384451242.84.0.0741219651505.issue19587@psf.upfronthosting.co.za>
Message-ID: <1454326990.58.0.72299596291.issue19587@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Serhiy for reviewing. You are right that buffer_tests is only run on bytearray; I must have gotten mixed up. I fixed the comment in the version I committed.

Yes I think I agree with eliminating buffer_tests.py, which is only run for bytearray. I opened Issue 26257 for that.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  1 07:03:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 01 Feb 2016 12:03:04 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1454328184.2.0.0992796706019.issue26257@psf.upfronthosting.co.za>


Martin Panter added the comment:

I didn?t end up merging test_ljust/rjust/center() from test_bytes. Those tests are more specific to bytes and bytearray, so they are better left as-is.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41771/buffer_tests.patch

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

From report at bugs.python.org  Mon Feb  1 07:21:28 2016
From: report at bugs.python.org (Ali Razmjoo)
Date: Mon, 01 Feb 2016 12:21:28 +0000
Subject: [issue26258] readline module for python 3.x on windows
Message-ID: <1454329288.94.0.0141088037674.issue26258@psf.upfronthosting.co.za>


New submission from Ali Razmjoo:

Hello,

I using python 2.7.10 on windows and there isn't any problem with this readline module, but it's not exist in python3.x on windows, is it possible to add it ? how?

----------
messages: 259322
nosy: Ali Razmjoo
priority: normal
severity: normal
status: open
title: readline module for python 3.x on windows

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

From report at bugs.python.org  Mon Feb  1 07:24:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Feb 2016 12:24:43 +0000
Subject: [issue26258] readline module for python 3.x on windows
In-Reply-To: <1454329288.94.0.0141088037674.issue26258@psf.upfronthosting.co.za>
Message-ID: <1454329483.57.0.738464447199.issue26258@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The Python readline is a thin wrapper on top of the UNIX readline library.

You need a port of the readline library to Windows. There are some ports, but I don't think that Python can take the responsability to endorse them, ports seem unofficial.

Example: http://gnuwin32.sourceforge.net/packages/readline.htm -- last release 8 years ago...

MinGW & Cygwin have readline on Windows, but it's a different tool chain (GCC) than the current toolchain used by Python on Windows (Visual Studio).

----------
nosy: +haypo

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

From report at bugs.python.org  Mon Feb  1 09:02:22 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 01 Feb 2016 14:02:22 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454335342.38.0.562298260271.issue26256@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Very nice. I'd suggest posting it as a recipe or as a Python package on PyPI for others to use. It's not really something that it would be appropriate to add to the Python core: Python isn't really intended for super-efficient high-precision arithmetic, and there are external libraries for that sort of thing (like gmpy2, for example).

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Mon Feb  1 09:18:10 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 01 Feb 2016 14:18:10 +0000
Subject: [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <1454336290.61.0.509337381136.issue26248@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Thanks, Victor!

----------

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

From report at bugs.python.org  Mon Feb  1 09:20:50 2016
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Mon, 01 Feb 2016 14:20:50 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454336450.59.0.285896170538.issue26256@psf.upfronthosting.co.za>


Jurjen N.E. Bos added the comment:

Thanks for the tip. I'll consider making it a recipe.
- Jurjen

----------

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

From report at bugs.python.org  Mon Feb  1 11:06:20 2016
From: report at bugs.python.org (Jonas Brunsgaard)
Date: Mon, 01 Feb 2016 16:06:20 +0000
Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get
 is performed, without push to queue.
Message-ID: <1454342780.58.0.210365622359.issue26259@psf.upfronthosting.co.za>


New submission from Jonas Brunsgaard:

When making repeated calls to queue.get, memory is building up and is not freed until queue.push is called.

I wrote this little program to show my findings. The program will perform a lot of calls to queue.get and once every 60 seconds a queue.push is performed. Every 15 seconds the memory usage of dictionaries is printet to the console. You can find the output below the program

```
import asyncio
from pympler import muppy
from pympler import summary


q = asyncio.Queue()
loop = asyncio.get_event_loop()
closing = False


async def get_with_timeout():
    while not closing:
        try:
            task = asyncio.ensure_future(q.get())
            await asyncio.wait_for(task, 0.2)
        except asyncio.TimeoutError:
            pass

def mem_profiling():
    if not closing:
        types_ = muppy.filter(muppy.get_objects(), Type=dict)
        summary.print_(summary.summarize(types_))
        loop.call_later(15, mem_profiling)

def put():
    q.put_nowait(None)
    loop.call_later(60, put)

put()
tasks = [asyncio.ensure_future(get_with_timeout()) for _ in range(10000)]
mem_profiling()

try:
    loop.run_forever()
except KeyboardInterrupt:
    closing = True
    loop.run_until_complete(
        asyncio.ensure_future(asyncio.wait(tasks)))
finally:
    loop.close()
```

Output:

                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |       11886 |      3.20 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |      224835 |     62.44 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |      401487 |    111.00 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |      576621 |    158.86 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |      219745 |     58.99 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |      390061 |    105.72 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |      560623 |    152.65 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============
                            <class 'dict |      220372 |     59.11 MB
         <class 'collections.OrderedDict |          11 |     16.84 KB
  <class 'email._encoded_words._QByteMap |           1 |    288     B
                                   types |   # objects |   total size
======================================== | =========== | ============

What we see is that memory builds up ~3mb/s, and when the push method is called the memory usage returns to normal.

Is this the expected behavior or is this a bug? If it is expected I think we should update the documentation, to let people know about this behavior.

--
Jonas Brunsgaard

----------
components: asyncio
files: poc.py
messages: 259327
nosy: Jonas Brunsgaard, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Memleak when repeated calls to asyncio.queue.Queue.get is performed, without push to queue.
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file41772/poc.py

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

From report at bugs.python.org  Mon Feb  1 11:35:23 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 01 Feb 2016 16:35:23 +0000
Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get
 is performed, without push to queue.
In-Reply-To: <1454342780.58.0.210365622359.issue26259@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+iCHLVJBbHSEpqiy9ipvmHQ=GDY83WeLEdA5k2=Gmcmw@mail.gmail.com>


Guido van Rossum added the comment:

I think this is expected behavior when you do a lot of get() calls
that are cancelled by a timeout. Each call leaves a cancelled Future
in the deque self._getters; these are removed only when _wakeup_next()
is called (by put or put_nowait).

Why is your app doing this?

I suppose we could band-aid this by removing cancelled Futures when
next calling get(), but that won't help if you start a load of get()
calls and then cancel them all.

Note that I don't want to complicate this code -- in the past it has
been very difficult to prove it was correct under all circumstances,
and now I am sure it is correct (barring memory leaks, as you've
shown). I want to make sure any fix for this issue doesn't complicate
the code, making it harder to understand or prove its correctness.

On Mon, Feb 1, 2016 at 8:06 AM, Jonas Brunsgaard <report at bugs.python.org> wrote:
>
> New submission from Jonas Brunsgaard:
>
> When making repeated calls to queue.get, memory is building up and is not freed until queue.push is called.
>
> I wrote this little program to show my findings. The program will perform a lot of calls to queue.get and once every 60 seconds a queue.push is performed. Every 15 seconds the memory usage of dictionaries is printet to the console. You can find the output below the program
>
> ```
> import asyncio
> from pympler import muppy
> from pympler import summary
>
>
> q = asyncio.Queue()
> loop = asyncio.get_event_loop()
> closing = False
>
>
> async def get_with_timeout():
>     while not closing:
>         try:
>             task = asyncio.ensure_future(q.get())
>             await asyncio.wait_for(task, 0.2)
>         except asyncio.TimeoutError:
>             pass
>
> def mem_profiling():
>     if not closing:
>         types_ = muppy.filter(muppy.get_objects(), Type=dict)
>         summary.print_(summary.summarize(types_))
>         loop.call_later(15, mem_profiling)
>
> def put():
>     q.put_nowait(None)
>     loop.call_later(60, put)
>
> put()
> tasks = [asyncio.ensure_future(get_with_timeout()) for _ in range(10000)]
> mem_profiling()
>
> try:
>     loop.run_forever()
> except KeyboardInterrupt:
>     closing = True
>     loop.run_until_complete(
>         asyncio.ensure_future(asyncio.wait(tasks)))
> finally:
>     loop.close()
> ```
>
> Output:
>
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |       11886 |      3.20 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |      224835 |     62.44 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |      401487 |    111.00 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |      576621 |    158.86 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |      219745 |     58.99 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |      390061 |    105.72 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |      560623 |    152.65 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>                             <class 'dict |      220372 |     59.11 MB
>          <class 'collections.OrderedDict |          11 |     16.84 KB
>   <class 'email._encoded_words._QByteMap |           1 |    288     B
>                                    types |   # objects |   total size
> ======================================== | =========== | ============
>
> What we see is that memory builds up ~3mb/s, and when the push method is called the memory usage returns to normal.
>
> Is this the expected behavior or is this a bug? If it is expected I think we should update the documentation, to let people know about this behavior.
>
> --
> Jonas Brunsgaard
>
> ----------
> components: asyncio
> files: poc.py
> messages: 259327
> nosy: Jonas Brunsgaard, gvanrossum, haypo, yselivanov
> priority: normal
> severity: normal
> status: open
> title: Memleak when repeated calls to asyncio.queue.Queue.get is performed, without push to queue.
> type: resource usage
> versions: Python 3.5
> Added file: http://bugs.python.org/file41772/poc.py
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26259>
> _______________________________________

----------

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

From report at bugs.python.org  Mon Feb  1 11:40:22 2016
From: report at bugs.python.org (Jim Jin)
Date: Mon, 01 Feb 2016 16:40:22 +0000
Subject: [issue26260] utf8 decoding inconsistency between P2 and P3
Message-ID: <1454344822.47.0.584077650452.issue26260@psf.upfronthosting.co.za>


New submission from Jim Jin:

PAYLOAD1 = b'\xce\xba\xe1\xbd\xb9\xcf\x83\xce\xbc\xce\xb5'
   PAYLOAD2 = b'\xed\xa0\x80'  
   PAYLOAD3 = b'\x65\x64\x69\x74\x65\x64'
   PAYLOAD = PAYLOAD1 + PAYLOAD2 + PAYLOAD3

   PAYLOAD.decode('utf8')  passes in P2.7.* and fails in P3.4

   Thank you for reading.

----------
components: Unicode
messages: 259329
nosy: ezio.melotti, haypo, jinz
priority: normal
severity: normal
status: open
title: utf8 decoding inconsistency between P2 and P3
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  1 11:54:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Feb 2016 16:54:25 +0000
Subject: [issue26260] utf8 decoding inconsistency between P2 and P3
In-Reply-To: <1454344822.47.0.584077650452.issue26260@psf.upfronthosting.co.za>
Message-ID: <1454345665.7.0.128274358036.issue26260@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> PAYLOAD.decode('utf8')  passes in P2.7.* and fails in P3.4

Well, Python 2 decoder didn't respect the Unicode standard. Please see:
http://unicodebook.readthedocs.org/issues.html#non-strict-utf-8-decoder-overlong-byte-sequences-and-surrogates

Python 3 is now stricted. You can still decode surrogate characters if you need them *for a good reason* using:

>>> b'\xed\xa0\x80'.decode('utf-8', 'surrogatepass')
'\ud800'

By they way, there is also:

>>> b'\xed\xa0\x80'.decode('utf-8', 'surrogateescape')
'\udced\udca0\udc80'

which is very different but may also help.

I suggest to close the issue as NOT A BUG.

----------

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

From report at bugs.python.org  Mon Feb  1 11:57:38 2016
From: report at bugs.python.org (Jim Jin)
Date: Mon, 01 Feb 2016 16:57:38 +0000
Subject: [issue26260] utf8 decoding inconsistency between P2 and P3
In-Reply-To: <1454345665.7.0.128274358036.issue26260@psf.upfronthosting.co.za>
Message-ID: <CY1PR02MB16905342865FA7EF467DB1D8E5DE0@CY1PR02MB1690.namprd02.prod.outlook.com>


Jim Jin added the comment:

Thank you very much for your help!

----------

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

From report at bugs.python.org  Mon Feb  1 12:02:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Feb 2016 17:02:21 +0000
Subject: [issue26260] utf8 decoding inconsistency between P2 and P3
In-Reply-To: <1454344822.47.0.584077650452.issue26260@psf.upfronthosting.co.za>
Message-ID: <1454346141.89.0.241661595572.issue26260@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Feb  1 12:06:36 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Mon, 01 Feb 2016 17:06:36 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <1454346396.72.0.0692405437138.issue26243@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Thanks for the review.
1. Changed "bytes" to "data".
2. Updated Doc as in issue 26244 (will update the patch if there will be changes there).
3. Added version changed notice but i don't think there is a need for What's new update.

----------
Added file: http://bugs.python.org/file41773/zlib-compress-level-keyword2.patch

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

From report at bugs.python.org  Mon Feb  1 12:09:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 01 Feb 2016 17:09:21 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454346561.98.0.830758216258.issue26110@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

For those interested in reviewing this patch at some point: please wait until I upload a new version.  The current patch is somewhat outdated.

----------

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

From report at bugs.python.org  Mon Feb  1 12:21:22 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 01 Feb 2016 17:21:22 +0000
Subject: [issue26261] NamedTemporaryFile documentation is vague about the
 `name` attribute
Message-ID: <1454347282.51.0.892341568817.issue26261@psf.upfronthosting.co.za>


New submission from Antti Haapala:

The documentation for NamedTemporaryFile is a bit vague. It says

[--] That name can be retrieved from the name attribute of the file object. [--] The returned object is always a file-like object whose file
attribute is the underlying true file object. This file-like object can be used in a with statement, just like a normal file.

That `file-like object` vs `true file object` made me assume that I need to do

    f = NamedTemporaryFile()
    f.file.name

to get the filename, which sort of worked, but only later realized that `f.file.name` is actually the file descriptor number on Linux, a.k.a an integer. Thus I suggest that the one sentence be changed to "That name can be retrieved from the name attribute of the returned file-like object."

----------
assignee: docs at python
components: Documentation
messages: 259334
nosy: docs at python, ztane
priority: normal
severity: normal
status: open
title: NamedTemporaryFile documentation is vague about the `name` attribute

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

From report at bugs.python.org  Mon Feb  1 12:21:37 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 01 Feb 2016 17:21:37 +0000
Subject: [issue26261] NamedTemporaryFile documentation is vague about the
 `name` attribute
In-Reply-To: <1454347282.51.0.892341568817.issue26261@psf.upfronthosting.co.za>
Message-ID: <1454347297.01.0.382242034754.issue26261@psf.upfronthosting.co.za>


Changes by Antti Haapala <antti at haapala.name>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Mon Feb  1 12:23:20 2016
From: report at bugs.python.org (jan matejek)
Date: Mon, 01 Feb 2016 17:23:20 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454347400.92.0.144269409658.issue26252@psf.upfronthosting.co.za>


Changes by jan matejek <jmatejek at suse.cz>:


----------
nosy: +matejcik

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

From report at bugs.python.org  Mon Feb  1 12:28:00 2016
From: report at bugs.python.org (Jonas Brunsgaard)
Date: Mon, 01 Feb 2016 17:28:00 +0000
Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get
 is performed, without push to queue.
In-Reply-To: <1454342780.58.0.210365622359.issue26259@psf.upfronthosting.co.za>
Message-ID: <1454347680.42.0.147949880695.issue26259@psf.upfronthosting.co.za>


Jonas Brunsgaard added the comment:

In my particular case, I developed an application close to beanstalkd, but with redis as "engine". I did create a callbackback reader class for users to subclass, the callbackreader is checking every second, on every tube(queue.Object). If new data has arrived for processing (this subroutine is using queue.get with wait_for). Maybe asyncio.Condition would have been the better choice. The easy solution was to check if the queue was empty and skip the read (get call) if there was nothing in the queue.

Before my fix, over a week the program would take up 10 Gigs of memory in our staging environment if nothing was touched, so I was assigned to investigate the cause. I think the current behavior is undesirable and cumbersome to see through, and if not changed there should be some kind of note in the documentation, so other good python folks will have a better chance to understand the behavior without reading the cpython asyncio queue implementation.

----------

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

From report at bugs.python.org  Mon Feb  1 12:50:09 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 01 Feb 2016 17:50:09 +0000
Subject: [issue26262] Cannot compile with /fp:strict with MSVC
Message-ID: <1454349009.19.0.118531537241.issue26262@psf.upfronthosting.co.za>


New submission from Zachary Ware:

As reported in msg258685 (issue25934), Python cannot be built with /fp:strict while using MSVC.  As Mark showed in msg258686 and msg258689, there are three calculations that could be replaced with suitable constants to allow /fp:strict to be used.

(Nosy list copied from #25934)

----------
components: Build, Windows
keywords: easy
messages: 259336
nosy: haypo, mark.dickinson, paul.moore, pitrou, python-dev, r.david.murray, serhiy.storchaka, skrah, steve.dower, tim.golden, tim.peters, zach.ware
priority: low
severity: normal
stage: needs patch
status: open
title: Cannot compile with /fp:strict with MSVC
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Mon Feb  1 12:52:08 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 01 Feb 2016 17:52:08 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1454349128.98.0.36468496655.issue25934@psf.upfronthosting.co.za>


Zachary Ware added the comment:

With the buildbots not angry over this, I'm closing the issue.  I opened #26262 to follow the possibility of changing the initializers to allow /fp:strict with MSVC.

----------
assignee:  -> zach.ware
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  1 12:57:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 01 Feb 2016 17:57:41 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
In-Reply-To: <1452865979.87.0.840611229209.issue26125@psf.upfronthosting.co.za>
Message-ID: <1454349461.04.0.269538335342.issue26125@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Victor committed this in 97c80e317ab8 (3.5) and c7f1acdd8be1 (default). Closing as "fixed".

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.4

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

From report at bugs.python.org  Mon Feb  1 13:11:32 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 01 Feb 2016 18:11:32 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454350292.1.0.0237856332352.issue26110@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Yury, thank you for the heads up! Here at Intel, in the Dynamic Scripting Languages Optimization Team, we can help the community with reviewing and measuring this patch in our quiet and stable environment, the same one that we use to provide public CPython daily measurements. We will wait for your update.

----------

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

From report at bugs.python.org  Mon Feb  1 13:38:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 01 Feb 2016 18:38:50 +0000
Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get
 is performed, without push to queue.
In-Reply-To: <1454347680.42.0.147949880695.issue26259@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ4ktpBOhi8OFEwmSbUQYfYtzwinu99UWOefL_3UorUsA@mail.gmail.com>


Guido van Rossum added the comment:

> The easy solution was to check if the queue was empty and skip the read (get call) if there was nothing in the queue.

There's an API for that -- get_nowait().

I'm happy to review a fix if you come up with one. But I currently
don't have time to devise a fix myself. (Not even a docfix, if you
think that's sufficient, but if you submit one it will swiftly be
applied.)

On Mon, Feb 1, 2016 at 9:28 AM, Jonas Brunsgaard <report at bugs.python.org> wrote:
>
> Jonas Brunsgaard added the comment:
>
> In my particular case, I developed an application close to beanstalkd, but with redis as "engine". I did create a callbackback reader class for users to subclass, the callbackreader is checking every second, on every tube(queue.Object). If new data has arrived for processing (this subroutine is using queue.get with wait_for). Maybe asyncio.Condition would have been the better choice. The easy solution was to check if the queue was empty and skip the read (get call) if there was nothing in the queue.
>
> Before my fix, over a week the program would take up 10 Gigs of memory in our staging environment if nothing was touched, so I was assigned to investigate the cause. I think the current behavior is undesirable and cumbersome to see through, and if not changed there should be some kind of note in the documentation, so other good python folks will have a better chance to understand the behavior without reading the cpython asyncio queue implementation.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26259>
> _______________________________________

----------

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

From report at bugs.python.org  Mon Feb  1 13:50:39 2016
From: report at bugs.python.org (Omer Katz)
Date: Mon, 01 Feb 2016 18:50:39 +0000
Subject: [issue26263] Serialize array.array to JSON by default
Message-ID: <1454352639.9.0.0979042510265.issue26263@psf.upfronthosting.co.za>


New submission from Omer Katz:

Is there a reason why the JSON module doesn't serialize array.array() instances by default?
Currently you need to convert them to tuples but I'm confident that the C API for those types is enough to iterate over the array and serialize it to a JSON list.
We should support serializing arrays by default in my opinion.

----------
components: Interpreter Core
messages: 259341
nosy: Omer.Katz
priority: normal
severity: normal
status: open
title: Serialize array.array to JSON by default
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Feb  1 14:00:46 2016
From: report at bugs.python.org (Mark Stern)
Date: Mon, 01 Feb 2016 19:00:46 +0000
Subject: [issue9779] argparse.ArgumentParser not support unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1454353246.23.0.69722439269.issue9779@psf.upfronthosting.co.za>


Mark Stern added the comment:

This bit me also. For anybody else reading this, argparsenobug.py includes a class that provides a workaround.

python argparsebug.py --help

works, but:

python argparsebug.py --help > <some file>
python argparsebug.py --help | more

give the error.

However:

python argparsenobug.py --help
python argparsenobug.py --help > <some file>
python argparsenobug.py --help | more

all work.

----------
nosy: +markastern
Added file: http://bugs.python.org/file41774/argparsebug.py

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

From report at bugs.python.org  Mon Feb  1 14:01:49 2016
From: report at bugs.python.org (Mark Stern)
Date: Mon, 01 Feb 2016 19:01:49 +0000
Subject: [issue9779] argparse.ArgumentParser not support unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1454353309.82.0.858687061961.issue9779@psf.upfronthosting.co.za>


Mark Stern added the comment:

And here is the source code with the workaround class

----------
Added file: http://bugs.python.org/file41775/argparsenobug.py

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

From report at bugs.python.org  Mon Feb  1 14:04:08 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 01 Feb 2016 19:04:08 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1454353448.78.0.612258028163.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching a new version of the patch.  Issues #26058 and #26110 need to be merged before we can start reviewing it.

----------
Added file: http://bugs.python.org/file41776/opcache2.patch

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

From report at bugs.python.org  Mon Feb  1 14:18:12 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 01 Feb 2016 19:18:12 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1454354292.49.0.33932992493.issue26219@psf.upfronthosting.co.za>


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


----------
hgrepos: +333

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

From report at bugs.python.org  Mon Feb  1 16:40:54 2016
From: report at bugs.python.org (neo gurb)
Date: Mon, 01 Feb 2016 21:40:54 +0000
Subject: [issue11597] Can't get ConfigParser.write to write unicode strings
In-Reply-To: <1300468084.29.0.517380899901.issue11597@psf.upfronthosting.co.za>
Message-ID: <1454362854.67.0.347731391298.issue11597@psf.upfronthosting.co.za>


neo gurb added the comment:

In file ConfigParser.py, def write, replace line

    key = " = ".join((key, str(value).replace('\n', '\n\t')))

by

    key = " = ".join((key, str(value).decode('utf-8').replace('\n', '\n\t')))

Tested in Windows7 and Ubuntu 15.04.

----------
nosy: +neo gurb

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

From report at bugs.python.org  Mon Feb  1 17:32:59 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Mon, 01 Feb 2016 22:32:59 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za>
Message-ID: <1454365979.71.0.453693844346.issue25958@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

> I did actually mean a version changed notice for the data model change. I see this as a small expansion of the Python object API. Previously, __reversed__() had to be a function, now you are also allowed to set it to None. The collections ABCs are just catching up with the API change.

Are you suggesting that in Python 3.5, it's not defined what happens if you set __reversed__ = None on a sequence-like object and then call reversed()? I think any implementation has to raise a TypeError; the only difference is that we're now documenting the behavior directly, rather than forcing you to infer it from reading a half-dozen different parts of the docs and tracing through the implied behavior. It's already the best way to do it in 3.5, or even 2.5; the problem is that it isn't _obviously_ the best way. And I think a version-changed would send the wrong message: someone might think, "Oh, I can't use None here because I can't require 3.6, so what should I do? Write a method that raises TypeError when called?" (Which will work, but will then make it very hard to write a Reversible implicit ABC if they later want to.)

> Imagine someone using an Orderable virtual base class that tested for __gt__() etc.

That's part of what we're trying to solve. Do you test that with hasattr, like Sized, or do you test for getattr with default None, like Hashable?

----------

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

From report at bugs.python.org  Mon Feb  1 19:00:42 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Tue, 02 Feb 2016 00:00:42 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1454371242.13.0.613039917246.issue25788@psf.upfronthosting.co.za>


Joseph Hackman added the comment:

I haven't seen OP in over 30 days, so am posting my own patch.

I've added an optional argument that defaults to strict and gets passed along.

I've updated the primary test to verify the argument passing, as well as that things get handled as specified in the documentation at https://docs.python.org/3.5/library/codecs.html

This is off-topic, but is there any way I can submit a patch that allows a similar fix for stdin? Presently there is no way at all to pass malformed unicode through fileinput using stdin that I can find.

----------
keywords: +patch
nosy: +Joseph Hackman
Added file: http://bugs.python.org/file41777/issue25788.patch

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

From report at bugs.python.org  Mon Feb  1 19:52:41 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 02 Feb 2016 00:52:41 +0000
Subject: [issue26254] ssl should raise an exception when trying to load an
 unusable key (ECC key not using a named curve)
In-Reply-To: <1454291417.3.0.6306970178.issue26254@psf.upfronthosting.co.za>
Message-ID: <1454374361.7.0.27292641905.issue26254@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

So, it looks like OpenSSL doesn't support keys using arbitrary curves at all. Then why don't I get an exception when trying to load such a key? Instead it just quietly disables all authenticated ciphersuites (anonymous ciphersuites still work) and then I get a confusing exception about lack of shared ciphers. I think that if it can't use a key, it should raise an exception right away.

----------
resolution: not a bug -> 
status: closed -> open
title: ssl server doesn't work with ECC certificates -> ssl should raise an exception when trying to load an unusable key (ECC key not using a named curve)

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

From report at bugs.python.org  Mon Feb  1 21:06:26 2016
From: report at bugs.python.org (Timo Furrer)
Date: Tue, 02 Feb 2016 02:06:26 +0000
Subject: [issue26264] keyword.py missing async await
Message-ID: <1454378786.53.0.925531991818.issue26264@psf.upfronthosting.co.za>


New submission from Timo Furrer:

I had a look at the *Lib/keyword.py* module. It seems like the auto generated *kwlist* is missing the *await* and *async* keywords.
At least according to https://www.python.org/dev/peps/pep-0492/ they are called *keywords*. 

The keyword module generates the *kwlist* from *Python/graminit.c*.

----------
components: Library (Lib)
messages: 259349
nosy: tuxtimo
priority: normal
severity: normal
status: open
title: keyword.py missing async await
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Feb  1 21:06:41 2016
From: report at bugs.python.org (Timo Furrer)
Date: Tue, 02 Feb 2016 02:06:41 +0000
Subject: [issue26264] keyword module missing async and await keywords
In-Reply-To: <1454378786.53.0.925531991818.issue26264@psf.upfronthosting.co.za>
Message-ID: <1454378801.0.0.392114989717.issue26264@psf.upfronthosting.co.za>


Changes by Timo Furrer <tuxtimo at gmail.com>:


----------
title: keyword.py missing async await -> keyword module missing async and await keywords

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

From report at bugs.python.org  Mon Feb  1 21:08:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 02:08:46 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za>
Message-ID: <1454378926.05.0.0810086900011.issue25958@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is not really my area of expertise, but I would have thought if you defined a __special__ method to something illegal (non-callable, or wrong signature) it would be reasonable for Python to raise an error at class definition (or assignment) time, not just later when you try to use it. Somewhere I think the documentation says you are only allowed to use these names as documented.

----------

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

From report at bugs.python.org  Mon Feb  1 21:11:47 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Tue, 02 Feb 2016 02:11:47 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454379107.39.0.940842897352.issue26110@psf.upfronthosting.co.za>


Changes by Eric Fahlgren <ericfahlgren at gmail.com>:


----------
nosy: +eric.fahlgren

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

From report at bugs.python.org  Mon Feb  1 21:25:57 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 02 Feb 2016 02:25:57 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za>
Message-ID: <1454379957.15.0.525217998962.issue25958@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

> This is not really my area of expertise, but I would have thought if you defined a __special__ method to something illegal (non-callable, or wrong signature) it would be reasonable for Python to raise an error at class definition (or assignment) time, not just later when you try to use it.

As Guido pointed out on the -ideas thread, defining __spam__ = None to block inheritance of a superclass implementation has long been the standard way to mark a class unhashable. So, any Python that raised such an error would break a lot of code. 

> Somewhere I think the documentation says you are only allowed to use these names as documented.

I can't find anything that says that. Any idea where to look? That might be worth adding, but if we add it at the same time as (or after) we explicitly document the None behavior, that's not a problem. :)

By the way, did you not review my last patch because you didn't get an email for it? I think Rietveld #439 (http://psf.upfronthosting.co.za/roundup/meta/issue439) may be causing issues to get stalled in the patch stage because people are expecting to get flagged when a new patch goes up but never see it (unless they're on the same mail domain as the patcher).

----------

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

From report at bugs.python.org  Mon Feb  1 21:37:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 02:37:34 +0000
Subject: [issue26261] NamedTemporaryFile documentation is vague about the
 `name` attribute
In-Reply-To: <1454347282.51.0.892341568817.issue26261@psf.upfronthosting.co.za>
Message-ID: <1454380654.96.0.788823975521.issue26261@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also the doc string could be updated. I guess suggesting ?file.name? is even more confusing :)

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Feb  1 21:56:11 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 02:56:11 +0000
Subject: [issue26264] keyword module missing async and await keywords
In-Reply-To: <1454378786.53.0.925531991818.issue26264@psf.upfronthosting.co.za>
Message-ID: <1454381771.95.0.297277779531.issue26264@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

`async` and `await` are only keywords in the context of an 'async def' function.  It will be that way until Python 3.7.  That said, I'm not sure what to do about the keywords module.

Nick, Victor, thoughts?

----------
nosy: +haypo, ncoghlan, yselivanov

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

From report at bugs.python.org  Mon Feb  1 22:07:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 03:07:54 +0000
Subject: [issue26264] keyword module missing async and await keywords
In-Reply-To: <1454378786.53.0.925531991818.issue26264@psf.upfronthosting.co.za>
Message-ID: <1454382474.57.0.218602261556.issue26264@psf.upfronthosting.co.za>


Martin Panter added the comment:

What happened in cases like ?with? and ?yield?, when these names were turned into reserved keywords depending on a __future__ statement?

----------
nosy: +martin.panter

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

From report at bugs.python.org  Mon Feb  1 22:18:12 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 02 Feb 2016 03:18:12 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1454379957.15.0.525217998962.issue25958@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJE=+rg5jT72z_LMct-fX4WW3ginSUoL2JR93L8ip9Okw@mail.gmail.com>


Guido van Rossum added the comment:

> This is not really my area of expertise, but I would have thought if you defined a __special__ method to something illegal (non-callable, or wrong signature) it would be reasonable for Python to raise an error at class definition (or assignment) time, not just later when you try to use it.

No, that's not the intention.

> Somewhere I think the documentation says you are only allowed to use these names as documented.

Indeed, but it's not enforced. What it means is that when the next
release of Python (or a different implementation) changes the meaning
of a __special__ name, you can't complain that your code broke.

(And please don't go suggesting that we start enforcing it.)

----------

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

From report at bugs.python.org  Tue Feb  2 00:01:19 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Feb 2016 05:01:19 +0000
Subject: [issue26255] symtable.Symbol.is_referenced() returns false for valid
 use
In-Reply-To: <1454320625.23.0.218294172463.issue26255@psf.upfronthosting.co.za>
Message-ID: <1454389279.3.0.0821541614504.issue26255@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The genexp implicitly creates a nested function in which *code* is referenced.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Tue Feb  2 00:01:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 05:01:46 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za>
Message-ID: <1454389306.46.0.653507715694.issue25958@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation about double-underscore names: <https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers>. It says any undocumented usage may be broken. The technique with __hash__() is already documented: <https://docs.python.org/3/reference/datamodel.html#object.__hash__>.

I have seen your 5th patch, and do appreciate the new improvements. (I think I did see an email for it. But a while ago G Mail started treating a lot of stuff as spam until I made a special rule for bug tracker emails.)

----------

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

From report at bugs.python.org  Tue Feb  2 00:12:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 05:12:10 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <1454389930.97.0.520882044452.issue26243@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks, it looks good to me. I think ?data? is a better name than ?bytes?.

About What?s New, I thought the general idea was to document all enhancements, though I admit this is about as small as they come. There is precedent with the compile() builtin (Issue 1444529, Python 2.6), although there is no indication of kwargs in the main documentation for compile(). But on the other hand, str.split() didn?t get any What?s New entry (Issue 14081, Python 3.3). See also <https://docs.python.org/devguide/committing.html#what-s-new-and-news-entries>.

----------

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

From report at bugs.python.org  Tue Feb  2 00:21:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Feb 2016 05:21:53 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <20160202052148.77415.78600@psf.io>


Roundup Robot added the comment:

New changeset 7dabb94bdf63 by Raymond Hettinger in branch '3.5':
Issue #26194:  Inserting into a full deque to raise an IndexError
https://hg.python.org/cpython/rev/7dabb94bdf63

----------

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

From report at bugs.python.org  Tue Feb  2 00:22:14 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Feb 2016 05:22:14 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454390534.24.0.380688088572.issue26194@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Feb  2 00:23:42 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Feb 2016 05:23:42 +0000
Subject: [issue25945] Type confusion in partial_setstate and partial_call
 leads to memory corruption
In-Reply-To: <1451017001.94.0.489150526382.issue25945@psf.upfronthosting.co.za>
Message-ID: <1454390622.83.0.898177325963.issue25945@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This looks correct.

----------
assignee: rhettinger -> serhiy.storchaka

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

From report at bugs.python.org  Tue Feb  2 00:41:34 2016
From: report at bugs.python.org (lirenke)
Date: Tue, 02 Feb 2016 05:41:34 +0000
Subject: [issue26238] httplib use wrong hostname in https request with SNI
 support
In-Reply-To: <1454070946.61.0.657909359351.issue26238@psf.upfronthosting.co.za>
Message-ID: <1454391694.23.0.933291617418.issue26238@psf.upfronthosting.co.za>


lirenke added the comment:

In RFC6066, literal IPv4 is not allowed as hostname indeed. Actually, many requests still use the format of "IP+PORT" to access the server, and it seems Python don't prohibit this action explicitly. The explorer Chrome also use literal IP address to access for instance.

In our case, all requests will be forwarded by apacheproxy and there is another apache server that receiving them. The URL is like "https://128.6.42.21:8088/xx/", and the SNI will be added by OpenSSL in TLS-handshake packet when new https connection create. In this time, "128.6.42.21:8088" is set to self._tunnel_host in set_tunnel(), then, the server_hostname, as SNI, is determined.

The Server side's apache will check the SNI between handshake packet and local vHost configuration. So it is the place where mismatch happen. Error Code 400, Bad Request will return to client.<https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI>
 
Definitely, port number shouldn't be a part of SNI. Compare with Chrome do, we hope Python could handle the server_hostname precisely too. Calling self._get_hostport() again and setting the IP address to server_hostname without port number is our suggestion.

----------

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

From report at bugs.python.org  Tue Feb  2 00:59:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Feb 2016 05:59:16 +0000
Subject: [issue24421] Race condition compiling Modules/_math.c
In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za>
Message-ID: <20160202055913.16548.44716@psf.io>


Roundup Robot added the comment:

New changeset 76624d47ee99 by Martin Panter in branch 'default':
Issue #24421: Compile _math.c separately to avoid race condition
https://hg.python.org/cpython/rev/76624d47ee99

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  2 01:26:48 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Tue, 02 Feb 2016 06:26:48 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454394408.99.0.887103387774.issue26229@psf.upfronthosting.co.za>


Anders Rundgren added the comment:

An easier fix than mucking around in the pretty complex number serializer code would be adding an "ES6Format" option to the "json.dump*" methods which could use the supplied conversion code as is.

For JSON parsing in an ES6-compatible way you must anyway use an "OrderedDict" hook option to get the right (=original) property order.

----------

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

From report at bugs.python.org  Tue Feb  2 01:36:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 06:36:15 +0000
Subject: [issue26238] httplib use wrong hostname in https request with SNI
 support
In-Reply-To: <1454070946.61.0.657909359351.issue26238@psf.upfronthosting.co.za>
Message-ID: <1454394975.75.0.615140499253.issue26238@psf.upfronthosting.co.za>


Martin Panter added the comment:

I still cannot reproduce any problem. When using set_tunnel(), this is the request sent to the proxy:

b'CONNECT 128.6.42.21:8088 HTTP/1.0\r\n'
b'\r\n'

This is the SNI and request sent through the proxy to the end server:

>>> wrapped = context.wrap_socket(conn, server_side=True)
Requested server name '128.6.42.21'
>>> for line in wrapped.recv(3000).splitlines(keepends=True): print(repr(line))... 
b'GET /xx/ HTTP/1.1\r\n'
b'Host: 128.6.42.21:8088\r\n'
b'Accept-Encoding: identity\r\n'
b'\r\n'

Can you please provide some code that demonstrates your problem.

----------

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

From report at bugs.python.org  Tue Feb  2 02:25:50 2016
From: report at bugs.python.org (lirenke)
Date: Tue, 02 Feb 2016 07:25:50 +0000
Subject: [issue26238] httplib use wrong hostname in https request with SNI
 support
In-Reply-To: <1454070946.61.0.657909359351.issue26238@psf.upfronthosting.co.za>
Message-ID: <1454397950.93.0.584716174605.issue26238@psf.upfronthosting.co.za>


lirenke added the comment:

We use Python 2.7.9, and I have checked the httplib.py in 2.7.11 version same time. Notice that in set_tunnel(), self._tunnel_host have already updated by calling _get_hostport(), just like you said. It's different between 2.7.9 and 2.7.11.

Then, I replace the file and retry, the problem is gone. Maybe this is an fixed bug before which I don't notice.

I think it's time to upgrade python for us...
Thank you for your remind and help, Martin.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Feb  2 02:30:48 2016
From: report at bugs.python.org (lirenke)
Date: Tue, 02 Feb 2016 07:30:48 +0000
Subject: [issue26238] httplib use wrong hostname in https request with SNI
 support
In-Reply-To: <1454070946.61.0.657909359351.issue26238@psf.upfronthosting.co.za>
Message-ID: <1454398248.11.0.955897342199.issue26238@psf.upfronthosting.co.za>


Changes by lirenke <lvhancy at 163.com>:


----------
resolution:  -> fixed

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

From report at bugs.python.org  Tue Feb  2 02:43:31 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Feb 2016 07:43:31 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454399011.27.0.582691660073.issue26229@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> For JSON parsing in an ES6-compatible way you must anyway use an "OrderedDict" hook option to get the right (=original) property order.

Why? From the JSON spec: "An object is an *unordered* set of name/value pairs." (emphasis mine). What do you mean by "JSON parsing in an ES6-compatible way"? Surely the JSON specification is all that should matter when determining how to parse JSON?

----------

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

From report at bugs.python.org  Tue Feb  2 02:52:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Feb 2016 07:52:41 +0000
Subject: [issue26244] zlib.compressobj level default value documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <20160202075238.20013.2800@psf.io>


Roundup Robot added the comment:

New changeset 650cf38fba28 by Martin Panter in branch '2.7':
Issue #26244: Clarify default zlib compression level in documentation
https://hg.python.org/cpython/rev/650cf38fba28

New changeset 950e0bfe94ae by Martin Panter in branch '3.5':
Issue #26244: Clarify default zlib compression level in documentation
https://hg.python.org/cpython/rev/950e0bfe94ae

New changeset 03708c680eca by Martin Panter in branch 'default':
Issue #26244: Merge zlib documentation from 3.5
https://hg.python.org/cpython/rev/03708c680eca

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  2 03:16:21 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Feb 2016 08:16:21 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454400981.39.0.253201546695.issue26229@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> An easier fix than mucking around in the pretty complex number serializer
> code would be adding an "ES6Format" option to the "json.dump*" methods
> which could use the supplied conversion code as is.

Certainly if this were added we'd want to do it in a backwards compatible way; adding (yet) another flag to the json.dump* methods is one possibility.

----------

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

From report at bugs.python.org  Tue Feb  2 03:24:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 08:24:48 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454401488.67.0.821649967227.issue26194@psf.upfronthosting.co.za>


Martin Panter added the comment:

FYI Raymond, your revision 0731f097157b didn?t actually merge the 3.5 branch (It only had one parent). Also, the default branch never got any NEWS entry in 58266f5101cc, so maybe it needs to be added?

----------
nosy: +martin.panter

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

From report at bugs.python.org  Tue Feb  2 03:25:10 2016
From: report at bugs.python.org (Florin Papa)
Date: Tue, 02 Feb 2016 08:25:10 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454401510.19.0.79083421468.issue26110@psf.upfronthosting.co.za>


Changes by Florin Papa <florin.papa at intel.com>:


----------
nosy: +florin.papa

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

From report at bugs.python.org  Tue Feb  2 03:40:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 08:40:09 +0000
Subject: [issue26233] select.epoll.poll() should avoid calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1454402409.63.0.454722705329.issue26233@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Yury, Serhiy: Do you think that it's worth to avoid malloc in epoll? Aside of the performance, my colleague also told me that heavy pressure on the memory allocator can slowly create framgmentation of the heap memory, which is true.

----------

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

From report at bugs.python.org  Tue Feb  2 03:47:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 08:47:08 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1454402828.11.0.311353578522.issue26219@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm concerned by the test_descr failure.

======================================================================
ERROR: test_vicious_descriptor_nonsense (test.test_descr.ClassPropertiesAndMethods)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_descr.py", line 4176, in test_vicious_descriptor_nonsense
    self.assertEqual(c.attr, 1)
AttributeError: 'C' object has no attribute 'attr'

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


======================================================================
FAIL: test_objecttypes (test.test_sys.SizeofTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 895, in test_objecttypes
    check(get_cell().__code__, size('5i9Pi3P'))
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1475, in check_sizeof
    test.assertEqual(result, size, msg)
AssertionError: 192 != 160 : wrong size for <class 'code'>: got 192, expected 160

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


======================================================================
FAIL: test_pycfunction (test.test_gdb.PyBtTests)
Verify that "py-bt" displays invocations of PyCFunction instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_gdb.py", line 857, in test_pycfunction
    self.assertIn('#0 <built-in method gmtime', gdb_output)
AssertionError: '#0 <built-in method gmtime' not found in 'Breakpoint 1 at 0x6518e3: file ./Modules/timemodule.c, line 338.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n\nBreakpoint 1, time_gmtime (self=<module at remote 0x7ffff7e6ff58>, args=(1,)) at ./Modules/timemodule.c:338\n338\t    if (!parse_time_t_args(args, "|O:gmtime", &when))\n#1 <built-in method gmtime of module object at remote 0x7ffff7e6ff58>\n#4 Frame 0x7ffff7fb27b8, for file <string>, line 3, in foo ()\n#7 Frame 0x7ffff7f423f8, for file <string>, line 5, in bar ()\n#10 Frame 0x7ffff7fb25e0, for file <string>, line 6, in <module> ()\n'

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

----------

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

From report at bugs.python.org  Tue Feb  2 04:42:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 09:42:03 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454406123.84.0.707096473359.issue26194@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> FYI Raymond, your revision 0731f097157b didn?t actually merge the 3.5 branch (It only had one parent). Also, the default branch never got any NEWS entry in 58266f5101cc, so maybe it needs to be added?

Maybe it's also worth to document the change in Python 3.5 and 3.6 documentation with a ".. versionchanged::"?
https://docs.python.org/dev/library/collections.html#deque-objects

It can be suprising to get a different behaviour between two bugfix versions (Python 3.5.1 and 3.5.2). I'm not saying that we must not fix bugs, just that it helps users to document them :-)

It will also avoid bug reports about this behaviour change. Example of user report: issue #26260, "it works on Python 2 but no more on Python 3" ;-)

----------

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

From report at bugs.python.org  Tue Feb  2 04:57:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 09:57:19 +0000
Subject: [issue26244] zlib.compressobj level default value documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <1454407039.13.0.273700788165.issue26244@psf.upfronthosting.co.za>


Martin Panter added the comment:

I also made a small change to the compressobj() doc string.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  2 05:25:50 2016
From: report at bugs.python.org (Jonas Brunsgaard)
Date: Tue, 02 Feb 2016 10:25:50 +0000
Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get
 is performed, without push to queue.
In-Reply-To: <1454342780.58.0.210365622359.issue26259@psf.upfronthosting.co.za>
Message-ID: <1454408750.3.0.262967898093.issue26259@psf.upfronthosting.co.za>


Jonas Brunsgaard added the comment:

You are right that get_nowait() is the correct api for my use case, using get_nowait() nothing is pushed to the internal _getters deque. The reason for my us of get() is that job futures are created one place in the code and then thrown in a processing function that will yield the job future. This design was created to handle all exceptions in processing(), but I agree that get_nowait would have been the superior solution.

I do not have time on my hands right now to take on the challenge of writing a patch, but I might take it up later, sound fun ;)

Good day to you sir, and thank you for the feedback.

----------

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

From report at bugs.python.org  Tue Feb  2 05:39:11 2016
From: report at bugs.python.org (Anish Shah)
Date: Tue, 02 Feb 2016 10:39:11 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1454409551.67.0.768562876338.issue24780@psf.upfronthosting.co.za>


Anish Shah added the comment:

I would like to work on this..

----------
nosy: +anish.shah

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

From report at bugs.python.org  Tue Feb  2 06:06:14 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2016 11:06:14 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454411174.94.0.36805748.issue26249@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hum, the point of PyMem_Malloc() is that it's distinct from PyObject_Malloc(), right? Why would you redirect one to the other?

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Feb  2 06:06:53 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2016 11:06:53 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454411213.51.0.405014428584.issue26249@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(of course, we might question why we have two different families of allocation APIs...)

----------

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

From report at bugs.python.org  Tue Feb  2 06:10:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 11:10:45 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454411445.91.0.933604026266.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Hum, the point of PyMem_Malloc() is that it's distinct from PyObject_Malloc(), right? Why would you redirect one to the other?

For performances.

> (of course, we might question why we have two different families of allocation APIs...)

That's the real question: why does Python have PyMem family? Is it still justified in 2016?

--

Firefox uses jemalloc to limit the fragmentation of the heap memory. Once I spent a lot of time to try to understand the principle of fragmentation, and in my tiny benchmarks, jemalloc was *much* better than system allocator. By the way, jemalloc scales well on multiple threads ;-)

* http://www.canonware.com/jemalloc/
* https://github.com/jemalloc/jemalloc/wiki

My notes on heap memory fragmentation: http://haypo-notes.readthedocs.org/heap_fragmentation.html

----------

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

From report at bugs.python.org  Tue Feb  2 06:12:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 11:12:45 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454411565.75.0.389834422597.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

About heap memory fragmentation, see also my attached two "benchmarks" in Python and C: python_memleak.py and tu_malloc.c.

----------
Added file: http://bugs.python.org/file41778/python_memleak.py

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

From report at bugs.python.org  Tue Feb  2 06:12:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 11:12:50 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454411570.74.0.49134928762.issue26249@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file41779/tu_malloc.c

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

From report at bugs.python.org  Tue Feb  2 06:33:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 11:33:17 +0000
Subject: =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor=E2=80=99s_flus?=
 =?utf-8?q?h=28=29_method?=
In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>
Message-ID: <1454412797.64.0.518266909584.issue23200@psf.upfronthosting.co.za>


Martin Panter added the comment:

New version of the patch merged with current code and cleaning up the zipfile EOF detection.

----------
Added file: http://bugs.python.org/file41780/deprecate-flush.v2.patch

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

From report at bugs.python.org  Tue Feb  2 06:34:20 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 02 Feb 2016 11:34:20 +0000
Subject: [issue26263] Serialize array.array to JSON by default
In-Reply-To: <1454352639.9.0.0979042510265.issue26263@psf.upfronthosting.co.za>
Message-ID: <1454412860.7.0.466015954745.issue26263@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components: +Extension Modules -Interpreter Core
nosy: +ezio.melotti, pitrou, rhettinger

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

From report at bugs.python.org  Tue Feb  2 06:54:07 2016
From: report at bugs.python.org (Anish Shah)
Date: Tue, 02 Feb 2016 11:54:07 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454414047.28.0.660516286127.issue26136@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Tue Feb  2 06:56:32 2016
From: report at bugs.python.org (Florin Papa)
Date: Tue, 02 Feb 2016 11:56:32 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1454414191.99.0.540232363974.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi all,

Our latest effort on enabling MPX in CPython has concentrated around eliminating all INIT_BOUNDS and BND_LEGACY attributes that are used to bypass bounds checking for certain pointers. In order to avoid using these attributes, we needed to find and fix the root cause of the problems. The main issue was represented by the small object allocator (Objects/obmalloc.c), which was performing some operations that MPX considered unsafe (pointer jumping). A similar problem was found in the allocator used by the garbage collection module (Modules/gcmodule.c). These issues, as well as other minor operations considered unsafe by MPX (Objects/listobject.c, Objects/dictobject.c) have been addressed so far.

As a result, we were able to eliminate all INIT_BOUNDS and BND_LEGACY attributes from the code. Also, we identified the optimization flag that caused crashes when compiling with ?O3, which is ?fipa-icf. Compiling with ?-O3 ?fno-ipa-icf? now works fine. The entire regrtest suite passes, except test_capi and test_faulthandler. Test_capi fails because of a ?\n? outputted by the MPX runtime at stdout instead of stderr (fixed in the GCC 6 trunk). Test_faulthandler fails because we have disabled the faulthandler module when MPX is active, as it produced crashes since both the faulthandler and the MPX runtime overwrite the default SIGSEGV handler and the new handlers would interfere with each other.

The current patch works on GCC 5.3.0, which solves a linking problem with libmpx, present in GCC 5.2.1. We still have some problems, such as bounds warnings that only appear once in 10 runs for a few of the tests, but do not cause crashes or failed tests. The biggest problem we face is the presence of pointers that do not have bounds. These could be the result of some bugs we found in MPX:

    1. Calling strlen and memset (possibly others) for the first time in a program will not be subject to MPX checks
    2.Copying an array of pointers to a new location will reset the first pointer?s bounds (deep copy of the pointer bounds fails)
The first problem was solved by upgrading ldd to version 2.22, while the second issue will be solved by the GCC 6 release (around April 2016), which will offer more stable support for MPX.

Therefore, we have decided to wait until the GCC 6 release to provide a final version of the MPX patch for CPython. Meanwhile, you can see the latest modifications we have made in the patch attached.

Thank you,
Florin Papa

----------
Added file: http://bugs.python.org/file41781/mpx_enable_3_6_v7.patch

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

From report at bugs.python.org  Tue Feb  2 07:00:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 12:00:31 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454414431.96.0.548010021187.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

So, I ran ssh://hg at hg.python.org/benchmarks with my patch. It looks like some benchmarks are up to 4% faster:

$ python3 -u perf.py ../default/python.orig ../default/python.pymem

INFO:root:Automatically selected timer: perf_counter
[ 1/10] 2to3...
INFO:root:Running `../default/python.pymem lib3/2to3/2to3 -f all lib/2to3`
INFO:root:Running `../default/python.pymem lib3/2to3/2to3 -f all lib/2to3` 1 time
INFO:root:Running `../default/python.orig lib3/2to3/2to3 -f all lib/2to3`
INFO:root:Running `../default/python.orig lib3/2to3/2to3 -f all lib/2to3` 1 time
[ 2/10] chameleon_v2...
INFO:root:Running `../default/python.pymem performance/bm_chameleon_v2.py -n 50 --timer perf_counter`
INFO:root:Running `../default/python.orig performance/bm_chameleon_v2.py -n 50 --timer perf_counter`
[ 3/10] django_v3...
INFO:root:Running `../default/python.pymem performance/bm_django_v3.py -n 50 --timer perf_counter`
INFO:root:Running `../default/python.orig performance/bm_django_v3.py -n 50 --timer perf_counter`
[ 4/10] fastpickle...
INFO:root:Running `../default/python.pymem performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle pickle`
INFO:root:Running `../default/python.orig performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle pickle`
[ 5/10] fastunpickle...
INFO:root:Running `../default/python.pymem performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle unpickle`
INFO:root:Running `../default/python.orig performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle unpickle`
[ 6/10] json_dump_v2...
INFO:root:Running `../default/python.pymem performance/bm_json_v2.py -n 50 --timer perf_counter`
INFO:root:Running `../default/python.orig performance/bm_json_v2.py -n 50 --timer perf_counter`
[ 7/10] json_load...
INFO:root:Running `../default/python.pymem performance/bm_json.py -n 50 --timer perf_counter json_load`
INFO:root:Running `../default/python.orig performance/bm_json.py -n 50 --timer perf_counter json_load`
[ 8/10] nbody...
INFO:root:Running `../default/python.pymem performance/bm_nbody.py -n 50 --timer perf_counter`
INFO:root:Running `../default/python.orig performance/bm_nbody.py -n 50 --timer perf_counter`
[ 9/10] regex_v8...
INFO:root:Running `../default/python.pymem performance/bm_regex_v8.py -n 50 --timer perf_counter`
INFO:root:Running `../default/python.orig performance/bm_regex_v8.py -n 50 --timer perf_counter`
[10/10] tornado_http...
INFO:root:Running `../default/python.pymem performance/bm_tornado_http.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python.orig performance/bm_tornado_http.py -n 100 --timer perf_counter`

Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### 2to3 ###
6.880090 -> 6.818911: 1.01x faster

### fastpickle ###
Min: 0.453826 -> 0.442081: 1.03x faster
Avg: 0.456499 -> 0.443978: 1.03x faster
Significant (t=20.03)
Stddev: 0.00370 -> 0.00242: 1.5293x smaller

### fastunpickle ###
Min: 0.547908 -> 0.526027: 1.04x faster
Avg: 0.554663 -> 0.528686: 1.05x faster
Significant (t=15.95)
Stddev: 0.00893 -> 0.00728: 1.2260x smaller

### json_dump_v2 ###
Min: 2.733907 -> 2.627718: 1.04x faster
Avg: 2.762473 -> 2.664675: 1.04x faster
Significant (t=11.99)
Stddev: 0.03796 -> 0.04341: 1.1435x larger

### regex_v8 ###
Min: 0.042438 -> 0.042581: 1.00x slower
Avg: 0.042805 -> 0.044078: 1.03x slower
Significant (t=-2.12)
Stddev: 0.00171 -> 0.00388: 2.2694x larger

### tornado_http ###
Min: 0.254089 -> 0.246088: 1.03x faster
Avg: 0.257046 -> 0.249033: 1.03x faster
Significant (t=15.83)
Stddev: 0.00401 -> 0.00310: 1.2930x smaller

The following not significant results are hidden, use -v to show them:
chameleon_v2, django_v3, json_load, nbody.

real	19m13.413s
user	18m50.024s
sys	0m22.507s

----------

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

From report at bugs.python.org  Tue Feb  2 08:17:09 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 13:17:09 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454414431.96.0.548010021187.issue26249@psf.upfronthosting.co.za>
Message-ID: <9C8DF64D-0855-4858-BC92-BABC77E2F3C3@gmail.com>


Yury Selivanov added the comment:

> On Feb 2, 2016, at 7:00 AM, STINNER Victor <report at bugs.python.org> wrote:
> 
> So, I ran ssh://hg at hg.python.org/benchmarks with my patch. It looks like some benchmarks are up to 4% faster:

Please use -r flag for perf.py

----------
nosy: +Yury.Selivanov

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

From report at bugs.python.org  Tue Feb  2 08:20:34 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 02 Feb 2016 13:20:34 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454419234.06.0.99787308386.issue26110@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
nosy: +ebarry

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

From report at bugs.python.org  Tue Feb  2 08:28:11 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2016 13:28:11 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454419691.29.0.227889235897.issue26249@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> It looks like some benchmarks are up to 4% faster:

What this says is that some internals uses of PyMem_XXX should be replaced with PyObject_XXX.

----------

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

From report at bugs.python.org  Tue Feb  2 08:40:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 13:40:35 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454420435.66.0.476821586679.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI benchmark result to compare Python with and without pymalloc (fast memory allocator for block <= 512 bytes). As expected, no pymalloc is slower, up to 30% slower (and it's never faster).

Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### 2to3 ###
7.253671 -> 7.558993: 1.04x slower

### chameleon_v2 ###
Min: 5.598481 -> 5.794526: 1.04x slower
Avg: 5.714233 -> 5.922142: 1.04x slower
Significant (t=-8.01)
Stddev: 0.15956 -> 0.09048: 1.7636x smaller

### django_v3 ###
Min: 0.574221 -> 0.606462: 1.06x slower
Avg: 0.579659 -> 0.612088: 1.06x slower
Significant (t=-28.44)
Stddev: 0.00605 -> 0.00532: 1.1371x smaller

### fastpickle ###
Min: 0.450852 -> 0.502645: 1.11x slower
Avg: 0.455619 -> 0.513777: 1.13x slower
Significant (t=-26.24)
Stddev: 0.00696 -> 0.01404: 2.0189x larger

### fastunpickle ###
Min: 0.544064 -> 0.696306: 1.28x slower
Avg: 0.552459 -> 0.705372: 1.28x slower
Significant (t=-85.52)
Stddev: 0.00798 -> 0.00980: 1.2281x larger

### json_dump_v2 ###
Min: 2.780312 -> 3.265531: 1.17x slower
Avg: 2.830463 -> 3.370060: 1.19x slower
Significant (t=-23.73)
Stddev: 0.04190 -> 0.15521: 3.7046x larger

### json_load ###
Min: 0.428893 -> 0.558956: 1.30x slower
Avg: 0.431941 -> 0.569441: 1.32x slower
Significant (t=-74.76)
Stddev: 0.00791 -> 0.01033: 1.3060x larger

### regex_v8 ###
Min: 0.043439 -> 0.044614: 1.03x slower
Avg: 0.044388 -> 0.046487: 1.05x slower
Significant (t=-4.95)
Stddev: 0.00215 -> 0.00209: 1.0283x smaller

### tornado_http ###
Min: 0.264603 -> 0.278840: 1.05x slower
Avg: 0.270153 -> 0.285263: 1.06x slower
Significant (t=-23.04)
Stddev: 0.00489 -> 0.00436: 1.1216x smaller

The following not significant results are hidden, use -v to show them:
nbody.

----------

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

From report at bugs.python.org  Tue Feb  2 08:45:14 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 02 Feb 2016 13:45:14 +0000
Subject: [issue26188] Provide more helpful error message when `await` is
 called inside non-`async` method
In-Reply-To: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za>
Message-ID: <1454420714.52.0.0223145837611.issue26188@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Related discussions about providing more helpful syntax error messages:

* http://bugs.python.org/issue1634034
* http://bugs.python.org/issue400734
* http://bugs.python.org/issue20608

>From the discussion on issue1634034, it looks like providing better messages in the general case of a syntax error is quite difficult. But perhaps in limited cases like this one we can do better.

Parsers are a bit over my head. Martin, is it difficult to distinguish between `await` as a regular name and `await` as a special token?

----------

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

From report at bugs.python.org  Tue Feb  2 08:46:17 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 02 Feb 2016 13:46:17 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1454420777.28.0.582135408717.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Great, how do we ensure this gets merged soon?

----------

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

From report at bugs.python.org  Tue Feb  2 09:13:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 02 Feb 2016 14:13:45 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <1454422425.76.0.0366666413517.issue26243@psf.upfronthosting.co.za>


Berker Peksag added the comment:

There is an outdated patch in issue 16764 for zlib.compress(), zlib.decompress(), zlib.flush() and other functions. Perhaps we can close it as a duplicate of this one.

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Tue Feb  2 09:25:48 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 02 Feb 2016 14:25:48 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1454423148.17.0.634043987782.issue25788@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage: needs patch -> patch review

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

From report at bugs.python.org  Tue Feb  2 09:47:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 14:47:27 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454424447.48.0.749884702566.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Test with jemalloc using the shell script "python.jemalloc":
---
#!/bin/sh
LD_PRELOAD=/usr/lib64/libjemalloc.so /home/haypo/prog/python/default/python "$@"
---

Memory consumption:
python3 -u perf.py -m ../default/python ../default/python.jemalloc

Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### 2to3 ###
Mem max: 43100.000 -> 220.000: 195.9091x smaller

### chameleon_v2 ###
Mem max: 367276.000 -> 224.000: 1639.6250x smaller

### django_v3 ###
Mem max: 24136.000 -> 284.000: 84.9859x smaller

### fastpickle ###
Mem max: 8692.000 -> 284.000: 30.6056x smaller

### fastunpickle ###
Mem max: 8704.000 -> 216.000: 40.2963x smaller

### json_dump_v2 ###
Mem max: 10448.000 -> 216.000: 48.3704x smaller

### json_load ###
Mem max: 8444.000 -> 220.000: 38.3818x smaller

### nbody ###
Mem max: 7388.000 -> 220.000: 33.5818x smaller

### regex_v8 ###
Mem max: 12764.000 -> 220.000: 58.0182x smaller

### tornado_http ###
Mem max: 28216.000 -> 228.000: 123.7544x smaller



****

Performance:

Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### 2to3 ###
7.413484 -> 7.189792: 1.03x faster

### chameleon_v2 ###
Min: 5.559697 -> 5.869468: 1.06x slower
Avg: 5.672448 -> 6.033152: 1.06x slower
Significant (t=-13.67)
Stddev: 0.12098 -> 0.14203: 1.1740x larger

### nbody ###
Min: 0.242194 -> 0.229747: 1.05x faster
Avg: 0.244991 -> 0.235297: 1.04x faster
Significant (t=9.75)
Stddev: 0.00262 -> 0.00652: 2.4861x larger

### regex_v8 ###
Min: 0.042532 -> 0.046920: 1.10x slower
Avg: 0.043249 -> 0.047907: 1.11x slower
Significant (t=-13.23)
Stddev: 0.00180 -> 0.00172: 1.0503x smaller

### tornado_http ###
Min: 0.265755 -> 0.274526: 1.03x slower
Avg: 0.273617 -> 0.284186: 1.04x slower
Significant (t=-6.67)
Stddev: 0.00583 -> 0.01474: 2.5297x larger

The following not significant results are hidden, use -v to show them:
django_v3, fastpickle, fastunpickle, json_dump_v2, json_load.

----------

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

From report at bugs.python.org  Tue Feb  2 09:48:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 14:48:38 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454424518.45.0.277729800673.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>> It looks like some benchmarks are up to 4% faster:

> What this says is that some internals uses of PyMem_XXX should be replaced with PyObject_XXX.

Why not changing PyMem_XXX to use the same fast allocator than PyObject_XXX? (as proposed in this issue)

FYI we now also have the PyMem_RawXXX family :)

----------

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

From report at bugs.python.org  Tue Feb  2 09:52:13 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2016 14:52:13 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454424447.48.0.749884702566.issue26249@psf.upfronthosting.co.za>
Message-ID: <56B0C299.5040908@free.fr>


Antoine Pitrou added the comment:

Le 02/02/2016 15:47, STINNER Victor a ?crit :
> 
> ### 2to3 ###
> Mem max: 43100.000 -> 220.000: 195.9091x smaller
> 
> ### chameleon_v2 ###
> Mem max: 367276.000 -> 224.000: 1639.6250x smaller
> 
> ### django_v3 ###
> Mem max: 24136.000 -> 284.000: 84.9859x smaller

These figures are not even remotely believable.
It would make sense to investigate them before posting such numbers ;-)

----------

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

From report at bugs.python.org  Tue Feb  2 09:53:16 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2016 14:53:16 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454424518.45.0.277729800673.issue26249@psf.upfronthosting.co.za>
Message-ID: <56B0C2DB.9010404@free.fr>


Antoine Pitrou added the comment:

Le 02/02/2016 15:48, STINNER Victor a ?crit :
>> What this says is that some internals uses of PyMem_XXX should be replaced with PyObject_XXX.
> 
> Why not changing PyMem_XXX to use the same fast allocator than
PyObject_XXX? (as proposed in this issue)

Why have two sets of functions doing exactly the same thing?

----------

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

From report at bugs.python.org  Tue Feb  2 09:54:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 14:54:29 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454424869.11.0.156011520851.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> These figures are not even remotely believable.

To be honest, I didn't try to understand them :-) Are they the number of kB of the RSS memory?

Maybe perf.py doesn't like my shell script?

----------

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

From report at bugs.python.org  Tue Feb  2 09:59:29 2016
From: report at bugs.python.org (Marco Buttu)
Date: Tue, 02 Feb 2016 14:59:29 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454425169.85.0.604134250166.issue26182@psf.upfronthosting.co.za>


Marco Buttu added the comment:

The check for the 'with' statement was handled in the parser (parsetok.c), and in Python 2.5 the warnings were enabled by default. 
I do not know how to check if the deprecation warning are enabled, otherwise I would have tried to fix the problem.

----------

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

From report at bugs.python.org  Tue Feb  2 10:01:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 15:01:56 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454424869.11.0.156011520851.issue26249@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwadwBcnAu5TRH60mGd9iw9wPkS3UP3Z6HaRStuNroHe5A@mail.gmail.com>


STINNER Victor added the comment:

> Why have two sets of functions doing exactly the same thing?

I have no idea.

----------

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

From report at bugs.python.org  Tue Feb  2 10:12:50 2016
From: report at bugs.python.org (David Beck)
Date: Tue, 02 Feb 2016 15:12:50 +0000
Subject: [issue26265] errors during static build on OSX
Message-ID: <1454425969.86.0.641229022171.issue26265@psf.upfronthosting.co.za>


New submission from David Beck:

I'm working on an iMac (27" mid 2010) running OSX 10.11.3.

I'm trying to build Python3.5.0 for use with pyqtdeploy. 

If I build python without specifying "--enable-universalsdk", I get multiple warnings "clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk'" on trying to build PyQt5. 

If I specify "--enable-universalsdk" while building Python, I get an error "ld: symbol(s) not found for architecture i386" from the 'make' command. 

If I then specify "--with-universal-archs=64-bit", I get the output below, which includes a number of requests to report this here.

David$ /Users/David/OpenSource/Python-3.5.0/configure --prefix /Users/David/OpenSource/PyQtDeploy/python --enable-universalsdk --with-universal-archs=64-bit
checking build system type... x86_64-apple-darwin15.3.0
checking host system type... x86_64-apple-darwin15.3.0
checking for --enable-universalsdk... /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
checking for --with-universal-archs... 64-bit
checking MACHDEP... darwin
checking for --without-gcc... no
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for --with-cxx-main=<compiler>... no
checking for g++... no
configure:

  By default, distutils will build C++ extension modules with "g++".
  If this is not intended, then set CXX on the configure command line.
  
checking for the platform triplet based on compiler characteristics... darwin
checking for -Wl,--no-as-needed... no
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for --with-suffix... 
checking for case-insensitive build directory... yes
checking LIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking LINKCC... $(PURIFY) $(MAINCC)
checking for GNU ld... no
checking for inline... inline
checking for --enable-shared... no
checking for --enable-profiling... no
checking LDLIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking for ranlib... ranlib
checking for ar... ar
checking for readelf... no
checking for python3.5... python3.5
checking for python3.5... (cached) python3.5
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for --with-pydebug... no
checking whether gcc accepts and needs -fno-strict-aliasing... no
checking if we can turn off gcc unused result warning... yes
checking for -Werror=declaration-after-statement... yes
checking if we can turn on gcc mixed sign comparison warning... yes
checking if we can turn on gcc unreachable code warning... yes
checking which compiler should be used... gcc
checking which MACOSX_DEPLOYMENT_TARGET to use... 10.9
checking whether pthreads are available without options... no
checking whether gcc accepts -Kpthread... no
checking whether gcc accepts -Kthread... no
checking whether gcc accepts -pthread... no
checking whether g++ also accepts flags for thread support... no
checking for ANSI C header files... (cached) yes
checking asm/types.h usability... no
checking asm/types.h presence... no
checking for asm/types.h... no
checking conio.h usability... no
checking conio.h presence... no
checking for conio.h... no
checking direct.h usability... no
checking direct.h presence... no
checking for direct.h... no
checking dlfcn.h usability... no
checking dlfcn.h presence... yes
configure: WARNING: dlfcn.h: present but cannot be compiled
configure: WARNING: dlfcn.h:     check for missing prerequisite headers?
configure: WARNING: dlfcn.h: see the Autoconf documentation
configure: WARNING: dlfcn.h:     section "Present But Cannot Be Compiled"
configure: WARNING: dlfcn.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for dlfcn.h... no
checking errno.h usability... no
checking errno.h presence... yes
configure: WARNING: errno.h: present but cannot be compiled
configure: WARNING: errno.h:     check for missing prerequisite headers?
configure: WARNING: errno.h: see the Autoconf documentation
configure: WARNING: errno.h:     section "Present But Cannot Be Compiled"
configure: WARNING: errno.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for errno.h... no
checking fcntl.h usability... no
checking fcntl.h presence... yes
configure: WARNING: fcntl.h: present but cannot be compiled
configure: WARNING: fcntl.h:     check for missing prerequisite headers?
configure: WARNING: fcntl.h: see the Autoconf documentation
configure: WARNING: fcntl.h:     section "Present But Cannot Be Compiled"
configure: WARNING: fcntl.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for fcntl.h... no
checking grp.h usability... no
checking grp.h presence... yes
configure: WARNING: grp.h: present but cannot be compiled
configure: WARNING: grp.h:     check for missing prerequisite headers?
configure: WARNING: grp.h: see the Autoconf documentation
configure: WARNING: grp.h:     section "Present But Cannot Be Compiled"
configure: WARNING: grp.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for grp.h... no
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking langinfo.h usability... no
checking langinfo.h presence... yes
configure: WARNING: langinfo.h: present but cannot be compiled
configure: WARNING: langinfo.h:     check for missing prerequisite headers?
configure: WARNING: langinfo.h: see the Autoconf documentation
configure: WARNING: langinfo.h:     section "Present But Cannot Be Compiled"
configure: WARNING: langinfo.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for langinfo.h... no
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking process.h usability... no
checking process.h presence... no
checking for process.h... no
checking pthread.h usability... no
checking pthread.h presence... yes
configure: WARNING: pthread.h: present but cannot be compiled
configure: WARNING: pthread.h:     check for missing prerequisite headers?
configure: WARNING: pthread.h: see the Autoconf documentation
configure: WARNING: pthread.h:     section "Present But Cannot Be Compiled"
configure: WARNING: pthread.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for pthread.h... no
checking sched.h usability... no
checking sched.h presence... yes
configure: WARNING: sched.h: present but cannot be compiled
configure: WARNING: sched.h:     check for missing prerequisite headers?
configure: WARNING: sched.h: see the Autoconf documentation
configure: WARNING: sched.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sched.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sched.h... no
checking shadow.h usability... no
checking shadow.h presence... no
checking for shadow.h... no
checking signal.h usability... no
checking signal.h presence... yes
configure: WARNING: signal.h: present but cannot be compiled
configure: WARNING: signal.h:     check for missing prerequisite headers?
configure: WARNING: signal.h: see the Autoconf documentation
configure: WARNING: signal.h:     section "Present But Cannot Be Compiled"
configure: WARNING: signal.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for signal.h... no
checking for stdint.h... (cached) yes
checking stropts.h usability... no
checking stropts.h presence... no
checking for stropts.h... no
checking termios.h usability... no
checking termios.h presence... yes
configure: WARNING: termios.h: present but cannot be compiled
configure: WARNING: termios.h:     check for missing prerequisite headers?
configure: WARNING: termios.h: see the Autoconf documentation
configure: WARNING: termios.h:     section "Present But Cannot Be Compiled"
configure: WARNING: termios.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for termios.h... no
checking for unistd.h... (cached) yes
checking utime.h usability... no
checking utime.h presence... yes
configure: WARNING: utime.h: present but cannot be compiled
configure: WARNING: utime.h:     check for missing prerequisite headers?
configure: WARNING: utime.h: see the Autoconf documentation
configure: WARNING: utime.h:     section "Present But Cannot Be Compiled"
configure: WARNING: utime.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for utime.h... no
checking poll.h usability... no
checking poll.h presence... yes
configure: WARNING: poll.h: present but cannot be compiled
configure: WARNING: poll.h:     check for missing prerequisite headers?
configure: WARNING: poll.h: see the Autoconf documentation
configure: WARNING: poll.h:     section "Present But Cannot Be Compiled"
configure: WARNING: poll.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for poll.h... no
checking sys/devpoll.h usability... no
checking sys/devpoll.h presence... no
checking for sys/devpoll.h... no
checking sys/epoll.h usability... no
checking sys/epoll.h presence... no
checking for sys/epoll.h... no
checking sys/poll.h usability... no
checking sys/poll.h presence... yes
configure: WARNING: sys/poll.h: present but cannot be compiled
configure: WARNING: sys/poll.h:     check for missing prerequisite headers?
configure: WARNING: sys/poll.h: see the Autoconf documentation
configure: WARNING: sys/poll.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/poll.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/poll.h... no
checking sys/audioio.h usability... no
checking sys/audioio.h presence... no
checking for sys/audioio.h... no
checking sys/xattr.h usability... no
checking sys/xattr.h presence... yes
configure: WARNING: sys/xattr.h: present but cannot be compiled
configure: WARNING: sys/xattr.h:     check for missing prerequisite headers?
configure: WARNING: sys/xattr.h: see the Autoconf documentation
configure: WARNING: sys/xattr.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/xattr.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/xattr.h... no
checking sys/bsdtty.h usability... no
checking sys/bsdtty.h presence... no
checking for sys/bsdtty.h... no
checking sys/event.h usability... no
checking sys/event.h presence... yes
configure: WARNING: sys/event.h: present but cannot be compiled
configure: WARNING: sys/event.h:     check for missing prerequisite headers?
configure: WARNING: sys/event.h: see the Autoconf documentation
configure: WARNING: sys/event.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/event.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/event.h... no
checking sys/file.h usability... no
checking sys/file.h presence... yes
configure: WARNING: sys/file.h: present but cannot be compiled
configure: WARNING: sys/file.h:     check for missing prerequisite headers?
configure: WARNING: sys/file.h: see the Autoconf documentation
configure: WARNING: sys/file.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/file.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/file.h... no
checking sys/ioctl.h usability... no
checking sys/ioctl.h presence... yes
configure: WARNING: sys/ioctl.h: present but cannot be compiled
configure: WARNING: sys/ioctl.h:     check for missing prerequisite headers?
configure: WARNING: sys/ioctl.h: see the Autoconf documentation
configure: WARNING: sys/ioctl.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/ioctl.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/ioctl.h... no
checking sys/kern_control.h usability... no
checking sys/kern_control.h presence... yes
configure: WARNING: sys/kern_control.h: present but cannot be compiled
configure: WARNING: sys/kern_control.h:     check for missing prerequisite headers?
configure: WARNING: sys/kern_control.h: see the Autoconf documentation
configure: WARNING: sys/kern_control.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/kern_control.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/kern_control.h... no
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking sys/lock.h usability... no
checking sys/lock.h presence... yes
configure: WARNING: sys/lock.h: present but cannot be compiled
configure: WARNING: sys/lock.h:     check for missing prerequisite headers?
configure: WARNING: sys/lock.h: see the Autoconf documentation
configure: WARNING: sys/lock.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/lock.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/lock.h... no
checking sys/mkdev.h usability... no
checking sys/mkdev.h presence... no
checking for sys/mkdev.h... no
checking sys/modem.h usability... no
checking sys/modem.h presence... no
checking for sys/modem.h... no
checking sys/param.h usability... no
checking sys/param.h presence... yes
configure: WARNING: sys/param.h: present but cannot be compiled
configure: WARNING: sys/param.h:     check for missing prerequisite headers?
configure: WARNING: sys/param.h: see the Autoconf documentation
configure: WARNING: sys/param.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/param.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/param.h... no
checking sys/select.h usability... no
checking sys/select.h presence... yes
configure: WARNING: sys/select.h: present but cannot be compiled
configure: WARNING: sys/select.h:     check for missing prerequisite headers?
configure: WARNING: sys/select.h: see the Autoconf documentation
configure: WARNING: sys/select.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/select.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/select.h... no
checking sys/sendfile.h usability... no
checking sys/sendfile.h presence... no
checking for sys/sendfile.h... no
checking sys/socket.h usability... no
checking sys/socket.h presence... yes
configure: WARNING: sys/socket.h: present but cannot be compiled
configure: WARNING: sys/socket.h:     check for missing prerequisite headers?
configure: WARNING: sys/socket.h: see the Autoconf documentation
configure: WARNING: sys/socket.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/socket.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/socket.h... no
checking sys/statvfs.h usability... no
checking sys/statvfs.h presence... yes
configure: WARNING: sys/statvfs.h: present but cannot be compiled
configure: WARNING: sys/statvfs.h:     check for missing prerequisite headers?
configure: WARNING: sys/statvfs.h: see the Autoconf documentation
configure: WARNING: sys/statvfs.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/statvfs.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/statvfs.h... no
checking for sys/stat.h... (cached) yes
checking sys/syscall.h usability... no
checking sys/syscall.h presence... yes
configure: WARNING: sys/syscall.h: present but cannot be compiled
configure: WARNING: sys/syscall.h:     check for missing prerequisite headers?
configure: WARNING: sys/syscall.h: see the Autoconf documentation
configure: WARNING: sys/syscall.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/syscall.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/syscall.h... no
checking sys/sys_domain.h usability... no
checking sys/sys_domain.h presence... yes
configure: WARNING: sys/sys_domain.h: present but cannot be compiled
configure: WARNING: sys/sys_domain.h:     check for missing prerequisite headers?
configure: WARNING: sys/sys_domain.h: see the Autoconf documentation
configure: WARNING: sys/sys_domain.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/sys_domain.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/sys_domain.h... no
checking sys/termio.h usability... no
checking sys/termio.h presence... no
checking for sys/termio.h... no
checking sys/time.h usability... no
checking sys/time.h presence... yes
configure: WARNING: sys/time.h: present but cannot be compiled
configure: WARNING: sys/time.h:     check for missing prerequisite headers?
configure: WARNING: sys/time.h: see the Autoconf documentation
configure: WARNING: sys/time.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/time.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/time.h... no
checking sys/times.h usability... no
checking sys/times.h presence... yes
configure: WARNING: sys/times.h: present but cannot be compiled
configure: WARNING: sys/times.h:     check for missing prerequisite headers?
configure: WARNING: sys/times.h: see the Autoconf documentation
configure: WARNING: sys/times.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/times.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/times.h... no
checking for sys/types.h... (cached) yes
checking sys/uio.h usability... no
checking sys/uio.h presence... yes
configure: WARNING: sys/uio.h: present but cannot be compiled
configure: WARNING: sys/uio.h:     check for missing prerequisite headers?
configure: WARNING: sys/uio.h: see the Autoconf documentation
configure: WARNING: sys/uio.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/uio.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/uio.h... no
checking sys/un.h usability... no
checking sys/un.h presence... yes
configure: WARNING: sys/un.h: present but cannot be compiled
configure: WARNING: sys/un.h:     check for missing prerequisite headers?
configure: WARNING: sys/un.h: see the Autoconf documentation
configure: WARNING: sys/un.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/un.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/un.h... no
checking sys/utsname.h usability... no
checking sys/utsname.h presence... yes
configure: WARNING: sys/utsname.h: present but cannot be compiled
configure: WARNING: sys/utsname.h:     check for missing prerequisite headers?
configure: WARNING: sys/utsname.h: see the Autoconf documentation
configure: WARNING: sys/utsname.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/utsname.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/utsname.h... no
checking sys/wait.h usability... no
checking sys/wait.h presence... yes
configure: WARNING: sys/wait.h: present but cannot be compiled
configure: WARNING: sys/wait.h:     check for missing prerequisite headers?
configure: WARNING: sys/wait.h: see the Autoconf documentation
configure: WARNING: sys/wait.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/wait.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/wait.h... no
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking sys/resource.h usability... no
checking sys/resource.h presence... yes
configure: WARNING: sys/resource.h: present but cannot be compiled
configure: WARNING: sys/resource.h:     check for missing prerequisite headers?
configure: WARNING: sys/resource.h: see the Autoconf documentation
configure: WARNING: sys/resource.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/resource.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sys/resource.h... no
checking netpacket/packet.h usability... no
checking netpacket/packet.h presence... no
checking for netpacket/packet.h... no
checking sysexits.h usability... no
checking sysexits.h presence... yes
configure: WARNING: sysexits.h: present but cannot be compiled
configure: WARNING: sysexits.h:     check for missing prerequisite headers?
configure: WARNING: sysexits.h: see the Autoconf documentation
configure: WARNING: sysexits.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sysexits.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for sysexits.h... no
checking bluetooth.h usability... no
checking bluetooth.h presence... no
checking for bluetooth.h... no
checking bluetooth/bluetooth.h usability... no
checking bluetooth/bluetooth.h presence... no
checking for bluetooth/bluetooth.h... no
checking linux/tipc.h usability... no
checking linux/tipc.h presence... no
checking for linux/tipc.h... no
checking spawn.h usability... no
checking spawn.h presence... yes
configure: WARNING: spawn.h: present but cannot be compiled
configure: WARNING: spawn.h:     check for missing prerequisite headers?
configure: WARNING: spawn.h: see the Autoconf documentation
configure: WARNING: spawn.h:     section "Present But Cannot Be Compiled"
configure: WARNING: spawn.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for spawn.h... no
checking util.h usability... no
checking util.h presence... yes
configure: WARNING: util.h: present but cannot be compiled
configure: WARNING: util.h:     check for missing prerequisite headers?
configure: WARNING: util.h: see the Autoconf documentation
configure: WARNING: util.h:     section "Present But Cannot Be Compiled"
configure: WARNING: util.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for util.h... no
checking alloca.h usability... no
checking alloca.h presence... yes
configure: WARNING: alloca.h: present but cannot be compiled
configure: WARNING: alloca.h:     check for missing prerequisite headers?
configure: WARNING: alloca.h: see the Autoconf documentation
configure: WARNING: alloca.h:     section "Present But Cannot Be Compiled"
configure: WARNING: alloca.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for alloca.h... no
checking endian.h usability... no
checking endian.h presence... no
checking for endian.h... no
checking sys/endian.h usability... no
checking sys/endian.h presence... no
checking for sys/endian.h... no
checking for dirent.h that defines DIR... no
checking for sys/ndir.h that defines DIR... no
checking for sys/dir.h that defines DIR... no
checking for ndir.h that defines DIR... no
checking for library containing opendir... no
checking whether sys/types.h defines makedev... no
checking for sys/mkdev.h... (cached) no
checking sys/sysmacros.h usability... no
checking sys/sysmacros.h presence... no
checking for sys/sysmacros.h... no
checking for net/if.h... no
checking for linux/netlink.h... no
checking for linux/can.h... no
checking for linux/can/raw.h... no
checking for linux/can/bcm.h... no
checking for clock_t in time.h... yes
checking for makedev... no
checking for le64toh... no
checking Solaris LFS bug... yes
checking for mode_t... no
checking for off_t... no
checking for pid_t... no
checking for size_t... no
checking for uid_t in sys/types.h... yes
checking for uint32_t... no
checking for uint32_t... no
checking for uint64_t... no
checking for uint64_t... no
checking for int32_t... no
checking for int32_t... no
checking for int64_t... no
checking for int64_t... no
checking for ssize_t... no
checking for __uint128_t... no
checking size of int... 0
checking size of long... 0
checking size of void *... 0
checking size of short... 0
checking size of float... 0
checking size of double... 0
checking size of fpos_t... 0
checking size of size_t... 0
checking size of pid_t... 0
checking for long long support... no
checking for long double support... no
checking for _Bool support... no
checking for uintptr_t... no
checking size of off_t... 0
checking whether to enable large file support... no
checking size of time_t... 0
checking for pthread_t... no
checking for --enable-framework... no
checking for dyld... always on for Darwin
checking the extension of shared libraries... .so
checking LDSHARED... $(CC) -bundle -undefined dynamic_lookup
checking CCSHARED... 
checking LINKFORSHARED... -Wl,-stack_size,1000000  -framework CoreFoundation
checking CFLAGSFORSHARED... 
checking SHLIBS... $(LIBS)
checking for sendfile in -lsendfile... no
checking for dlopen in -ldl... no
checking for shl_load in -ldld... no
checking for RAND_egd in -lcrypto... no
checking for library containing sem_init... no
checking for textdomain in -lintl... no
checking aligned memory access is required... yes
checking for --with-hash-algorithm... default
checking for --with-address-sanitizer... no
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for --with-libs... no
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for --with-system-expat... no
checking for --with-system-ffi... no
checking for --with-system-libmpdec... no
checking for --enable-loadable-sqlite-extensions... no
checking for --with-tcltk-includes... default
checking for --with-tcltk-libs... default
checking for --with-dbmliborder... 
checking for --with-signal-module... yes
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for pthread_create in -lpthread... checking for pthread_detach... no
checking for pthread_create in -lpthreads... no
checking for pthread_create in -lc_r... no
checking for __pthread_create_system in -lpthread... no
checking for pthread_create in -lcma... no
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... no
checking for CAN_RAW_FD_FRAMES... no
checking for OSX 10.5 SDK or later... no
checking for --with-doc-strings... yes
checking for --with-tsc... no
checking for --with-pymalloc... yes
checking for --with-valgrind... no
checking for dlopen... no
checking DYNLOADFILE... dynload_stub.o
checking MACHDEP_OBJS... none
checking for alarm... no
checking for accept4... no
checking for setitimer... no
checking for getitimer... no
checking for bind_textdomain_codeset... no
checking for chown... no
checking for clock... no
checking for confstr... no
checking for ctermid... no
checking for dup3... no
checking for execv... no
checking for faccessat... no
checking for fchmod... no
checking for fchmodat... no
checking for fchown... no
checking for fchownat... no
checking for fexecve... no
checking for fdopendir... no
checking for fork... no
checking for fpathconf... no
checking for fstatat... no
checking for ftime... no
checking for ftruncate... no
checking for futimesat... no
checking for futimens... no
checking for futimes... no
checking for gai_strerror... no
checking for getentropy... no
checking for getgrouplist... no
checking for getgroups... no
checking for getlogin... no
checking for getloadavg... no
checking for getpeername... no
checking for getpgid... no
checking for getpid... no
checking for getpriority... no
checking for getresuid... no
checking for getresgid... no
checking for getpwent... no
checking for getspnam... no
checking for getspent... no
checking for getsid... no
checking for getwd... no
checking for if_nameindex... no
checking for initgroups... no
checking for kill... no
checking for killpg... no
checking for lchmod... no
checking for lchown... no
checking for lockf... no
checking for linkat... no
checking for lstat... no
checking for lutimes... no
checking for mmap... no
checking for memrchr... no
checking for mbrtowc... no
checking for mkdirat... no
checking for mkfifo... no
checking for mkfifoat... no
checking for mknod... no
checking for mknodat... no
checking for mktime... no
checking for mremap... no
checking for nice... no
checking for openat... no
checking for pathconf... no
checking for pause... no
checking for pipe2... no
checking for plock... no
checking for poll... no
checking for posix_fallocate... no
checking for posix_fadvise... no
checking for pread... no
checking for pthread_init... no
checking for pthread_kill... no
checking for putenv... no
checking for pwrite... no
checking for readlink... no
checking for readlinkat... no
checking for readv... no
checking for realpath... no
checking for renameat... no
checking for select... no
checking for sem_open... no
checking for sem_timedwait... no
checking for sem_getvalue... no
checking for sem_unlink... no
checking for sendfile... no
checking for setegid... no
checking for seteuid... no
checking for setgid... no
checking for sethostname... no
checking for setlocale... no
checking for setregid... no
checking for setreuid... no
checking for setresuid... no
checking for setresgid... no
checking for setsid... no
checking for setpgid... no
checking for setpgrp... no
checking for setpriority... no
checking for setuid... no
checking for setvbuf... no
checking for sched_get_priority_max... no
checking for sched_setaffinity... no
checking for sched_setscheduler... no
checking for sched_setparam... no
checking for sched_rr_get_interval... no
checking for sigaction... no
checking for sigaltstack... no
checking for siginterrupt... no
checking for sigpending... no
checking for sigrelse... no
checking for sigtimedwait... no
checking for sigwait... no
checking for sigwaitinfo... no
checking for snprintf... no
checking for strftime... no
checking for strlcpy... no
checking for symlinkat... no
checking for sync... no
checking for sysconf... no
checking for tcgetpgrp... no
checking for tcsetpgrp... no
checking for tempnam... no
checking for timegm... no
checking for times... no
checking for tmpfile... no
checking for tmpnam... no
checking for tmpnam_r... no
checking for truncate... no
checking for uname... no
checking for unlinkat... no
checking for unsetenv... no
checking for utimensat... no
checking for utimes... no
checking for waitid... no
checking for waitpid... no
checking for wait3... no
checking for wait4... no
checking for wcscoll... no
checking for wcsftime... no
checking for wcsxfrm... no
checking for wmemcmp... no
checking for writev... no
checking for _getpty... no
checking whether dirfd is declared... no
checking for chroot... no
checking for link... no
checking for symlink... no
checking for fchdir... no
checking for fsync... no
checking for fdatasync... no
checking for epoll... no
checking for epoll_create1... no
checking for kqueue... no
checking for prlimit... no
checking for ctermid_r... no
checking for flock declaration... no
checking for getpagesize... no
checking for broken unsetenv... yes
checking for true... true
checking for inet_aton in -lc... no
checking for inet_aton in -lresolv... no
checking for chflags... no
checking for lchflags... no
checking for inflateCopy in -lz... no
checking for hstrerror... no
checking for inet_aton... no
checking for inet_pton... no
checking for setgroups... no
checking for openpty... no
checking for openpty in -lutil... no
checking for openpty in -lbsd... no
checking for forkpty... no
checking for forkpty in -lutil... no
checking for forkpty in -lbsd... no
checking for memmove... no
checking for fseek64... no
checking for fseeko... no
checking for fstatvfs... no
checking for ftell64... no
checking for ftello... no
checking for statvfs... no
checking for dup2... no
checking for strdup... no
checking for getpgrp... no
checking for setpgrp... (cached) no
checking for gettimeofday... no
checking for clock_gettime... no
checking for clock_gettime in -lrt... no
checking for clock_getres... no
checking for clock_getres in -lrt... no
checking for major... no
checking for getaddrinfo... no

checking for getnameinfo... no
checking whether time.h and sys/time.h may both be included... no
checking whether struct tm is in sys/time.h or time.h... sys/time.h
checking for struct tm.tm_zone... no
checking whether tzname is declared... no
checking for tzname... no
checking for struct stat.st_rdev... no
checking for struct stat.st_blksize... no
checking for struct stat.st_flags... no
checking for struct stat.st_gen... no
checking for struct stat.st_birthtime... no
checking for struct stat.st_blocks... no
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... no
checking for addrinfo... no
checking for sockaddr_storage... no
checking whether char is unsigned... yes
checking for an ANSI C-conforming const... no
checking for working volatile... no
checking for working signed char... no
checking for prototypes... no
checking for variable length prototypes and stdarg.h... no
checking for socketpair... no
checking if sockaddr has sa_len member... no
checking whether va_list is an array... yes
checking for gethostbyname_r... no
checking for gethostbyname... no
checking for __fpu_control... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM=""
checking for --with-libc=STRING... default LIBC=""
checking for x64 gcc inline assembler... no
checking whether C doubles are little-endian IEEE 754 binary64... no
checking whether C doubles are big-endian IEEE 754 binary64... no
checking whether C doubles are ARM mixed-endian IEEE 754 binary64... no
checking whether we can use gcc inline assembler to get and set x87 control word... no
checking whether we can use gcc inline assembler to get and set mc68881 fpcr... no
checking for x87-style double rounding... yes
checking for acosh... no
checking for asinh... no
checking for atanh... no
checking for copysign... no
checking for erf... no
checking for erfc... no
checking for expm1... no
checking for finite... no
checking for gamma... no
checking for hypot... no
checking for lgamma... no
checking for log1p... no
checking for log2... no
checking for round... no
checking for tgamma... no
checking whether isinf is declared... no
checking whether isnan is declared... no
checking whether isfinite is declared... no
checking whether tanh preserves the sign of zero... no
checking whether POSIX semaphores are enabled... no
checking for broken sem_getvalue... yes
checking digit size for Python's longs... no value specified
checking wchar.h usability... no
checking wchar.h presence... yes
configure: WARNING: wchar.h: present but cannot be compiled
configure: WARNING: wchar.h:     check for missing prerequisite headers?
configure: WARNING: wchar.h: see the Autoconf documentation
configure: WARNING: wchar.h:     section "Present But Cannot Be Compiled"
configure: WARNING: wchar.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for wchar.h... no
checking for UCS-4 tcl... no
/Users/David/OpenSource/Python-3.5.0/configure: line 14108: test: : integer expression expected
no usable wchar_t found
checking whether byte ordering is bigendian... yes
checking ABIFLAGS... m
checking SOABI... cpython-35m-darwin
checking LDVERSION... $(VERSION)$(ABIFLAGS)
checking whether right shift extends the sign bit... no
checking for getc_unlocked() and friends... no
checking how to link readline libs... none
checking for rl_callback_handler_install in -lreadline... no
checking for rl_pre_input_hook in -lreadline... no
checking for rl_completion_display_matches_hook in -lreadline... no
checking for rl_completion_matches in -lreadline... no
checking for append_history in -lreadline... no
checking for broken nice()... no
checking for broken poll()... no
checking for struct tm.tm_zone... (cached) no
checking whether tzname is declared... (cached) no
checking for tzname... (cached) no
checking for working tzset()... no
checking for tv_nsec in struct stat... no
checking for tv_nsec2 in struct stat... no
checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for curses.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the compiler's result
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##
checking for ncurses.h... no
checking for term.h... no
checking whether mvwdelch is an expression... no
checking whether WINDOW has _flags... no
checking for is_term_resized... no
checking for resize_term... no
checking for resizeterm... no
configure: checking for device files
checking for /dev/ptmx... yes
checking for /dev/ptc... no
checking for %zd printf() format support... no
checking for socklen_t... no
checking for broken mbstowcs... yes
checking for --with-computed-gotos... no value specified
checking whether gcc supports computed gotos... no
checking for build directories... done
checking for -O2... yes
checking for glibc _FORTIFY_SOURCE/memmove bug... yes
checking for stdatomic.h... no
checking for GCC >= 4.7 __atomic builtins... no
checking for ensurepip... upgrade
checking if the dirent structure of a d_type field... no
checking for the Linux getrandom() syscall... no
configure: creating ./config.status
config.status: creating Makefile.pre
config.status: creating Modules/Setup.config
config.status: creating Misc/python.pc
config.status: creating Misc/python-config.sh
config.status: creating Modules/ld_so_aix
config.status: creating pyconfig.h
creating Modules/Setup
creating Modules/Setup.local
creating Makefile

----------
components: Macintosh
messages: 259396
nosy: davidjamesbeck, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: errors during static build on OSX
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Tue Feb  2 10:48:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Feb 2016 15:48:39 +0000
Subject: [issue26233] select.epoll.poll() should avoid calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1454428119.22.0.0445372834927.issue26233@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure that it is worth to apply this optimization. The patch adds half a hundred lines of complex code for only 80 ns benefit. On my computer just incrementing an integer takes 100 ns.

----------

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

From report at bugs.python.org  Tue Feb  2 10:49:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Feb 2016 15:49:55 +0000
Subject: [issue25945] Type confusion in partial_setstate and partial_call
 leads to memory corruption
In-Reply-To: <1451017001.94.0.489150526382.issue25945@psf.upfronthosting.co.za>
Message-ID: <1454428195.12.0.10054333491.issue25945@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Nick and Raymond for your reviews.

----------

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

From report at bugs.python.org  Tue Feb  2 11:27:31 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 02 Feb 2016 16:27:31 +0000
Subject: [issue26266] add classattribute to enum to handle non-Enum attributes
Message-ID: <1454430451.09.0.888937739305.issue26266@psf.upfronthosting.co.za>


New submission from Ethan Furman:

The rules for what objects in an Enum become members and which do not are fairly straight-forward:

__double_underscore__ do not (but is reserved for Python)
_single_underscore_ do not (but is reserved for Enum itself)
any descriptored object (such as functions) do not

Which means the proper way to add constants/attributes to an Enum is to write a descriptor, but most folks don't think about that when the Enum is not working properly they (okay, and me :/ ) just add the double-underscore.

This question has already come up a couple times on StackOverflow:
- http://stackoverflow.com/q/17911188/208880
- http://stackoverflow.com/q/34465739/208880

While this doesn't come up very often, that just means it is even more likely to have the attribute be __double_underscored__ instead of descriptored.

The solution is have a descriptor in the Enum module for this case.  While it would be possible to have several (constant-unless-mutable, constant-even-if-mutable, not-constant, possibly others) I think the not-constant would be sufficient (aka a writable property), although I am not opposed to a constant-unless mutable version as well.

The not-constant version would look like this (I'll attach patch later):

class classattribute:
    def __init__(self, value):
        self.value = value
    def __get__(self, *args):
        return self.value
    def __set__(self, value):
        self.value = value
    def __repr__(self):
        return '%s(%r)' % (self.__class__.__name__, self.value)

----------
assignee: ethan.furman
messages: 259399
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: add classattribute to enum to handle non-Enum attributes
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Feb  2 11:27:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Feb 2016 16:27:46 +0000
Subject: [issue26265] errors during static build on OSX
In-Reply-To: <1454425969.86.0.641229022171.issue26265@psf.upfronthosting.co.za>
Message-ID: <1454430466.91.0.328095065383.issue26265@psf.upfronthosting.co.za>


Ned Deily added the comment:

I can't speak to issues with PyQt5 since that is not part of the Python standard library but you shouldn't need additional configure options just to build Python itself. Make sure you have installed the latest version of Xcode for your release via the App Store app update pane and that you have installed the corresponding latest version of the Xcode Command Line Tools with:

xcode-select --install

Then start with a clean build directory.

----------

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

From report at bugs.python.org  Tue Feb  2 11:46:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Feb 2016 16:46:27 +0000
Subject: [issue25945] Type confusion in partial_setstate and partial_call
 leads to memory corruption
In-Reply-To: <1451017001.94.0.489150526382.issue25945@psf.upfronthosting.co.za>
Message-ID: <20160202164621.4733.92029@psf.io>


Roundup Robot added the comment:

New changeset 542b5744ddc3 by Serhiy Storchaka in branch '3.5':
Issue #25945: Fixed bugs in functools.partial.
https://hg.python.org/cpython/rev/542b5744ddc3

New changeset 33109176538d by Serhiy Storchaka in branch 'default':
Issue #25945: Fixed bugs in functools.partial.
https://hg.python.org/cpython/rev/33109176538d

New changeset 628ce2975e29 by Serhiy Storchaka in branch '2.7':
Issue #25945: Fixed bugs in functools.partial.
https://hg.python.org/cpython/rev/628ce2975e29

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  2 11:56:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Feb 2016 16:56:40 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454432200.0.0.124938070531.issue26256@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is this the same algorithm as in issue3451?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Tue Feb  2 11:59:20 2016
From: report at bugs.python.org (Anish Shah)
Date: Tue, 02 Feb 2016 16:59:20 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1454432360.91.0.910764398969.issue24780@psf.upfronthosting.co.za>


Anish Shah added the comment:

The problem is in `difflib.ndiff` function. When the string does not have a trailing newline, we get an unreadable output.
After applying my patch, the following is the output of test2.py (submitted by Elena.Oat).



FFFFFFFF
======================================================================
FAIL: test_notrailingnewline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 8, in test_notrailingnewline_0
    self.assertEqual("abcDefehiJkl", "abcdefGhijkl")
AssertionError: 'abcDefehiJkl' != 'abcdefGhijkl'
- abcDefehiJkl
?    ^  ^  ^
+ abcdefGhijkl
?    ^  ^  ^


======================================================================
FAIL: test_notrailingnewline_1 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 14, in test_notrailingnewline_1
    self.assertEqual("a\nbcdf", "a\nbddf")
AssertionError: 'a\nbcdf' != 'a\nbddf'
  a
- bcdf
?  ^
+ bddf
?  ^


======================================================================
FAIL: test_notrailingnewline_2 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 18, in test_notrailingnewline_2
    self.assertEqual("a\nbcdf", "a\nbddg")
AssertionError: 'a\nbcdf' != 'a\nbddg'
  a
- bcdf
+ bddg


======================================================================
FAIL: test_starting_and_ending_newline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 12, in test_starting_and_ending_newline_0
    self.assertEqual("\nabcDefehiJkl\n", "\nabcdefGhijkl\n")
AssertionError: '\nabcDefehiJkl\n' != '\nabcdefGhijkl\n'
  
- abcDefehiJkl
?    ^  ^  ^
+ abcdefGhijkl
?    ^  ^  ^


======================================================================
FAIL: test_startingnewline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 10, in test_startingnewline_0
    self.assertEqual("\nabcDefehiJkl", "\nabcdefGhijkl")
AssertionError: '\nabcDefehiJkl' != '\nabcdefGhijkl'
  
- abcDefehiJkl
?    ^  ^  ^
+ abcdefGhijkl
?    ^  ^  ^


======================================================================
FAIL: test_trailingnewline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 6, in test_trailingnewline_0
    self.assertEqual("abcDefehiJkl\n", "abcdefGhijkl\n")
AssertionError: 'abcDefehiJkl\n' != 'abcdefGhijkl\n'
- abcDefehiJkl
?    ^  ^  ^
+ abcdefGhijkl
?    ^  ^  ^


======================================================================
FAIL: test_trailingnewline_1 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 16, in test_trailingnewline_1
    self.assertEqual("a\nbcdf\n", "a\nbddf\n")
AssertionError: 'a\nbcdf\n' != 'a\nbddf\n'
  a
- bcdf
?  ^
+ bddf
?  ^


======================================================================
FAIL: test_trailingnewline_2 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 20, in test_trailingnewline_2
    self.assertEqual("a\nbcdf\n", "a\nbddg\n")
AssertionError: 'a\nbcdf\n' != 'a\nbddg\n'
  a
- bcdf
+ bddg


----------------------------------------------------------------------
Ran 8 tests in 0.004s

FAILED (failures=8)

----------
keywords: +patch
Added file: http://bugs.python.org/file41782/issue24780.patch

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

From report at bugs.python.org  Tue Feb  2 11:59:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Feb 2016 16:59:49 +0000
Subject: [issue25945] Type confusion in partial_setstate and partial_call
 leads to memory corruption
In-Reply-To: <1451017001.94.0.489150526382.issue25945@psf.upfronthosting.co.za>
Message-ID: <1454432389.73.0.480170443914.issue25945@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  2 12:01:53 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 02 Feb 2016 17:01:53 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1454420777.28.0.582135408717.issue25924@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKj80orGkVCTS=ajAaqX39nXX5zbObHr-9rb8mP9d2aSQ@mail.gmail.com>


Guido van Rossum added the comment:

Find an active developer who cares -- e.g. Martin Panter, Serhiy, Yury.

On Tue, Feb 2, 2016 at 5:46 AM, A. Jesse Jiryu Davis
<report at bugs.python.org> wrote:
>
> A. Jesse Jiryu Davis added the comment:
>
> Great, how do we ensure this gets merged soon?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25924>
> _______________________________________

----------

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

From report at bugs.python.org  Tue Feb  2 12:09:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Feb 2016 17:09:58 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454432998.58.0.615586010904.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Reopened. Otherwise Martin's comments can be lost in spam.

> Maybe it's also worth to document the change in Python 3.5 and 3.6 documentation with a ".. versionchanged::"?

I don't think this is needed. This isn't new feature, this is just a bugfix, old behavior obviously was incorrect. We don't add the versionchanged directive for every bugfix.

----------
status: closed -> open

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

From report at bugs.python.org  Tue Feb  2 12:23:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Feb 2016 17:23:08 +0000
Subject: [issue23252] Add support of writing to unseekable file in zipfile
In-Reply-To: <1421438148.04.0.307260333821.issue23252@psf.upfronthosting.co.za>
Message-ID: <1454433788.64.0.241363485777.issue23252@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Currently the zipfile module requires seekable stream to read a list of entries from central directory at the end of ZIP file, and for reding their content in arbitrary order. The support of unseekable stream needs to design a new API. This is separate issue.

----------

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

From report at bugs.python.org  Tue Feb  2 12:33:45 2016
From: report at bugs.python.org (Anish Shah)
Date: Tue, 02 Feb 2016 17:33:45 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454434425.84.0.645711853047.issue26136@psf.upfronthosting.co.za>


Anish Shah added the comment:

I have submitted a patch. I have replace `PyExc_PendingDeprecationWarning` to `PyExc_DeprecationWarning` in Objects/genobject.c

Can anyone please review?

----------
keywords: +patch
Added file: http://bugs.python.org/file41783/issue26136.patch

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

From report at bugs.python.org  Tue Feb  2 13:07:50 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Feb 2016 18:07:50 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454436470.7.0.356268701554.issue26256@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Not really the same, since that issue was more about fast division. But it's the same spirit. It looks like I was more enthusiastic back then; now I'm older and grumpier. It's great to have this stuff, but I don't think it belongs in core Python: I'd much rather that the core Python integer implementation remain simple, portable and low-maintenance, and work well for the domain it's intended for: small-to-medium size integers. Cryptographic-size integers with a few hundred to a few thousand digits should be fine; number-theoretic work requiring hundreds of thousands of digits should use gmpy2 or something similar.

----------

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

From report at bugs.python.org  Tue Feb  2 13:10:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Feb 2016 18:10:08 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454436608.03.0.882819163935.issue26182@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm not quite sure what you mean by "do not know how to check if the deprecation warning are enabled". Do you mean how do you make sure you don't emit a DeprecationWarning if someone hasn't turned warnings on? If that's the case then if you look at some example code and read https://docs.python.org/3/c-api/exceptions.html#issuing-warnings you will notice that when you call the warning-related functions, all you have to do is check if the return value is < 0, then return like there is an exception raised. Otherwise the warnings module handles whether something will be shown.

----------

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

From report at bugs.python.org  Tue Feb  2 13:20:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 18:20:13 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1454437213.27.0.254156836209.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Victor,

Thanks for the initial review.  I'll work on the patch sometime later next week.  

As for test_vicious_descriptor_nonsense -- yeah, I saw that too.  I know what's going on there and I know how to fix that.  FWIW that test tests a very counter-intuitive and quirky CPython implementation detail.

----------

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

From report at bugs.python.org  Tue Feb  2 13:22:04 2016
From: report at bugs.python.org (Anish Shah)
Date: Tue, 02 Feb 2016 18:22:04 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454437324.14.0.918067043887.issue26182@psf.upfronthosting.co.za>


Anish Shah added the comment:

I would like to work on this, if it is okay with Marco?
I look at the history of parsetok.c file and I think I can solve this issue. 

Also, I have a doubt - PEP 492 says that "async and await names will be softly deprecated in CPython 3.5 and 3.6".
What exactly does "softly deprecate" mean? is it just same as throwing a warning?

----------

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

From report at bugs.python.org  Tue Feb  2 13:35:51 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Feb 2016 18:35:51 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454438151.53.0.945306585348.issue26182@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I don't know what "softly deprecate" means. Hopefully someone involved with the PEP can answer that question.

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Tue Feb  2 13:41:25 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 18:41:25 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454438485.39.0.161339773604.issue26182@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I don't know what "softly deprecate" means. Hopefully someone involved with the PEP can answer that question.

I actually thought about emitting DeprecationWarnings in 3.6 for async/await NAME tokens.  I think it's a reasonable thing to do to prepare for 3.7, where they will become proper keywords.

----------

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

From report at bugs.python.org  Tue Feb  2 13:43:06 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2016 18:43:06 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454438586.56.0.744046812242.issue26182@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

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

From report at bugs.python.org  Tue Feb  2 13:43:09 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 02 Feb 2016 18:43:09 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
Message-ID: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

Most real-world code that uses the UUID module wants either the standard format '{12345678-1234-5678-1234-567812345678}', or the same thing without the braces.

There are a number of different documented accessors, but none of them give you either of these. The simplest way I can think of to guarantee the standard format from what's documented is '{%08x-%04x-%04x-%02x%02x-%12x}' % u.fields.

It might be nice to add accessors for standard form and braceless standard form, but that probably isn't necessary--as long as there's documentation saying that __str__ returns the braceless standard form.

The example code does say that, but I don't think people can trust that a comment in an example is binding documentation--plus, plenty of people don't read the examples looking for more information about things that aren't documented. And I've seen people come up with buggy versions of the format string that miss leading zeros, or horrible things like repr(u)[6:42].

----------
assignee: docs at python
components: Documentation
messages: 259414
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: UUID docs should say how to get "standard form"
type: enhancement

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

From report at bugs.python.org  Tue Feb  2 13:47:43 2016
From: report at bugs.python.org (David Beck)
Date: Tue, 02 Feb 2016 18:47:43 +0000
Subject: [issue26265] errors during static build on OSX
In-Reply-To: <1454430466.91.0.328095065383.issue26265@psf.upfronthosting.co.za>
Message-ID: <32452858-41D1-4F19-ACF9-C78A46A27761@ualberta.ca>


David Beck added the comment:

Thanks, I?ve done that (a couple of times). I posted this not so much because of my problems with PyQt, but because the output of the Python build when I used those two options asked me to report this as a bug.

cheers,

David

> On Feb 2, 2016, at 9:27 AM, Ned Deily <report at bugs.python.org> wrote:
> 
> 
> Ned Deily added the comment:
> 
> I can't speak to issues with PyQt5 since that is not part of the Python standard library but you shouldn't need additional configure options just to build Python itself. Make sure you have installed the latest version of Xcode for your release via the App Store app update pane and that you have installed the corresponding latest version of the Xcode Command Line Tools with:
> 
> xcode-select --install
> 
> Then start with a clean build directory.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26265>
> _______________________________________

----------

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

From report at bugs.python.org  Tue Feb  2 13:51:32 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 18:51:32 +0000
Subject: [issue26233] select.epoll.poll() should avoid calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1454439092.25.0.768036300088.issue26233@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Aside of the performance, my colleague also told me that heavy pressure on the memory allocator can slowly create framgmentation of the heap memory, which is true.

Right, but there are so many other things which contribute to the memory fragmentation.. I doubt that optimizing epoll will make any detectable improvement on that side.

All in all, I think I'm with Serhiy -- since the performance benefits are unclear, we shouldn't complicate the code.

----------

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

From report at bugs.python.org  Tue Feb  2 13:55:11 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 18:55:11 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454439311.46.0.885076221004.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I'm assigning this patch to myself to commit it in 3.6 later.

----------
assignee:  -> yselivanov
components: +Interpreter Core
stage:  -> patch review
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Tue Feb  2 14:03:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 19:03:51 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1454432998.58.0.615586010904.issue26194@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYwRn1GiE7UGZ_4VRAb=jjFnXQm0bRcdLKqqz2iah8MKQ@mail.gmail.com>


STINNER Victor added the comment:

Ok no problem, it was just a suggestion.

In asyncio, we try to document behaviour change but asyncio is different.
Major functions are still modified, asyncio API is still provisional, but
people rely on tehe exact API.

----------

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

From report at bugs.python.org  Tue Feb  2 14:08:09 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 02 Feb 2016 19:08:09 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1454440089.91.0.264320028732.issue26267@psf.upfronthosting.co.za>


SilentGhost added the comment:

The docs seem to clearly show a str(x) as the way to produce the desired form (without braces). https://docs.python.org/3/library/uuid.html#example

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Tue Feb  2 14:09:30 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 02 Feb 2016 19:09:30 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1454440170.58.0.593072045407.issue26267@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

> The docs seem to clearly show a str(x) as the way to produce the desired form (without braces). https://docs.python.org/3/library/uuid.html#example

Please read the last paragraph of the original message.

----------

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

From report at bugs.python.org  Tue Feb  2 14:10:40 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 02 Feb 2016 19:10:40 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454440240.68.0.839073260237.issue26256@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Jurjen, this is very nice! -- Like Mark, I'm not sure if this should be in CPython.


Decimal (Python >= 3.3) has sneaked in a couple of fast bignum
algorithms, so calculating and converting the latest Mersenne
prime takes a couple of seconds:

from decimal import *

c = getcontext()
c.prec = MAX_PREC
c.Emax = MAX_EMAX
c.Emin = MIN_EMIN

x = Decimal(2)**74207281 - 1
s = str(x)
assert s[:12] == "300376418084"
assert s[-12:] == "391086436351"

----------
nosy: +skrah

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

From report at bugs.python.org  Tue Feb  2 14:23:30 2016
From: report at bugs.python.org (Timo Furrer)
Date: Tue, 02 Feb 2016 19:23:30 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1454441010.81.0.441785159191.issue26267@psf.upfronthosting.co.za>


Changes by Timo Furrer <tuxtimo at gmail.com>:


----------
nosy: +tuxtimo

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

From report at bugs.python.org  Tue Feb  2 14:24:17 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Feb 2016 19:24:17 +0000
Subject: [issue26268] Update python.org installers to use OpenSSL 1.0.2f
Message-ID: <1454441057.55.0.0354413518189.issue26268@psf.upfronthosting.co.za>


New submission from Zachary Ware:

http://openssl.org/news/secadv/20160128.txt

----------
components: Build, Macintosh, Windows
messages: 259422
nosy: ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Update python.org installers to use OpenSSL 1.0.2f
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Feb  2 14:24:56 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Feb 2016 19:24:56 +0000
Subject: [issue25798] Update python.org installers to use OpenSSL 1.0.2e
In-Reply-To: <1449261271.59.0.313913873542.issue25798@psf.upfronthosting.co.za>
Message-ID: <1454441096.69.0.472058347394.issue25798@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Actually, this one can be closed now, see issue26268.

----------
nosy: +zach.ware
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  2 14:27:40 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 19:27:40 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1454441259.99.0.380434665806.issue25924@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Hi Jesse, could you please update your patch with a detailed comment summarizing your research?  Also it would be great if you can provide a separate patch for 2.7.

----------
nosy: +yselivanov

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

From report at bugs.python.org  Tue Feb  2 14:38:53 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 02 Feb 2016 19:38:53 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1454441933.56.0.97907579776.issue26267@psf.upfronthosting.co.za>


SilentGhost added the comment:

Well, you seem to suggest we add something to documentation to accommodate people who don't read it in the first place.

----------

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

From report at bugs.python.org  Tue Feb  2 14:58:55 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 02 Feb 2016 19:58:55 +0000
Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120
In-Reply-To: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za>
Message-ID: <1454443135.44.0.401482765645.issue26079@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Perhaps the ideal approach here would be to pass TMP_DIR and OUT_DIR into the Tcl/Tk builds, so we can tell them where to put stuff.  However, that would require major surgery to Tix's makefile to get it to build.  I'd be +1 on doing so (since we're pretty much the de-facto maintainers of Tix at this point, as far as I can tell), but am not enthusiastic about actually doing it.  I'd be much more enthusiastic about deprecating Tix.

Steve, if the patch as given is good enough for you, I'm fine with applying it.

----------
assignee:  -> steve.dower

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

From report at bugs.python.org  Tue Feb  2 15:31:58 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Tue, 02 Feb 2016 20:31:58 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454445118.13.0.87309432274.issue26229@psf.upfronthosting.co.za>


Anders Rundgren added the comment:

In ES6/V8-compatible implementations which include "node.js", Chrome, Firefox, Safari and (of course) my Java reference implementation you can take a cryptographic hash of a JSON object with a predictable result.

That is, this request is in no way limited to JCS.

Other solutions to this problem has been to create something like XML's canonicalization which is much more complex.

The JSON RFC is still valid, it just isn't very useful for people who are interested in security solutions.  The predictable property order introduced in ES6 makes a huge difference!  Now it is just the number thing left...

The other alternative is dressing your JSON objects in Base64 to maintain a predictable signature like in IETF's JOSE.  I doubt that this is going to be mainstream except for OpenID/OAuth which JOSE stems from.

----------

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

From report at bugs.python.org  Tue Feb  2 15:37:15 2016
From: report at bugs.python.org (Zach Byrne)
Date: Tue, 02 Feb 2016 20:37:15 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454445435.64.0.5990284092.issue21955@psf.upfronthosting.co.za>


Zach Byrne added the comment:

I took another look at this, and tried applying it to 3.6 and running the latest benchmarks. It applied cleanly, and the benchmark results were similar, this time unpack_sequence and spectral_norm were slower. Spectral norm makes sense, it's doing lots of FP addition. The unpack_sequence instruction looks like it already has optimizations for unpacking lists and tuples onto the stack, and running dis on the test showed that it's completely dominated calls to unpack_sequence, load_fast, and store_fast so I still don't know what's going on there.

----------

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

From report at bugs.python.org  Tue Feb  2 15:56:51 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2016 20:56:51 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454446611.83.0.416351459115.issue21955@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Any change that increases the cache or branch predictor footprint of the evaluation loop may make the interpreter slower, even if the change doesn't seem related to a particular benchmark. That may be the reason here.

----------

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

From report at bugs.python.org  Tue Feb  2 16:02:01 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 02 Feb 2016 21:02:01 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1454446921.95.0.161558650141.issue26267@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

No, I suggest we add something for users who don't think that a comment in an example is the place to look for documentation, but do think that actual documentation of a class or method is.

----------

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

From report at bugs.python.org  Tue Feb  2 16:06:54 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 02 Feb 2016 21:06:54 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454447214.91.0.208807429667.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

unpack_sequence contains 400 lines of this: "a, b, c, d, e, f, g, h, i, j = to_unpack".  This code doesn't even touch BINARY_SUBSCR or BINARY_ADD.

Zach, could you please run your benchmarks in rigorous mode (perf.py -r)?  I'd also suggest to experiment with putting the baseline cpython as a first arg and as a second -- maybe your machine runs the second interpreter slightly faster.

----------

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

From report at bugs.python.org  Tue Feb  2 16:13:38 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 02 Feb 2016 21:13:38 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1454447618.74.0.735957321513.issue26267@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Andrew is right, this should be documented "properly".

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Tue Feb  2 16:17:50 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Tue, 02 Feb 2016 21:17:50 +0000
Subject: [issue26261] NamedTemporaryFile documentation is vague about the
 `name` attribute
In-Reply-To: <1454347282.51.0.892341568817.issue26261@psf.upfronthosting.co.za>
Message-ID: <1454447870.4.0.21286067996.issue26261@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Antti, would you like to provide a patch? If you don't want to work on it, I can give it a try.

----------
nosy: +beng94

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

From report at bugs.python.org  Tue Feb  2 16:24:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Feb 2016 21:24:55 +0000
Subject: [issue26188] Provide more helpful error message when `await` is
 called inside non-`async` method
In-Reply-To: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za>
Message-ID: <1454448295.85.0.106570524753.issue26188@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not that familiar with the parser either. Maybe I remember a flag or something saying ?we are inside an async def function?, which changes ?await? from a user identifier into a reserved keyword. But I can?t imagine how that flag will help much with this proposal. The problem I think is ?await? is never treated as a reserved keyword when the flag is not set.

----------

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

From report at bugs.python.org  Tue Feb  2 16:32:30 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 02 Feb 2016 21:32:30 +0000
Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120
In-Reply-To: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za>
Message-ID: <1454448750.0.0.181674821155.issue26079@psf.upfronthosting.co.za>


Steve Dower added the comment:

Go ahead. Feel free to add toolsets to cover ICC if you need them.

At one point I was passing through those directories for the build and it was not really trivial. A few too many places where it needed to be handled, but with patches against Tix it's probably disable.

----------

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

From report at bugs.python.org  Tue Feb  2 16:37:44 2016
From: report at bugs.python.org (Ent)
Date: Tue, 02 Feb 2016 21:37:44 +0000
Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible
 usage.
In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za>
Message-ID: <1454449064.3.0.600270108983.issue23255@psf.upfronthosting.co.za>


Changes by Ent <pysplore at gmail.com>:


----------
status: open -> languishing

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

From report at bugs.python.org  Tue Feb  2 16:44:58 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Tue, 02 Feb 2016 21:44:58 +0000
Subject: [issue26269] zipfile should call lstat instead of stat if available
Message-ID: <1454449498.64.0.544045383692.issue26269@psf.upfronthosting.co.za>


New submission from Patrik Dufresne:

To mirror the behavior in tarfile, zipfile should make a call to stat instead of lstat if available.

Failure to do so resolved into an "IOError No such file or directory" if the filename is a symbolik link being broken. As such, the creation of the archive fail.

----------
components: Library (Lib)
messages: 259436
nosy: Patrik Dufresne
priority: normal
severity: normal
status: open
title: zipfile should call lstat instead of stat if available
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Feb  2 16:58:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Feb 2016 21:58:41 +0000
Subject: [issue25774] [benchmarks] Adjust to allow uploading benchmark data to
 codespeed
In-Reply-To: <1448994715.99.0.967922145164.issue25774@psf.upfronthosting.co.za>
Message-ID: <1454450321.35.0.287976846537.issue25774@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

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

From report at bugs.python.org  Tue Feb  2 17:01:21 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 02 Feb 2016 22:01:21 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1454450481.74.0.730245958911.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Second patch with a comment about how we know Mac OS 10.5+'s getaddrinfo is thread-safe. I'll wait for this to be merged before submitting another for Python 2.7.

----------
Added file: http://bugs.python.org/file41784/25924-getaddrinfo-is-thread-safe-2.patch

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

From report at bugs.python.org  Tue Feb  2 17:20:19 2016
From: report at bugs.python.org (Paulo Costa)
Date: Tue, 02 Feb 2016 22:20:19 +0000
Subject: [issue26270] Support for read()/write()/select() on asyncio
Message-ID: <1454451619.12.0.0280470843365.issue26270@psf.upfronthosting.co.za>


New submission from Paulo Costa:

I want to read from file descriptors from async coroutines.

I currently use `loop.add_reader(fd, callback)` and `loop.remove_reader(fd)`

It works, but IMO using callbacks feels completely alien in the middle of a coroutine.

I suggest adding new APIs to handle this. e.g.:
- asyncio.select(fd, mode)
- asyncio.read(fd, num)
- asyncio.write(fd, str)

(It would be nice to support all kinds of IO operations, but these are certainly the most important)

Using the current APIs, the async implementation of read() looks like this:

    async def async_read(fd. n):
        loop = asyncio.get_event_loop()
        future = asyncio.Future()

        def ready():
            future.set_result(os.read(fd, n))
            loop.remove_reader(fd)

        loop.add_reader(fd, ready)
        return future

----------
components: asyncio
messages: 259438
nosy: Paulo Costa, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Support for read()/write()/select() on asyncio
type: enhancement

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

From report at bugs.python.org  Tue Feb  2 17:20:48 2016
From: report at bugs.python.org (Paulo Costa)
Date: Tue, 02 Feb 2016 22:20:48 +0000
Subject: [issue26270] Support for read()/write()/select() on asyncio
In-Reply-To: <1454451619.12.0.0280470843365.issue26270@psf.upfronthosting.co.za>
Message-ID: <1454451648.18.0.468798554927.issue26270@psf.upfronthosting.co.za>


Changes by Paulo Costa <paulo at inutilfutil.com>:


----------
versions: +Python 3.6

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

From report at bugs.python.org  Tue Feb  2 17:24:15 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Tue, 02 Feb 2016 22:24:15 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1454451855.89.0.914305247692.issue25300@psf.upfronthosting.co.za>


Changes by Joseph Hackman <josephhackman at gmail.com>:


----------
nosy: +Joseph.Hackman

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

From report at bugs.python.org  Tue Feb  2 17:26:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 22:26:35 +0000
Subject: [issue26270] Support for read()/write()/select() on asyncio
In-Reply-To: <1454451619.12.0.0280470843365.issue26270@psf.upfronthosting.co.za>
Message-ID: <1454451995.03.0.882507026133.issue26270@psf.upfronthosting.co.za>


STINNER Victor added the comment:

IMHO you misunderstood asyncio design. See examples.

Using add_reader(), lowest level API:
* https://docs.python.org/dev/library/asyncio-eventloop.html#watch-a-file-descriptor-for-read-events

Using a protocol:
* https://docs.python.org/dev/library/asyncio-protocol.html#tcp-echo-client-protocol
* https://docs.python.org/dev/library/asyncio-protocol.html#udp-echo-client-protocol

Using a stream:
* https://docs.python.org/dev/library/asyncio-stream.html#tcp-echo-client-using-streams
* https://docs.python.org/dev/library/asyncio-stream.html#get-http-headers

etc.

----------

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

From report at bugs.python.org  Tue Feb  2 17:27:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 22:27:02 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454452022.35.0.41613373343.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Test with jemalloc using the shell script "python.jemalloc":
> ---
> #!/bin/sh
> LD_PRELOAD=/usr/lib64/libjemalloc.so /home/haypo/prog/python/default/python "$@"
> ---

"perf.py -m" doesn't work with such bash script, but it works using exec:
---
#!/bin/sh
LD_PRELOAD=/usr/lib64/libjemalloc.so exec /home/haypo/prog/python/default/python "$@"
---

> Memory consumption:
python3 -u perf.py -m ../default/python ../default/python.jemalloc


Hum, it looks like jemalloc uses *more* memory than libc memory allocators. I don't know if it's a known 


Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### 2to3 ###
Mem max: 43088.000 -> 43776.000: 1.0160x larger

### chameleon_v2 ###
Mem max: 367028.000 -> 626324.000: 1.7065x larger

### django_v3 ###
Mem max: 23824.000 -> 25120.000: 1.0544x larger

### fastpickle ###
Mem max: 8696.000 -> 9712.000: 1.1168x larger

### fastunpickle ###
Mem max: 8708.000 -> 9696.000: 1.1135x larger

### json_dump_v2 ###
Mem max: 10488.000 -> 11556.000: 1.1018x larger

### json_load ###
Mem max: 8444.000 -> 9396.000: 1.1127x larger

### nbody ###
Mem max: 7392.000 -> 8416.000: 1.1385x larger

### regex_v8 ###
Mem max: 12760.000 -> 13576.000: 1.0639x larger

### tornado_http ###
Mem max: 28196.000 -> 29920.000: 1.0611x larger

----------

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

From report at bugs.python.org  Tue Feb  2 17:27:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 22:27:43 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454452063.04.0.288345036048.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Crap. I sent an incomplete message, sorry about that.)

> Hum, it looks like jemalloc uses *more* memory than libc memory allocators. I don't know if it's a known 

I don't know if it's a known issue/property of jemalloc.

----------

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

From report at bugs.python.org  Tue Feb  2 17:37:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 22:37:34 +0000
Subject: [issue26233] select.epoll.poll() should avoid calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1454452654.4.0.615910502389.issue26233@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy Storchaka: "I'm not sure that it is worth to apply this optimization. The patch adds half a hundred lines of complex code for only 80 ns benefit. On my computer just incrementing an integer takes 100 ns."

Yury Selivanov: "(...) Right, but there are so many other things which contribute to the memory fragmentation.. I doubt that optimizing epoll will make any detectable improvement on that side."

To be honest, I expected better speedup before I ran the benchmark. That's why I repeat that any performance patch must come with a concrete benchmark showing a non-negligible speedup ;-)

I reject my optimization since it doesn't make the code faster.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Tue Feb  2 17:42:34 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Feb 2016 22:42:34 +0000
Subject: [issue25774] [benchmarks] Adjust to allow uploading benchmark data to
 codespeed
In-Reply-To: <1448994715.99.0.967922145164.issue25774@psf.upfronthosting.co.za>
Message-ID: <1454452954.36.0.919276260922.issue25774@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch LGTM, although I'm not sure why the upload script needs to be in the benchmark repo itself.

----------
assignee: brett.cannon -> zach.ware

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

From report at bugs.python.org  Tue Feb  2 18:02:15 2016
From: report at bugs.python.org (Daniel Shaulov)
Date: Tue, 02 Feb 2016 23:02:15 +0000
Subject: [issue26271] freeze.py makefile uses the wrong flags variables
Message-ID: <1454454135.77.0.499921177416.issue26271@psf.upfronthosting.co.za>


New submission from Daniel Shaulov:

Tools/Freeze/makemakefile.py uses CFLAGS, LDFLAGS and CPPFLAGS instead of the PY_ prefixed versions. This makes flags passed to ./configure ineffective.

The patch makes the trivial fix of adding PY_ when needed.

----------
components: Build
files: pyflags.patch
keywords: patch
messages: 259444
nosy: Daniel Shaulov
priority: normal
severity: normal
status: open
title: freeze.py makefile uses the wrong flags variables
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41785/pyflags.patch

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

From report at bugs.python.org  Tue Feb  2 18:14:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Feb 2016 23:14:59 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454454899.92.0.551307386779.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yury: "Please use -r flag for perf.py"

Oh, I didn't know this flag. Sure, I can do that.

New benchmark using --rigorous to measure the performance of attached pymem.patch.

It always seems faster, newer slower.

Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### 2to3 ###
Min: 6.772531 -> 6.686245: 1.01x faster
Avg: 6.875264 -> 6.726859: 1.02x faster
Significant (t=3.44)
Stddev: 0.09026 -> 0.03398: 2.6560x smaller

### django_v3 ###
Min: 0.562797 -> 0.552539: 1.02x faster
Avg: 0.591345 -> 0.557561: 1.06x faster
Significant (t=4.17)
Stddev: 0.07689 -> 0.02581: 2.9794x smaller

### fastpickle ###
Min: 0.464270 -> 0.437667: 1.06x faster
Avg: 0.467195 -> 0.442298: 1.06x faster
Significant (t=10.59)
Stddev: 0.01156 -> 0.02046: 1.7693x larger

### fastunpickle ###
Min: 0.548834 -> 0.526554: 1.04x faster
Avg: 0.554601 -> 0.539456: 1.03x faster
Significant (t=4.67)
Stddev: 0.01137 -> 0.03040: 2.6734x larger

### json_dump_v2 ###
Min: 2.723152 -> 2.603108: 1.05x faster
Avg: 2.749255 -> 2.693655: 1.02x faster
Significant (t=2.89)
Stddev: 0.03016 -> 0.18988: 6.2963x larger

### regex_v8 ###
Min: 0.044256 -> 0.042201: 1.05x faster
Avg: 0.044733 -> 0.043134: 1.04x faster
Significant (t=4.55)
Stddev: 0.00201 -> 0.00288: 1.4309x larger

### tornado_http ###
Min: 0.253405 -> 0.247401: 1.02x faster
Avg: 0.256274 -> 0.250380: 1.02x faster
Significant (t=17.48)
Stddev: 0.00285 -> 0.00382: 1.3430x larger

The following not significant results are hidden, use -v to show them:
chameleon_v2, json_load, nbody.

----------

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

From report at bugs.python.org  Tue Feb  2 18:22:51 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 02 Feb 2016 23:22:51 +0000
Subject: [issue25710] zipimport is not PEP 3147 or PEP 488 compliant
In-Reply-To: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za>
Message-ID: <1454455371.18.0.219318962151.issue25710@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

If you're affected, there's a workaround. Use the following script to rewrite paths in your .zip file to be zipimport-compatible:

https://gist.github.com/ambv/909d38bdac4f3e719b7c

It preserves the preamble and all file metadata.

A little context why this is useful: for archives that are effectively "static" environments with entire dependency trees in them, this bug causes both a big slowdown in startup time (counted in seconds), as well as tens of megabytes of .pyc created on the fly. Examples include zipapp-style .pyz, Twitter's .pex or Facebook's .par. 

So while we're waiting for a new zipimport implementation, the workaround listed above should unblock people uzing this form of Python package distribution.

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Tue Feb  2 19:01:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 00:01:50 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1454457710.98.0.180819781748.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 6: I inlined PyFunction_GetSpecializedCode() into fast_function() of Python/ceval.c. It reduces *a little bit* the overhead of the patch when specialization is not used, but it also avoids to expose this function. I don't think that it's worth to expose PyFunction_GetSpecializedCode(): it was only used in ceval.c. For example, I don't use it for unit tests. I prefer to write tests calling the function and checking the results (see test_pep510.py).

*Raw* overhead of specialized-6.patch on calling "def f(): pass": 1.7 nanoseconds. I computed the overhead using timeit:

./python -m timeit -s 'def f(): pass' 'f()'

* Original: 71.7 ns
* specialize-6.patch: 73.4 ns (+1.7 ns, +2.4%)
* specialize-5.patch: 74.3 ns (+2.6 ns, +3.6%)

I will run perf.py to see the overhead on a macro benchmark.

----------
Added file: http://bugs.python.org/file41786/specialize-6.patch

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

From report at bugs.python.org  Tue Feb  2 19:06:36 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Feb 2016 00:06:36 +0000
Subject: [issue26264] keyword module missing async and await keywords
In-Reply-To: <1454378786.53.0.925531991818.issue26264@psf.upfronthosting.co.za>
Message-ID: <1454457996.81.0.895534568825.issue26264@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Tue Feb  2 19:13:07 2016
From: report at bugs.python.org (Jonas Brunsgaard)
Date: Wed, 03 Feb 2016 00:13:07 +0000
Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get
 is performed, without push to queue.
In-Reply-To: <1454342780.58.0.210365622359.issue26259@psf.upfronthosting.co.za>
Message-ID: <1454458387.63.0.69243083598.issue26259@psf.upfronthosting.co.za>


Jonas Brunsgaard added the comment:

Okay I thoroughly read the code again. Can you describe the architectural changes to the code regarding a patch, I will do a proposal. But I have to know we are on the same page, so I do not waste my and your time :)

----------

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

From report at bugs.python.org  Tue Feb  2 19:21:34 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 03 Feb 2016 00:21:34 +0000
Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get
 is performed, without push to queue.
In-Reply-To: <1454458387.63.0.69243083598.issue26259@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLxODDUHEFX4-HHvk8O9k7mDw88QPirHSCo8ieVSt3AtQ@mail.gmail.com>


Guido van Rossum added the comment:

First, you wrote "The easy solution was to check if the queue was
empty and skip the read (get call) if there was nothing in the queue"
-- which is exactly what get_nowait() does.

As to a patch, I think you should just describe how you would change
the code, then we can talk details.

----------

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

From report at bugs.python.org  Tue Feb  2 19:53:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 00:53:37 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1454460817.26.0.218556336227.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Results of the "The Grand Unified Python Benchmark Suite" on  specialize-6.patch.

I'm skeptical, I don't understand how my patch can make a benchmark faster :-) The result of regex_v8 is bad :-/

$ python3 -u perf.py --rigorous ../default/python.orig ../default/python
(...)
Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### chameleon_v2 ###
Min: 5.558607 -> 5.831682: 1.05x slower
Avg: 5.613403 -> 5.902949: 1.05x slower
Significant (t=-27.95)
Stddev: 0.06994 -> 0.07640: 1.0924x larger

### django_v3 ###
Min: 0.582356 -> 0.573327: 1.02x faster
Avg: 0.604402 -> 0.582197: 1.04x faster
Significant (t=3.43)
Stddev: 0.05618 -> 0.03215: 1.7474x smaller

### regex_v8 ###
Min: 0.043784 -> 0.049854: 1.14x slower
Avg: 0.044270 -> 0.050521: 1.14x slower
Significant (t=-19.87)
Stddev: 0.00200 -> 0.00243: 1.2105x larger

The following not significant results are hidden, use -v to show them:
2to3, fastpickle, fastunpickle, json_dump_v2, json_load, nbody, tornado_http.

----------

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

From report at bugs.python.org  Tue Feb  2 21:08:12 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Feb 2016 02:08:12 +0000
Subject: [issue26265] build errors on OS X 10.11 with --enable-universalsdk
In-Reply-To: <1454425969.86.0.641229022171.issue26265@psf.upfronthosting.co.za>
Message-ID: <1454465292.64.0.549601023308.issue26265@psf.upfronthosting.co.za>


Ned Deily added the comment:

OK, thanks for reporting it.  A couple of things. I'm not sure why the PyQt5 build is looking for the MacOSX10.10.sdk as you report.  There do seem to be some issues building a universal Python when using a current default Xcode SDK; I'm going to leave this issue open to investigate those.  You can get around those issues by using --enable-universalsdk=/ which uses the header files and libraries installed in traditional locations by the Command Line Tools rather than from the SDK locations.  Also, as documented in the Mac README (https://hg.python.org/cpython/file/3.5/Mac/README) where universal builds are described, --with-universal-archs=64-bit is a legacy configuration option that is only supported with an OS X 10.5 SDK, because it includes ppc64 which is no longer supported by current Xcode compilers.  On current systems, building with no --with-universal-archs option specified will produce 64-bit Intel binaries.  Finally, depending on what your needs are, it might be easier to install PyQt5 and Python 3.5 from a third-party distributor, like Homebrew, MacPorts, or conda.

----------
title: errors during static build on OSX -> build errors on OS X 10.11 with --enable-universalsdk
versions: +Python 3.6

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

From report at bugs.python.org  Tue Feb  2 21:59:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Feb 2016 02:59:20 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <1454468360.05.0.720886387929.issue26243@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch at Issue 16764 has a test case for the new level=... keyword. Perhaps you would like to incorporate/update it :)

----------

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

From report at bugs.python.org  Tue Feb  2 22:00:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Feb 2016 03:00:18 +0000
Subject: [issue16764] Make zlib accept keyword-arguments
In-Reply-To: <1356353108.66.0.0747083241018.issue16764@psf.upfronthosting.co.za>
Message-ID: <1454468418.72.0.999545190666.issue16764@psf.upfronthosting.co.za>


Martin Panter added the comment:

See Issue 8706 discussing adding keyword support to library functions in general.

Functions the first patch affects:

* zlib.compress(data, level=...): still relevant; see Issue 26243
* compressobj(memlevel=...): fixed in documentation in revision fdb5d84f9948 instead
* compressobj.compress(data): still relevant, but little benefit IMO
* compressobj.flush(mode=...): still relevant; little benefit
* zlib.decompress(data, wbits=..., bufsize=...): still relevant
* decompressobj.decompress(data, max_length=...): still relevant
* decompressobj.flush(length=...): still relevant, but not worthwhile IMO; see Issue 23200

Most of the pep8 patch looks like pointless noise, and a lot of the remaining bits have probably already been addressed.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Tue Feb  2 22:11:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Feb 2016 03:11:00 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454469060.75.0.809108898663.issue26136@psf.upfronthosting.co.za>


Martin Panter added the comment:

Have you tried running the test suite? I suspect there are tests that will fail. E.g. the tests in revision 2771a0ac806b would need to be changed over to DeprecationWarning as well.

----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Tue Feb  2 22:52:28 2016
From: report at bugs.python.org (Lorenzo Ancora)
Date: Wed, 03 Feb 2016 03:52:28 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454471548.91.0.6110567569.issue26209@psf.upfronthosting.co.za>


Lorenzo Ancora added the comment:

(msg259229) Terry J. Reedy i Suggest that a standard and globally accepted scheme to manage IPv4 addresses is:

  "Host:PortNumber" --> (host, PortNumber)
  "Host"            --> (host, DefaultPortNumber)
  "IP:PortNumber" --> (host, PortNumber)
  "IP"            --> (host, DefaultPortNumber)

...where DefaultPortNumber is protocol and system dependent (IANA standard, see the SMTP line in: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml).

A simple research reveals that all versions of the module are (sadly) poorly documented, but the module is an interface to a very important protocol that indeed must be offered by the standard library.
The only little suggestion in the documentation of the module is: https://docs.python.org/3.6/library/socket.html#socket.socket.accept
...from a one-word link in: https://docs.python.org/3.6/library/smtpd.html#smtpd.SMTPChannel.addr
Which has only an indirect relation with the object itself.

Many users may not recognize the cause of the error if the documentation doesn't explicitate the information to correctly initialize the core objects of the module.
I also Suggest that at least the object should return an helpful error in newer versions of Python.

Thank you for your efforts guys. :-)

----------
components: +Library (Lib)
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb  2 23:52:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Feb 2016 04:52:34 +0000
Subject: [issue26270] Support for read()/write()/select() on asyncio
In-Reply-To: <1454451619.12.0.0280470843365.issue26270@psf.upfronthosting.co.za>
Message-ID: <1454475154.17.0.762721371541.issue26270@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe I misunderstand the asyncio protocols, transports, streams, etc too :) but last time I looked they all seemed to buffer your write data and send it in the background. E.g. in the echo-client-using-streams example, there is a writer.write() call that does not use ?yield from?.

Does asyncio have an easy way for a coroutine to write to a socket (or file descriptor) and block (suspend the coroutine) until the write has finished (or the data fits into a finite buffer)? E.g. how would you upload a multi-megabyte file?

----------
nosy: +martin.panter

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

From report at bugs.python.org  Wed Feb  3 00:39:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Feb 2016 05:39:01 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1454477941.16.0.491640109351.issue25924@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hello Jesse. Maybe Yury might be more qualified here than me to handle OS X stuff (correct me if I?m wrong). I mainly just work with Linux.

But reading around socketmodule.c, it sounds like we want to be able to build it on newer OS versions, but still have it compatible with older versions. If so, how does that MAC_OS_X_VERSION_10_5 macro work? Would some run-time check also be needed?

----------
nosy: +martin.panter

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

From report at bugs.python.org  Wed Feb  3 03:16:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 08:16:19 +0000
Subject: [issue26270] Support for read()/write()/select() on asyncio
In-Reply-To: <1454451619.12.0.0280470843365.issue26270@psf.upfronthosting.co.za>
Message-ID: <1454487379.49.0.949424609616.issue26270@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Paulo Costa:
> async def async_read(fd. n):

This method already exists:
* (TCP) https://docs.python.org/dev/library/asyncio-protocol.html#asyncio.Protocol.data_received
* (UDP) https://docs.python.org/dev/library/asyncio-protocol.html#asyncio.DatagramProtocol.datagram_received
* (TCP) https://docs.python.org/dev/library/asyncio-stream.html#asyncio.StreamReader.read


Martin Panter:
> last time I looked they all seemed to buffer your write data and send it in the background. E.g. in the echo-client-using-streams example, there is a writer.write() call that does not use ?yield from?. Does asyncio have an easy way for a coroutine to write to a socket (or file descriptor) and block (suspend the coroutine) until the write has finished

Sure, you must call https://docs.python.org/dev/library/asyncio-stream.html#asyncio.StreamWriter.drain

----------

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

From report at bugs.python.org  Wed Feb  3 03:48:27 2016
From: report at bugs.python.org (Pengyu Chen)
Date: Wed, 03 Feb 2016 08:48:27 +0000
Subject: [issue26272] `zipfile.ZipFile` fails reading a file object in
 specific version(s)
Message-ID: <1454489307.52.0.490426016128.issue26272@psf.upfronthosting.co.za>


New submission from Pengyu Chen:

When passing a file object to `zipfile.ZipFile` for reading it fails in Python 3.5.1 it fails. While the same code in Python 2.7.11 works.
Also loading that specific file directly from file path works in Python 3.5.1.
(Please see the sample testing code below for details)

[pengyu at GLaDOS tmp]$ echo "test message" > testfile
[pengyu at GLaDOS tmp]$ zip testfile.zip testfile
updating: testfile (stored 0%)
[pengyu at GLaDOS tmp]$ file testfile.zip 
testfile.zip: Zip archive data, at least v1.0 to extract
[pengyu at GLaDOS tmp]$ python -c "a = open('testfile.zip'); import zipfile; b = zipfile.ZipFile(a, 'r')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/zipfile.py", line 1026, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.5/zipfile.py", line 1093, in _RealGetContents
    raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file
[pengyu at GLaDOS tmp]$ python2 -c "a = open('testfile.zip'); import zipfile; b = zipfile.ZipFile(a, 'r')"
[pengyu at GLaDOS tmp]$ python -c "import zipfile; b = zipfile.ZipFile('testfile.zip', 'r')"
[pengyu at GLaDOS tmp]$ python --version
Python 3.5.1
[pengyu at GLaDOS tmp]$ python2 --version
Python 2.7.11

----------
components: Library (Lib)
messages: 259459
nosy: Pengyu Chen
priority: normal
severity: normal
status: open
title: `zipfile.ZipFile` fails reading a file object in specific version(s)
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Feb  3 03:54:44 2016
From: report at bugs.python.org (Omar Sandoval)
Date: Wed, 03 Feb 2016 08:54:44 +0000
Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket
 module
Message-ID: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za>


New submission from Omar Sandoval:

The socket module is missing a couple of TCP socket options: TCP_CONGESTION was added to Linux in v2.6.13 and TCP_USER_TIMEOUT was added in v2.6.37. These should be exposed.

----------
components: Library (Lib)
files: socket_tcp_options.patch
keywords: patch
messages: 259460
nosy: Omar Sandoval
priority: normal
severity: normal
status: open
title: Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41787/socket_tcp_options.patch

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

From report at bugs.python.org  Wed Feb  3 03:56:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Feb 2016 08:56:57 +0000
Subject: [issue26272] `zipfile.ZipFile` fails reading a file object in
 specific version(s)
In-Reply-To: <1454489307.52.0.490426016128.issue26272@psf.upfronthosting.co.za>
Message-ID: <1454489817.07.0.0882804484831.issue26272@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think you are only meant to pass in a ?binary? (bytes) file object. Maybe BufferedIOBase, I?m not sure. The documentation doesn?t seem to make this very clear though. Can you suggest an improvement?

Open the file with

a = open("testfile.zip", "rb")

and all should be well :)

----------
nosy: +martin.panter

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

From report at bugs.python.org  Wed Feb  3 04:03:00 2016
From: report at bugs.python.org (Pengyu Chen)
Date: Wed, 03 Feb 2016 09:03:00 +0000
Subject: [issue26272] `zipfile.ZipFile` fails reading a file object in
 specific version(s)
In-Reply-To: <1454489307.52.0.490426016128.issue26272@psf.upfronthosting.co.za>
Message-ID: <1454490180.57.0.796399100723.issue26272@psf.upfronthosting.co.za>


Pengyu Chen added the comment:

Well I should have noticed that I wasn't using binary mode.. Sorry for the mistake. Closing the issue report.

----------
status: open -> closed

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

From report at bugs.python.org  Wed Feb  3 04:04:02 2016
From: report at bugs.python.org (Pengyu Chen)
Date: Wed, 03 Feb 2016 09:04:02 +0000
Subject: [issue26272] `zipfile.ZipFile` fails reading a file object in
 specific version(s)
In-Reply-To: <1454489307.52.0.490426016128.issue26272@psf.upfronthosting.co.za>
Message-ID: <1454490242.37.0.248682705262.issue26272@psf.upfronthosting.co.za>


Pengyu Chen added the comment:

Oh yes you're right Martin. Thanks for the notice :) (I've closed this ticket before seeing your reply)

----------

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

From report at bugs.python.org  Wed Feb  3 04:36:08 2016
From: report at bugs.python.org (Florin Papa)
Date: Wed, 03 Feb 2016 09:36:08 +0000
Subject: [issue26274] Add CPU affinity to perf.py
Message-ID: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi all,

This is Florin Papa from the Dynamic Scripting Languages Optimizations Team from Intel Corporation.

The patch submitted adds an affinity feature to the Grand Unified Python Benchmarks suite to allow running benchmarks on a given CPU/set of CPUs. It is implemented for Linux and uses the taskset command to bond a command to the CPUs specified. This minimizes run to run variation, as we can get considerable differences in measured performance from running a benchmark on different cores. The taskset command receives a CPU mask that specifies which cores in the system will be used for the command.

Example:
python perf.py ?-affinity=0x1
     will use processor #0
python perf.py ?-affinity=0x3
    will use processors #0 and #1 

Thank you,
Florin

----------
components: Benchmarks
files: affinity.patch
keywords: patch
messages: 259464
nosy: brett.cannon, florin.papa, pitrou
priority: normal
severity: normal
status: open
title: Add CPU affinity to perf.py
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41788/affinity.patch

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

From report at bugs.python.org  Wed Feb  3 04:42:27 2016
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Wed, 03 Feb 2016 09:42:27 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454492547.73.0.915660717034.issue26256@psf.upfronthosting.co.za>


Jurjen N.E. Bos added the comment:

OMG is decimal that fast?
Maybe I should change the issue then to "documentation missing": it nowhere says in the documentation that decimal has optimized multiprecision computations. It only says that precision "can be as large as needed for a given problem", but I never realized that that included millions of digits.
It computed to my complete surprise 2**2**29 to full precision (161 million decimal digits) in about a minute. That smells suspiciously like FFT style multiplication, which implies that it is way more sophisticated than integer multiplication!
I suggest that the documentation of the decimal module recommends using decimal for multiprecision computations, as long as you use the builtin version.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
versions: +Python 3.4 -Python 2.7

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

From report at bugs.python.org  Wed Feb  3 04:51:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 09:51:53 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454493113.31.0.355157643012.issue26256@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"It's great to have this stuff, but I don't think it belongs in core Python: I'd much rather that the core Python integer implementation remain simple, portable and low-maintenance, and work well for the domain it's intended for: small-to-medium size integers."

Yeah I agree. Maybe we need to explain that somewhere? In the devguide? Even in Python doc?

I know that they are super crazy^W fast algorithm to handle very large numbers (hum, what is large? more than 4096 bits?), but they are usually very complex.

Projects like GMP have ultra fast code with optimizations in assemblers. Having assembler implementation is clearly out of the scope of Python.


"Maybe I should change the issue then to "documentation missing": it nowhere says in the documentation that decimal has optimized multiprecision computations."

Well, nowhere means:
https://docs.python.org/dev/whatsnew/3.3.html#decimal

Usually, we don't document performances of a function, maybe only its complexity.

--

You may move to the numpy community which is problably more keen on such optimization than the Python *core*.

----------
nosy: +haypo

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

From report at bugs.python.org  Wed Feb  3 05:00:18 2016
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Wed, 03 Feb 2016 10:00:18 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1454493618.73.0.590664111844.issue26256@psf.upfronthosting.co.za>


Jurjen N.E. Bos added the comment:

That reference you gave says that the binary version is faster than the Python version, but here the _complexity_ actually changed by a lot.
Only people who know the library by name will notice that it is this fast.
But you are right, for 99% of the people it doesn't make much of a difference.

----------

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

From report at bugs.python.org  Wed Feb  3 05:03:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 10:03:02 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454493782.51.0.493877758242.issue26274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I like the feature, but I would prefer to use a syntax like --affinity=0-2 to use cores 0, 1 and 2, rather than having to compute manually a binary mask (--affinity=3).

It's a builtin feature of taskset: just use --cpu-list.

----------
nosy: +haypo

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

From report at bugs.python.org  Wed Feb  3 05:03:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 10:03:15 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454493795.75.0.722379586968.issue26274@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +yselivanov

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

From report at bugs.python.org  Wed Feb  3 05:03:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 10:03:21 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454493801.38.0.493131801403.issue26274@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
type:  -> performance

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

From report at bugs.python.org  Wed Feb  3 05:38:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 10:38:49 +0000
Subject: [issue26275] perf.py: bm_regex_v8 doesn't seem reliable even with
 --rigorous
Message-ID: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi, I'm working on some optimizations projects like FAT Python (PEP 509: issue #26058, PEP 510: issue #26098, and PEP 511: issue #26145) and faster memory allocators (issue #26249).

I have the *feeling* that perf.py output is not reliable even if it takes more than 20 minutes :-/ Maybe because Yury told that I must use -r (--rigorous) :-)

Example with 5 runs of "python3 perf.py ../default/python ../default/python.orig -b regex_v8":

---------------
Report on Linux smithers 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### regex_v8 ###
Min: 0.043237 -> 0.050196: 1.16x slower
Avg: 0.043714 -> 0.050574: 1.16x slower
Significant (t=-19.83)
Stddev: 0.00171 -> 0.00174: 1.0178x larger

### regex_v8 ###
Min: 0.042774 -> 0.051420: 1.20x slower
Avg: 0.043843 -> 0.051874: 1.18x slower
Significant (t=-14.46)
Stddev: 0.00351 -> 0.00176: 2.0009x smaller

### regex_v8 ###
Min: 0.042673 -> 0.048870: 1.15x slower
Avg: 0.043726 -> 0.050474: 1.15x slower
Significant (t=-8.74)
Stddev: 0.00283 -> 0.00467: 1.6513x larger

### regex_v8 ###
Min: 0.044029 -> 0.049445: 1.12x slower
Avg: 0.044564 -> 0.049971: 1.12x slower
Significant (t=-13.97)
Stddev: 0.00175 -> 0.00211: 1.2073x larger

### regex_v8 ###
Min: 0.042692 -> 0.049084: 1.15x slower
Avg: 0.044295 -> 0.050725: 1.15x slower
Significant (t=-7.00)
Stddev: 0.00421 -> 0.00494: 1.1745x larger
---------------

I'm only care of the "Min", IMHO it's the most interesting information here.

The slowdown is betwen 12% and 20%, for me it's a big difference.


It looks like some benchmarks have very short iterations compare to others. For example, bm_json_v2 takes around 3 seconds, whereas bm_regex_v8 only takes less than 0.050 second (50 ms).

$ python3 performance/bm_json_v2.py -n 3 --timer perf_counter
3.310384973010514
3.3116717970115133
3.3077902760123834

$ python3 performance/bm_regex_v8.py -n 3 --timer perf_counter
0.0670697659952566
0.04515827298746444
0.045114840992027894

Do you think that bm_regex_v8 is reliable? I see that there is an "iteration scaling" to use run the benchmarks with more iterations. Maybe we can start to increase the "iteration scaling" for bm_regex_v8?

Instead of a fixed number of iterations, we should redesign benchmarks to use time. For example, one iteration must take at least 100 ms and should not take more than 1 second (but take longer to get more reliable results). Then the benchmark is responsible to ajust internal parameters.

I used this design for my "benchmark.py" script which is written to get "reliable" microbenchmarks:
https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py?fileviewer=file-view-default

The script is based on time and calibrate a benchmark. It also uses the *effictive* resolution of the clock used by the benchmark to calibrate the benchmark.

I will maybe work on such patch, but it would be good to know first your opinion on such change.

I guess that we should use the base python to calibrate the benchmark and then pass the same parameters to the modified python.

----------
components: Benchmarks
messages: 259469
nosy: brett.cannon, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: perf.py: bm_regex_v8 doesn't seem reliable even with --rigorous
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Wed Feb  3 05:39:32 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Wed, 03 Feb 2016 10:39:32 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1454495972.32.0.147172093256.issue21042@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Added a small patch that solves this issue on Ubuntu 15.10.

Produces output like:
/lib/x86_64-linux-gnu/libm.so.6
/lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libbz2.so.1.0

I'd be glad to add some test cases if someone can give me some tips on how to do that.

----------
keywords: +patch
nosy: +beng94
Added file: http://bugs.python.org/file41789/find_lib.patch

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

From report at bugs.python.org  Wed Feb  3 05:41:36 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 03 Feb 2016 10:41:36 +0000
Subject: [issue26256] Fast decimalisation and conversion to other bases
In-Reply-To: <1454493113.31.0.355157643012.issue26256@psf.upfronthosting.co.za>
Message-ID: <20160203104125.GA17635@bytereef.org>


Stefan Krah added the comment:

On Wed, Feb 03, 2016 at 09:51:53AM +0000, STINNER Victor wrote:
> Well, nowhere means:
> https://docs.python.org/dev/whatsnew/3.3.html#decimal

Okay, but hardly anyone reads that, and I can't blame them. :)

For example, if I use something like Lua, I won't read a release announcement
from 2012.

> Usually, we don't document performances of a function, maybe only its complexity.

As Jurjen said, the presence of the FFT (actually fast number theoretic
transform here) in Decimal is something completely unexpected, so if there's
a place for a line or two in the docs that makes some users happy I'd be
in favor of it.

----------

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

From report at bugs.python.org  Wed Feb  3 06:18:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 11:18:27 +0000
Subject: [issue26275] perf.py: bm_regex_v8 doesn't seem reliable even with
 --rigorous
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454498307.25.0.165794042707.issue26275@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Well, it was simpler than I expected to implement calibration. Here is a PoC for regex_v8 and json_dump_v2.

json_dump_v2 takes 3 seconds per run, but it already uses internally 100 loop iterations. I divided the number of iterations by 100 in my patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file41790/perf_calibration.patch

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

From report at bugs.python.org  Wed Feb  3 06:39:10 2016
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 03 Feb 2016 11:39:10 +0000
Subject: [issue26276] Inconsistent behaviour of PEP 3101 formatting between
 versions
Message-ID: <1454499550.19.0.0724839464997.issue26276@psf.upfronthosting.co.za>


New submission from Mark Shannon:

In Python 2.7.6 and 3.2.3:
>>> "{ {{ 0} }}".format(**{' {{ 0} }': 'X'})
'X'

In Python 3.4.3:
>>> "{ {{ 0} }}".format(**{' {{ 0} }': 'X'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unexpected '{' in field name


I think the problem is that PEP 3101 is under specified w.r.t. to non identifier characters in format units.

----------
components: Interpreter Core
messages: 259473
nosy: Mark Shannon
priority: normal
severity: normal
status: open
title: Inconsistent behaviour of PEP 3101 formatting between versions
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  3 06:47:34 2016
From: report at bugs.python.org (Florin Papa)
Date: Wed, 03 Feb 2016 11:47:34 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454500054.96.0.432332372545.issue26274@psf.upfronthosting.co.za>


Florin Papa added the comment:

Thank you for the feedback. Please see the updated patch.

----------
Added file: http://bugs.python.org/file41791/affinity_v2.patch

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

From report at bugs.python.org  Wed Feb  3 07:02:44 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 03 Feb 2016 12:02:44 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454500964.02.0.0526607043025.issue26209@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Doc fixes unrelated to security fixes are not applied to security-fix-only versions.

----------
versions:  -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb  3 07:23:51 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Feb 2016 12:23:51 +0000
Subject: [issue26276] Inconsistent behaviour of PEP 3101 formatting between
 versions
In-Reply-To: <1454499550.19.0.0724839464997.issue26276@psf.upfronthosting.co.za>
Message-ID: <1454502231.22.0.911951610634.issue26276@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Wed Feb  3 07:25:04 2016
From: report at bugs.python.org (flying sheep)
Date: Wed, 03 Feb 2016 12:25:04 +0000
Subject: [issue26277] Allow zipapp to target modules
Message-ID: <1454502304.42.0.453397075525.issue26277@psf.upfronthosting.co.za>


New submission from flying sheep:

currently, zipapp?s notion of __main__.py is very different from the usual.

the root directory of a zipapp is not a module, therefore __init__.py isn?t used and relative imports from __main__.py don?t work.

i propose that the zipapp functionality is amended/changed to

1. allow more than one target directory (bundle multiple modules)
2. allow creation of a __main__.py that contains a runpy-powered module runner

so maybe we could specify the module itself as entry point to get this behavior

zipapp -m my_module dependency.py my_module

should create

my_module.pyz
? __main__.py  ?  ...runpy.run_module('my_module')
? dependency.py
? my_module
  ? __init__.py
  ? __main__.py  ?  from . import ...

or there would be another option to specify it.

----------
components: Extension Modules
messages: 259476
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Allow zipapp to target modules
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Feb  3 07:26:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 12:26:05 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454500054.96.0.432332372545.issue26274@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY=k8t1vU6Z+OS1y+BdD8MSwRZx4vk2d4cKh7cxd1n6+w@mail.gmail.com>


STINNER Victor added the comment:

I don't think that it's useful to check at runtime that taskset works. At
least, I expect an error if the option is used and the command fails.

To use CPU affinity you need to know your hardware and your platform. For
most stable results you may even configure the Linux kernel to ignore some
cores. So i expect that users will not play with affinity if they don't
understand it.

----------

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

From report at bugs.python.org  Wed Feb  3 07:29:20 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Feb 2016 12:29:20 +0000
Subject: [issue26276] Inconsistent behaviour of PEP 3101 formatting between
 versions
In-Reply-To: <1454499550.19.0.0724839464997.issue26276@psf.upfronthosting.co.za>
Message-ID: <1454502560.78.0.865766164494.issue26276@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Hi, Mark.

Yes, PEP 3101 is very much under-specified in this area. I tried to avoid the same mistake in PEP 498, although of course that's a different problem area.

I don't recall why this particular case broke between 3.2.3 and 3.4.3. I'll try and track it down. I'm sure we were trying to "fix" some other edge condition.

FWIW, in 3.4.3 this also fails, as expected:
>>> "{ {{ 0} }}".format_map({' {{ 0} }': 'X'})

Can you try it in 3.2.3? I expect it to work, but you never know.

----------

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

From report at bugs.python.org  Wed Feb  3 08:10:10 2016
From: report at bugs.python.org (Florin Papa)
Date: Wed, 03 Feb 2016 13:10:10 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454505010.56.0.65058988701.issue26274@psf.upfronthosting.co.za>


Florin Papa added the comment:

I have updated the patch to throw an exception if the taskset command is not available. Not checking that taskset works will generate an ambiguous error (if there is no taskset on the system) that does not explicitly point to the problem.

I believe that users working on performance have knowledge on the platform and OS setup they are using and they will draw benefit from this feature because it gives more accurate results.

----------
Added file: http://bugs.python.org/file41792/affinity_v3.patch

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

From report at bugs.python.org  Wed Feb  3 08:46:51 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Wed, 03 Feb 2016 13:46:51 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1454507211.49.0.65618530099.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Thanks Martin. The MAC_OS_X_VERSION_10_5 macro ensures that Python is still compatible with Mac OS before version 10.5: if it's built on 10.4 or older, it locks around getaddrinfo (since it's not thread-safe there), and on 10.5 and later it doesn't lock.

I've built on a Mac OS 10.4 virtual machine and verified we'll still use the lock on that OS.

I think this is good enough, without a runtime check. We distribute prebuilt binaries for Mac OS 10.5+:

https://www.python.org/downloads/release/python-2711/

So those prebuilt Pythons should no longer lock around getaddrinfo. 

People who still use older Mac OSes (more than 12 years old!) will have to build Python themselves in order to get recent versions of Python, since we don't distribute binaries for them any more. Since they're building Python on old Mac OS, the MAC_OS_X_VERSION_10_5 macro will be undefined and they'll keep using the getaddrinfo lock.

----------

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

From report at bugs.python.org  Wed Feb  3 08:47:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 13:47:53 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454507273.91.0.535846933979.issue26274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, I modified your change:

* only display a warning if the option is used but taskset doesn't work
* remove check on Linux: taskset might be available on other platforms, it doesn't really matter to check the OS, we already check if the command works
* try to run "taskset --cpu-list 0 python -c pass" instead of "taskset -V" to check if taskset works or not

What do you think?

----------
Added file: http://bugs.python.org/file41793/affinity_warning.patch

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

From report at bugs.python.org  Wed Feb  3 08:50:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 13:50:24 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454507424.91.0.442711796278.issue26275@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +florin.papa
title: perf.py: bm_regex_v8 doesn't seem reliable even with --rigorous -> perf.py: calibrate benchmarks using time, not using a fixed number of iterations

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

From report at bugs.python.org  Wed Feb  3 08:55:51 2016
From: report at bugs.python.org (Florin Papa)
Date: Wed, 03 Feb 2016 13:55:51 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454507751.4.0.892418129867.issue26274@psf.upfronthosting.co.za>


Florin Papa added the comment:

I was thinking that a warning might go unnoticed, that is why I chose to 
end the program if taskset is not found. It would force the user to
install missing packages.

Otherwise the patch looks ok.

----------

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

From report at bugs.python.org  Wed Feb  3 09:22:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 14:22:36 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454509356.36.0.000470428522683.issue26274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Florent: "I was thinking that a warning might go unnoticed, that is why I chose to end the program if taskset is not found."

Oh right, I kept your behaviour and pushed a change.

---
changeset:   238:a97acad3bbf7
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Wed Feb 03 15:20:02 2016 +0100
files:       perf.py
description:
Add --affinity command line option

If used, run the benchmark using taskset to pin the process to a set of CPU
cores to reduce context switching. See taskset manual page for more information.

Patch written by Florin Papa.
---

----------

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

From report at bugs.python.org  Wed Feb  3 09:22:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 14:22:47 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454509367.07.0.829234645457.issue26274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for your contribution ;-)

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Feb  3 09:25:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 14:25:01 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454509367.07.0.829234645457.issue26274@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYnVFc2bcoatvt7RqJax2DtrNcsEgdqpKiTfzK9xywpFw@mail.gmail.com>


STINNER Victor added the comment:

"Florent" oops, Florin, sorry :-p

----------

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

From report at bugs.python.org  Wed Feb  3 09:35:06 2016
From: report at bugs.python.org (Florin Papa)
Date: Wed, 03 Feb 2016 14:35:06 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454510106.14.0.70636201694.issue26274@psf.upfronthosting.co.za>


Florin Papa added the comment:

No problem :)

----------
resolution: fixed -> 
status: closed -> open

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

From report at bugs.python.org  Wed Feb  3 09:45:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 14:45:20 +0000
Subject: [issue26274] Add CPU affinity to perf.py
In-Reply-To: <1454492168.34.0.115069633072.issue26274@psf.upfronthosting.co.za>
Message-ID: <1454510720.51.0.816714296285.issue26274@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Feb  3 10:15:03 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 15:15:03 +0000
Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket
 module
In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za>
Message-ID: <1454512503.24.0.731124060531.issue26273@psf.upfronthosting.co.za>


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


----------
nosy: +yselivanov

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

From report at bugs.python.org  Wed Feb  3 10:57:36 2016
From: report at bugs.python.org (=?utf-8?q?S=C3=BCmer_Cip?=)
Date: Wed, 03 Feb 2016 15:57:36 +0000
Subject: [issue26278] BaseTransport.close() does not trigger connection_lost()
Message-ID: <1454515056.72.0.0290408111031.issue26278@psf.upfronthosting.co.za>


New submission from S?mer Cip:

Hi all,

We have implemented a TCP server based on asyncio. And while doing some regression tests we randomly see following error:

1) Client connects to the server.
2) Client is closed ungracefully(without sending a FIN, deplug cable)
3) We have a custom PING handler that sends a PING and waits for PONG message.
4) After a while, we see that we timeout for the PING and we call close() on the Transport object. 

Now, most of the time, above just works fine, but at some point, somehow connection_lost() is NEVER gets called even though we call close() on the socket. As this issue is happening very randomly I don't have any asyncio logs for it. But can you think about any scenario that might lead to this somehow? 

Somehow, it seems we have an outgoing data in the TCP buffer when this happens and that is why the close() does not call the connection_lost immediately, but why it is never calling it is a mystery to me. Can that be following:

1) we call close() and is_closing is set to true we have outgoing data so we return.
2) Then a subsequent write occurs and connection ConnectionResetError() is raised and this calls _force_close(), but as we have previously set is_closing to True, connection_lost() does not get called.

Above is just a very trivial idea which is probably is not the case, I do not spend too much time on the code. 

Thanks,

----------
components: asyncio
messages: 259487
nosy: S?mer.Cip, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: BaseTransport.close() does not trigger connection_lost()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  3 11:02:51 2016
From: report at bugs.python.org (Ioannis Aslanidis)
Date: Wed, 03 Feb 2016 16:02:51 +0000
Subject: [issue26279] Possible bug in time library
Message-ID: <1454515371.52.0.00863631935711.issue26279@psf.upfronthosting.co.za>


New submission from Ioannis Aslanidis:

There seems to be a bug in the time library when performing the following conversion:

"""
In [8]: mytime=time.strptime(str([2015, 53, 0]), '[%Y, %U, %w]')

In [9]: mytime
Out[9]: time.struct_time(tm_year=2016, tm_mon=1, tm_mday=3, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=368, tm_isdst=-1)

In [10]: time.strftime('%Y %U', mytime)
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-10-c13538c08ea5> in <module>()
----> 1 time.strftime('%Y %U', mytime)

ValueError: day of year out of range 
"""

As you can observe, tm_yday got a value of 368 instead of 3. It seems that the C function is not properly subtracting 365 or 366 days when converting from week 53 of a particular year which, according to ISO 8601 [1] and per python documentation [2]. Documentation explicitly says that: "The first week of the year is the week with the year's first Thursday in it".

[1] https://en.wikipedia.org/wiki/ISO_8601#Week_dates
[2] https://docs.python.org/2/library/time.html

----------
components: Library (Lib)
messages: 259488
nosy: iaslan
priority: normal
severity: normal
status: open
title: Possible bug in time library
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Feb  3 11:13:43 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 03 Feb 2016 16:13:43 +0000
Subject: [issue26279] time.strptime does not properly convert out-of-bounds
 values
In-Reply-To: <1454515371.52.0.00863631935711.issue26279@psf.upfronthosting.co.za>
Message-ID: <1454516023.82.0.677090176005.issue26279@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
nosy: +ebarry
title: Possible bug in time library -> time.strptime does not properly convert out-of-bounds values
versions:  -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb  3 11:22:38 2016
From: report at bugs.python.org (Anish Shah)
Date: Wed, 03 Feb 2016 16:22:38 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454516558.63.0.271904450099.issue26136@psf.upfronthosting.co.za>


Anish Shah added the comment:

Yes @martin.panter, the tests were failing. But, I didn't know where the tests for PendingDeprecationWarning were added. Thanks for telling the changeset. I have updated the patch. Can you please have a look?

----------
Added file: http://bugs.python.org/file41794/issue26136_20160203.patch

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

From report at bugs.python.org  Wed Feb  3 11:40:31 2016
From: report at bugs.python.org (Zach Byrne)
Date: Wed, 03 Feb 2016 16:40:31 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454517631.38.0.576031269512.issue21955@psf.upfronthosting.co.za>


Zach Byrne added the comment:

I ran 6 benchmarks on my work machine(not the same one as the last set) overnight.
Two with just the BINARY_ADD change, two with the BINARY_SUBSCR change, and two with both.
I'm attaching the output from all my benchmark runs, but here are the highlights
In this table I've flipped the results for running the modified build as the reference, but in the new attachment, slower in the right column means faster, I think :)
|------------------|---------------------------------------|-----------------------------------|
|Build             | Baseline Reference                    | Modified Reference                |
|------------------|--------------------|------------------|--------------------|--------------|
|                  | Faster             | Slower           | Faster             | Slower       |
|------------------|--------------------|------------------|--------------------|--------------|
|BINARY_ADD        | chameleon_v2       | etree_parse      | chameleon_v2       | call_simple  |
|                  | chaos              | nbody            | fannkuch           | nbody        |
|                  | django             | normal_startup   | normal_startup     | pickle_dict  |
|                  | etree_generate     | pickle_dict      | nqueens            | regex_v8     |
|                  | fannkuch           | pickle_list      | regex_compile      |              |
|                  | formatted_logging  | regex_effbot     | spectral_norm      |              |
|                  | go                 |                  | unpickle_list      |              |
|                  | json_load          |                  |                    |              |
|                  | regex_compile      |                  |                    |              |
|                  | simple_logging     |                  |                    |              |
|                  | spectral_norm      |                  |                    |              |
|------------------|--------------------|------------------|--------------------|--------------|
|BINARY_SUBSCR     | chameleon_v2       | call_simple      | 2to3               | etree_parse  |
|                  | chaos              | go               | call_method_slots  | json_dump_v2 |
|                  | etree_generate     | pickle_list      | chaos              | pickle_dict  |
|                  | fannkuch           | telco            | fannkuch           |              |
|                  | fastpickle         |                  | formatted_logging  |              |
|                  | hexiom2            |                  | go                 |              |
|                  | json_load          |                  | hexiom2            |              |
|                  | mako_v2            |                  | mako_v2            |              |
|                  | meteor_contest     |                  | meteor_contest     |              |
|                  | nbody              |                  | nbody              |              |
|                  | regex_v8           |                  | normal_startup     |              |
|                  | spectral_norm      |                  | nqueens            |              |
|                  |                    |                  | pickle_list        |              |
|                  |                    |                  | simple_logging     |              |
|                  |                    |                  | spectral_norm      |              |
|                  |                    |                  | telco              |              |
|------------------|--------------------|------------------|--------------------|--------------|
|BOTH              | chameleon_v2       | call_simple      | chameleon_v2       | fastpickle   |
|                  | chaos              | etree_parse      | choas              | pickle_dict  |
|                  | etree_generate     | pathlib          | etree_generate     | pickle_list  |
|                  | etree_process      | pickle_list      | etree_process      | telco        |
|                  | fannkuch           |                  | fannkuch           |              |
|                  | fastunpickle       |                  | float              |              |
|                  | float              |                  | formatted_logging  |              |
|                  | formatted_logging  |                  | go                 |              |
|                  | hexiom2            |                  | hexiom2            |              |
|                  | nbody              |                  | nbody              |              |
|                  | nqueens            |                  | normal_startup     |              |
|                  | regex_v8           |                  | nqueens            |              |
|                  | spectral_norm      |                  | simple_logging     |              |
|                  | unpickle_list      |                  | spectral_norm      |              |
|------------------|--------------------|------------------|--------------------|--------------|

unpack_sequence is nowhere to be seen and spectral_norm is faster now...

----------
Added file: http://bugs.python.org/file41795/bench_results.txt

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

From report at bugs.python.org  Wed Feb  3 12:00:24 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 17:00:24 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454518824.58.0.481862737212.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching a new patch -- rewritten to optimize -, *, +, -=, *= and +=.  I also removed the optimization of [] operator -- that should be done in a separate patch and in a separate issue.

Some nano-benchmarks (best of 3):

python -m timeit  "sum([x + x + 1 for x in range(100)])"
2.7: 7.71     3.5: 8.54      3.6: 7.33

python -m timeit  "sum([x - x - 1 for x in range(100)])"
2.7: 7.81     3.5: 8.59      3.6: 7.57

python -m timeit  "sum([x * x * 1 for x in range(100)])"
2.7: 9.28     3.5: 10.6      3.6: 9.44


Python 3.6 vs 3.5 (spectral_norm, rigorous run):
Min: 0.315917 -> 0.276785: 1.14x faster
Avg: 0.321006 -> 0.284909: 1.13x faster


Zach, thanks a lot for the research!  I'm glad that unpack_sequence finally proved to be irrelevant.  Could you please take a look at the updated patch?

----------
Added file: http://bugs.python.org/file41796/fastint1.patch

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

From report at bugs.python.org  Wed Feb  3 12:02:18 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 17:02:18 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
Message-ID: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

See also issue #21955

----------
components: Interpreter Core
messages: 259492
nosy: haypo, yselivanov, zbyrne
priority: normal
severity: normal
stage: needs patch
status: open
title: ceval: Optimize [] operation similarly to CPython 2.7
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Wed Feb  3 12:05:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 17:05:22 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454518824.58.0.481862737212.issue21955@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaARXgeGZbZ_BwB0tiSt38f6ewaG43WNPr+Jzups-FKYQ@mail.gmail.com>


STINNER Victor added the comment:

> python -m timeit  "sum([x * x * 1 for x in range(100)])"

If you only want to benchmark x*y, x+y and list-comprehension, you
should use a tuple for the iterator.

----------

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

From report at bugs.python.org  Wed Feb  3 12:07:18 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Feb 2016 17:07:18 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454519238.65.0.729137432903.issue21955@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> In this table I've flipped the results for running the modified build > as the reference, but in the new attachment, slower in the right
> column means faster, I think :)

I don't understand what this table means (why 4 columns?). Can you explain what you did?

----------

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

From report at bugs.python.org  Wed Feb  3 12:15:50 2016
From: report at bugs.python.org (Zach Byrne)
Date: Wed, 03 Feb 2016 17:15:50 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454519750.44.0.817883185358.issue21955@psf.upfronthosting.co.za>


Zach Byrne added the comment:

> I don't understand what this table means (why 4 columns?). Can you explain what you did?

Yury suggested running perf.py twice with the binaries swapped
So "faster" and "slower" underneath "Baseline Reference" are runs where the unmodified python binary was the first argument to perf, and the "Modified Reference" is where the patched binary is the first argument.

ie. "perf.py -r -b all python patched_python" vs "perf.py -r -b all patched_python python"

bench_results.txt has the actual output in it, and the "slower in the right column" comment was referring to the contents of that file, not the table. Sorry for the confusion.

----------

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

From report at bugs.python.org  Wed Feb  3 12:21:01 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 17:21:01 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454520061.84.0.704726214583.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Yury suggested running perf.py twice with the binaries swapped

Yeah, I had some experience with perf.py when its results were skewed depending on what you test first.  Hopefully Victor's new patch will fix that http://bugs.python.org/issue26275

----------

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

From report at bugs.python.org  Wed Feb  3 12:36:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Feb 2016 17:36:37 +0000
Subject: [issue26277] Allow zipapp to target modules
In-Reply-To: <1454502304.42.0.453397075525.issue26277@psf.upfronthosting.co.za>
Message-ID: <1454520997.79.0.0374289115032.issue26277@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +paul.moore

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

From report at bugs.python.org  Wed Feb  3 12:47:22 2016
From: report at bugs.python.org (Zach Byrne)
Date: Wed, 03 Feb 2016 17:47:22 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454521642.46.0.806173990286.issue21955@psf.upfronthosting.co.za>


Zach Byrne added the comment:

> Could you please take a look at the updated patch?
Looks ok to me, for whatever that's worth.

----------

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

From report at bugs.python.org  Wed Feb  3 12:48:17 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Wed, 03 Feb 2016 17:48:17 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <1454521697.55.0.180211466678.issue26243@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Added the "suggested" test

----------
Added file: http://bugs.python.org/file41797/zlib-compress-level-keyword3.patch

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

From report at bugs.python.org  Wed Feb  3 12:52:40 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Feb 2016 17:52:40 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454520061.84.0.704726214583.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B23E64.8090907@free.fr>


Antoine Pitrou added the comment:

Le 03/02/2016 18:21, Yury Selivanov a ?crit :
> 
> Yury Selivanov added the comment:
> 
>> Yury suggested running perf.py twice with the binaries swapped
> 
> Yeah, I had some experience with perf.py when its results were
> skewed
depending on what you test first.

Have you tried disabling turbo on your CPU? (or any kind of power
management that would change the CPU clock depending on the current
workload)

----------

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

From report at bugs.python.org  Wed Feb  3 13:50:03 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 03 Feb 2016 18:50:03 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <CAMpsgwaARXgeGZbZ_BwB0tiSt38f6ewaG43WNPr+Jzups-FKYQ@mail.gmail.com>
Message-ID: <56B24BD6.2080600@egenix.com>


Marc-Andre Lemburg added the comment:

On 03.02.2016 18:05, STINNER Victor wrote:
> 
>> python -m timeit  "sum([x * x * 1 for x in range(100)])"
> 
> If you only want to benchmark x*y, x+y and list-comprehension, you
> should use a tuple for the iterator.

... and precalculate that in the setup:

python -m timeit -s "loops=tuple(range(100))" "sum([x * x * 1 for x in loops])"

# python -m timeit "sum([x * x * 1 for x in range(100)])"
100000 loops, best of 3: 5.74 usec per loop
# python -m timeit -s "loops=tuple(range(100))" "sum([x * x * 1 for x in loops])"
100000 loops, best of 3: 5.56 usec per loop

(python = Python 2.7)

----------
nosy: +lemburg

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

From mal at egenix.com  Wed Feb  3 13:49:58 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 3 Feb 2016 19:49:58 +0100
Subject: [issue21955] ceval.c: implement fast path for integers with a
 single digit
In-Reply-To: <CAMpsgwaARXgeGZbZ_BwB0tiSt38f6ewaG43WNPr+Jzups-FKYQ@mail.gmail.com>
References: <CAMpsgwaARXgeGZbZ_BwB0tiSt38f6ewaG43WNPr+Jzups-FKYQ@mail.gmail.com>
Message-ID: <56B24BD6.2080600@egenix.com>

On 03.02.2016 18:05, STINNER Victor wrote:
> 
>> python -m timeit  "sum([x * x * 1 for x in range(100)])"
> 
> If you only want to benchmark x*y, x+y and list-comprehension, you
> should use a tuple for the iterator.

... and precalculate that in the setup:

python -m timeit -s "loops=tuple(range(100))" "sum([x * x * 1 for x in loops])"

# python -m timeit "sum([x * x * 1 for x in range(100)])"
100000 loops, best of 3: 5.74 usec per loop
# python -m timeit -s "loops=tuple(range(100))" "sum([x * x * 1 for x in loops])"
100000 loops, best of 3: 5.56 usec per loop

(python = Python 2.7)

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Wed Feb  3 14:01:50 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Feb 2016 19:01:50 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454526110.16.0.104856254357.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[Martin]
>  the default branch never got any NEWS entry in 
> 58266f5101cc, so maybe it needs to be added?

No need for a news entry in default.  We haven't released 3.6 yet, so the bugfix from 3.5 is just a carry forward of the corrected behavior.  That isn't news ;-)

[Martin]
> revision 0731f097157b didn?t actually merge the 3.5 
> branch (It only had one parent)

I'm not sure I see what was missed here (I am not a mercurial jedi).  My 3.5 checkout shows the change and so does the 3.6.   What needs to be done at this point ?

[Serhiy]
> This isn't new feature, this is just a bugfix, old behavior
> obviously was incorrect. We don't add the versionchanged 
> directive for every bugfix.

I concur with Serhiy.

----------

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

From report at bugs.python.org  Wed Feb  3 14:04:03 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 19:04:03 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454526243.48.0.15837117905.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Antoine, yeah, it's probably turbo boost related.  There is no easy way to turn it off on mac os x, though.  I hope Victor's patch to perf.py will help to mitigate this. 

Victor, Marc-Andre,

Updated results of nano-bench (best of 10):

-m timeit -s "loops=tuple(range(100))" "sum([x * x * 1 for x in loops])"
2.7  8.5     3.5  10.1     3.6  8.91

-m timeit -s "loops=tuple(range(100))" "sum([x + x + 1 for x in loops])"
2.7  7.27    3.5  8.2      3.6  7.13

-m timeit -s "loops=tuple(range(100))" "sum([x - x - 1 for x in loops])"
2.7  7.01    3.5  8.1      3.6  6.95

Antoine, Serhiy, I'll upload a new patch soon.  Probably Serhiy's idea of using a switch statement will make it slightly faster.  I'll also add a fast path for integer division.

----------

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

From report at bugs.python.org  Wed Feb  3 14:19:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Feb 2016 19:19:30 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454527170.46.0.930610822266.issue21955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fast patch is already implemented in long_mul(). May be we should just use this function if both arguments are exact int, and apply the switch optimization inside.

----------

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

From report at bugs.python.org  Wed Feb  3 14:22:36 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 19:22:36 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454527356.61.0.378681007902.issue26275@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Here's a very interesting table from Zach Byrne: http://bugs.python.org/issue21955#msg259490

It shows that some benchmarks are indeed very unstable.  This also correlates with my own experience.

These ones are very unstable: pickle_dict, nbody, regex_v8, etree_parse, telco.

----------
nosy: +zbyrne

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

From report at bugs.python.org  Wed Feb  3 14:26:33 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 19:26:33 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454527593.2.0.571016269773.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Fast patch is already implemented in long_mul(). May be we should just use this function if both arguments are exact int, and apply the switch optimization inside.

Agree.

BTW, what do you think about using __int128 when available?  That way we can also optimize twodigit PyLongs.

----------

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

From report at bugs.python.org  Wed Feb  3 14:29:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 19:29:16 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454527593.2.0.571016269773.issue21955@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ5UWnnw64ouT=1kT7wKSSoL+jd2XOfFTd8n9Z+G_Y42w@mail.gmail.com>


STINNER Victor added the comment:

I don't think. I run benchmarks (for __int128) :-)

----------

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

From report at bugs.python.org  Wed Feb  3 14:30:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Feb 2016 19:30:00 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454527800.13.0.635267262595.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> No need for a news entry in default.  We haven't released 3.6 yet, so the bugfix from 3.5 is just a carry forward of the corrected behavior.  That isn't news ;-)

NEWS entries for 3.5.2 are not included in the NEWS file for 3.6. Usually we add bugfix NEWS entries in all branches that take the fix.

> What needs to be done at this point ?

It is too late to do anything except add a NEWS entry. Branches were merged by Martin when his applied next patch.

----------

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

From report at bugs.python.org  Wed Feb  3 14:35:22 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 19:35:22 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454528122.52.0.475137536085.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I don't think. I run benchmarks (for __int128) :-)

Never mind...  Seems that __int128 is still an experimental feature and some versions of clang even had bugs with it.

----------

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

From report at bugs.python.org  Wed Feb  3 14:43:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Feb 2016 19:43:20 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454528600.93.0.464204210132.issue21955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> BTW, what do you think about using __int128 when available?  That way we can also optimize twodigit PyLongs.

__int128 is not always available and it will add too much of complexity for possible less gain. There is many ways to optimize the code and we should to choose those of them that have the best gain/complexity ratio.

Lets split the patch on smaller parts: 1) direct using long-specialized functions in ceval.c, and 2) optimize the fast path in these functions, and test them separately and combined. May be only one way will add a gain.

----------

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

From report at bugs.python.org  Wed Feb  3 14:56:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Feb 2016 19:56:42 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454529402.15.0.0602173531103.issue26275@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If running time is close to the limit, different run will use different number of repetitions. This will add additional instability. I prefer a stable number of repetitions manually calibrated for average modern computer.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Wed Feb  3 15:15:40 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 03 Feb 2016 20:15:40 +0000
Subject: [issue25774] [benchmarks] Adjust to allow uploading benchmark data to
 codespeed
In-Reply-To: <1448994715.99.0.967922145164.issue25774@psf.upfronthosting.co.za>
Message-ID: <1454530540.53.0.792448758094.issue25774@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fair point, I'll leave out the upload script.

Thanks for the review!

----------

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

From report at bugs.python.org  Wed Feb  3 15:18:16 2016
From: report at bugs.python.org (Zach Byrne)
Date: Wed, 03 Feb 2016 20:18:16 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454530696.71.0.720511330843.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

Yury,
Are you going to tackle this one, or would you like me to?

----------

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

From report at bugs.python.org  Wed Feb  3 15:19:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 03 Feb 2016 20:19:48 +0000
Subject: [issue25774] [benchmarks] Adjust to allow uploading benchmark data to
 codespeed
In-Reply-To: <1448994715.99.0.967922145164.issue25774@psf.upfronthosting.co.za>
Message-ID: <20160203201944.11221.81418@psf.io>


Roundup Robot added the comment:

New changeset 9923b81a1d34 by Zachary Ware in branch 'default':
Issue #25774: Add raw mode to perf.py.
https://hg.python.org/benchmarks/rev/9923b81a1d34

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Feb  3 15:20:05 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 03 Feb 2016 20:20:05 +0000
Subject: [issue25774] [benchmarks] Adjust to allow uploading benchmark data to
 codespeed
In-Reply-To: <1448994715.99.0.967922145164.issue25774@psf.upfronthosting.co.za>
Message-ID: <1454530805.07.0.180162411259.issue25774@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Feb  3 15:27:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Feb 2016 20:27:35 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454531255.47.0.204480559461.issue26280@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Would be nice to collect statistics about arguments types during running the testsuite. May be list is not the most popular type of collection.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Wed Feb  3 15:33:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Feb 2016 20:33:03 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454529402.15.0.0602173531103.issue26275@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZOoS34w+qksYLmMgLtgZAT5supV_7dv76ifrGX-yEppA@mail.gmail.com>


STINNER Victor added the comment:

> If running time is close to the limit, different run will use different number of repetitions. This will add additional instability.

Maybe, to be honest I don't know. How can we decide if a patch makes
perf.py more and less stable?

> I prefer a stable number of repetitions manually calibrated for average modern computer.

The problem is to define an "average modern computer".

----------

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

From report at bugs.python.org  Wed Feb  3 15:39:54 2016
From: report at bugs.python.org (Simon Cross)
Date: Wed, 03 Feb 2016 20:39:54 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454531994.02.0.784214618439.issue26252@psf.upfronthosting.co.za>


Changes by Simon Cross <hodgestar at gmail.com>:


----------
nosy: +hodgestar

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

From report at bugs.python.org  Wed Feb  3 15:42:36 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 20:42:36 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454532156.31.0.882525082177.issue26280@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Zach, first I was going to collect some stats on this (as Serhiy also suggests).  It would be interesting to collect some stats on how many times BINARY_SUBSCR receives lists, tuples, dicts, and other types.  I'd instrument the code to collect those stats and run Python tests suite and benchmarks.

I'm pretty sure that optimizing lists (and tuples?) is a great idea.  It would also be nice to optimize [-1] lookup.  I'd also measure if we should add a fast path for dicts (PyDict_CheckExact + PyDict_GetItem).

If you have time to work on this issue, then by all means go ahead.  We'll be glad to assist you and review the patch.

----------

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

From report at bugs.python.org  Wed Feb  3 15:58:10 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 03 Feb 2016 20:58:10 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454533090.29.0.96022983455.issue26280@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Zach, BTW, you can see how I instrumented ceval for stats collection in the patch for issue #26219.  That's only for the research purposes, we won't commit that... or maybe we will, but in a separate issue :).

----------

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

From report at bugs.python.org  Wed Feb  3 16:11:00 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Feb 2016 21:11:00 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
Message-ID: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Would it make sense to clear sys.path_importer_cache when someone calls importlib.invalidate_caches()? It is a cache after all.

----------
components: Library (Lib)
messages: 259518
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Clear sys.path_importer_cache from importlib.invalidate_caches()
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Feb  3 16:20:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Feb 2016 21:20:11 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454534411.12.0.793556774244.issue26194@psf.upfronthosting.co.za>


Martin Panter added the comment:

I thought the 3.6.0 NEWS file generally listed bugs fixed since (at least) the 3.5.0 release. But the NEWS in default has no mention of Issue 26194.

Serhiy is right that there is nothing more to do for the merging problem. I was just pointing out that something in your ?merge? commit must have not worked properly. Normally a merge looks like revision 58266f5101cc (there are two parents listed). But in this case I pulled from default expecting to get all the 3.5 changes as well, but never got your latest 3.5 change until I pulled it explicitly.

----------

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

From report at bugs.python.org  Wed Feb  3 16:36:10 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Wed, 03 Feb 2016 21:36:10 +0000
Subject: [issue24905] Allow incremental I/O to blobs in sqlite3
In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za>
Message-ID: <1454535370.61.0.267883827579.issue24905@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I did the needed changes for the pull request at pysqlite for porting to python3. I will continue updating the patch if there will be changes in pysqlite and vice versa.

----------
keywords: +patch
Added file: http://bugs.python.org/file41798/blob.patch

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

From report at bugs.python.org  Wed Feb  3 16:44:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Feb 2016 21:44:16 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
Message-ID: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently extension functions either accept only positional-only arguments (PyArg_ParseTuple), or keyword arguments (PyArg_ParseTupleAndKeywords). While adding support passing by keywords looks good for some arguments, for other arguments it doesn't make much sense. For example "encoding" and "errors" arguments for str or "base" argument for int are examples of good keyword arguments, but it is hard to choose good name for the first argument.

I suggest to allow to add the support of keyword arguments only for the part of arguments, while left other arguments positional-only. This issue consists from two stages:

1. Allow PyArg_ParseTupleAndKeywords to accept empty string "" as keywords and interpret this as positional-only argument.

2. Make Argument Clinic to generate code for partial keyword arguments. The syntax already supports this: "/" separates positional-only arguments from keyword arguments.

----------
messages: 259521
nosy: larry, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add support for partial keyword arguments in extension functions
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Feb  3 17:15:59 2016
From: report at bugs.python.org (Francis MB)
Date: Wed, 03 Feb 2016 22:15:59 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1454537759.66.0.81188696519.issue26219@psf.upfronthosting.co.za>


Francis MB added the comment:

>From the two checks on Python/compile.c:

+ expr_ty meth = e->v.Call.func;
[...]
+    /* Check [...] that
+       the call doesn't have keyword parameters. */
[...]
+    /* Check that there are no *varargs types of arguments. */
[...]

I just wonder how many times those kind of checks/guards are done
on the whole Cpython code base (the second one seems expensive).

(Naive Idea):
Wouldn't be some kind of fast function description (e.g. bit flags
or 'e->v.Call.func.desc') generally helpful? The function description
could have: 'has_keywords' or 'has_varargs', ... 

Thanks in advance!

----------
nosy: +francismb

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

From report at bugs.python.org  Wed Feb  3 19:46:02 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 00:46:02 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1454546762.76.0.655307899617.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> From the two checks on Python/compile.c:

Stuff done in compile.c is cached in *.pyc files.

The for-loop you saw shouldn't take a lot of time - it iterates through function parameters, which an average function doesn't have more than 3-6.

----------

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

From report at bugs.python.org  Wed Feb  3 21:19:28 2016
From: report at bugs.python.org (=?utf-8?b?5by15Lyv6Kqg?=)
Date: Thu, 04 Feb 2016 02:19:28 +0000
Subject: [issue26283] zipfile can not handle the path build by os.path.join()
Message-ID: <1454552368.89.0.734714115407.issue26283@psf.upfronthosting.co.za>


New submission from ???:

I think the built-in library zipfile.py does not handle correctly the path build by os.path.join().

For example, assuming we have a zipfile named Test.zip which contanins a member xml/hello.xml,
if you want to extract the member out, then you hava to use 'xml/hello.xml', if using os.path.join('xml','hello.xml'), you will get an error. 

Platform: Windows7, Python3.4

>>> import zipfile,os
>>> f=zipfile.ZipFile("Test.zip",'r')
>>> f.extract('xml/hello.xml','.') # OK.
>>> f.extract(os.path.join('xml','hello.xml'),'.') # does not work.

If we fixed the zipfile.py, inside the method getinfo(self,name) of class ZipFile:

before:
    def getinfo(self, name):
        """Return the instance of ZipInfo given 'name'."""      
        info = self.NameToInfo.get(name)

        if info is None:
            raise KeyError(
                'There is no item named %r in the archive' % name)

        return info

after:
    def getinfo(self, name):
        """Return the instance of ZipInfo given 'name'."""
        if os.sep=='\\' and os.sep in name:
            name=name.replace('\\','/')
            
        info = self.NameToInfo.get(name)
        if info is None:
            raise KeyError(
                'There is no item named %r in the archive' % name)

        return info

Then this line work!
>>>  f.extract(os.path.join('xml','hello.xml'),'.') # OK!

of course, this line also work:
>>> f.extract('xml/hello.xml','.') # also OK!


I think it is a bug. Why?
Let's we take a closer look at the method:

info = self.NameToInfo.get(name)

The keys of NameToInfo are always the format "xxx/yyy" according to the document of class ZipInfo:

    def __init__(self, filename="NoName", date_time=(1980,1,1,0,0,0)):
 
        # This is used to ensure paths in generated ZIP files always use
        # forward slashes as the directory separator, as required by the
        # ZIP format specification.
        
        if os.sep != "/" and os.sep in filename:
            
            filename = filename.replace(os.sep, "/")

Hence the method getinfo(self,name) of class ZipFile always get KeyError for the path build os.path.join('xxx','yyy')


Thnaks for reading!
Bocheng.

----------
components: Library (Lib)
messages: 259524
nosy: ???
priority: normal
severity: normal
status: open
title: zipfile can not handle the path build by os.path.join()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  3 21:22:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 04 Feb 2016 02:22:28 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1454552548.83.0.447367199037.issue26282@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the examples you gave, they already seem to support keywords for the first parameter: int(x=0), str(object=""), bytes(source=b""). Maybe it is a bit unfortunate that they are inconsistent, but these names seem reasonable when considered separately.

But I agree that in those cases having the option of a keyword would rarely be useful. This proposal sounds like it could give a small benefit, and I guess it wouldn?t be costly to implement.

----------

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

From report at bugs.python.org  Wed Feb  3 21:51:03 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Feb 2016 02:51:03 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <1454554263.34.0.381853326909.issue25660@psf.upfronthosting.co.za>


Berker Peksag added the comment:

With rlcompleter.patch applied, I see the same behavior on my OS X (with libedit) and Ubuntu (with readline) systems.

Thanks!

----------
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Feb  3 21:56:50 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Feb 2016 02:56:50 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1454554610.38.0.891460212572.issue13501@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed Feb  3 22:26:13 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Feb 2016 03:26:13 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454556373.11.0.696020894411.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I can't say that I agree with putting an additional entry the 3.6 NEWS.   In the past, I've not made news entries in unreleased versions regarding bug fixes in prior versions.  That seems pointless to me and it would tend to clutter a document whose size already gets in the way of its usability.

----------

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

From report at bugs.python.org  Wed Feb  3 22:40:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 04 Feb 2016 03:40:04 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1454557204.44.0.767721380471.issue21042@psf.upfronthosting.co.za>


Martin Panter added the comment:

IMO this should be treated as a new feature for the next release. But consistently returning the path sounds good to me if there is no good reason not to.

Left a question on the review. I think you also need to update the documentation, and since this is changing documented behaviour it probably needs a What?s New entry.

For tests, I would try doing something like find_library("c"), and ensuring that the result is an absolute path. We may have to end up skipping the test for platforms like Windows where this is not expected to work. Look through the files in /Lib/ctypes/test/ for a good place for it to live (if there isn?t already a test there you can modify).

----------
nosy: +martin.panter
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Wed Feb  3 22:43:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 04 Feb 2016 03:43:36 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454557416.37.0.70060868684.issue26136@psf.upfronthosting.co.za>


Martin Panter added the comment:

FYI I found that changeset by doing annotate on the file that you originally changed <https://hg.python.org/cpython/annotate/default/Objects/genobject.c#l181>, which is an index of the changesets that last modified each line.

Thanks for the patch, I think it is generally good. Perhaps this also needs a short notice in What?s New, a bit like <https://docs.python.org/3/whatsnew/3.5.html#deprecated-python-behavior>?

----------

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

From report at bugs.python.org  Thu Feb  4 01:02:49 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 06:02:49 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454565769.63.0.45194845637.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching a second version of the patch.  (BTW, Serhiy, I tried your idea of using a switch statement to optimize branches (https://github.com/1st1/cpython/blob/fastint2/Python/ceval.c#L5390) -- no detectable speed improvement).


I decided to add fast path for floats & single-digit longs and their combinations.  +, -, *, /, //, and their inplace versions are optimized now.  


I'll have a full result of macro-benchmarks run tomorrow morning, but here's a result for spectral_norm (rigorous run, best of 3):

### spectral_norm ###
Min: 0.300269 -> 0.233037: 1.29x faster
Avg: 0.301700 -> 0.234282: 1.29x faster
Significant (t=399.89)
Stddev: 0.00147 -> 0.00083: 1.7619x smaller


Some nano-benchmarks (best of 3):

-m timeit -s "loops=tuple(range(100))" "sum([x + x + 1 for x in loops])"
2.7  7.23    3.5  8.17      3.6  7.57

-m timeit -s "loops=tuple(range(100))" "sum([x + x + 1.0 for x in loops])"
2.7  9.08    3.5  11.7      3.6  7.22

-m timeit -s "loops=tuple(range(100))" "sum([x/2.2 + 2 + x*2.5 + 1.0 for x in loops])"
2.7  17.9    3.5  24.3      3.6  11.8

----------
Added file: http://bugs.python.org/file41799/fastint2.patch

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

From report at bugs.python.org  Thu Feb  4 01:19:48 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Feb 2016 06:19:48 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <1454566788.34.0.472642516772.issue25660@psf.upfronthosting.co.za>


Ned Deily added the comment:

LGTM on OS X with both the system libedit and a MacPorts GNU readline.  Let's apply this.

----------

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

From report at bugs.python.org  Thu Feb  4 01:25:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 04 Feb 2016 06:25:23 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <20160204062520.20011.83013@psf.io>


Roundup Robot added the comment:

New changeset 64417e7a1760 by Yury Selivanov in branch '3.5':
Issue #25660: Fix TAB key behaviour in REPL.
https://hg.python.org/cpython/rev/64417e7a1760

New changeset 87dfadd61e0d by Yury Selivanov in branch 'default':
Merge 3.5 (issue #25660)
https://hg.python.org/cpython/rev/87dfadd61e0d

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Feb  4 01:26:29 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 06:26:29 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <1454567189.87.0.000224867553977.issue25660@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Let's apply this.

Merged.  Martin, Berker, and Ned, thanks for testing this patch out.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 01:38:24 2016
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 04 Feb 2016 06:38:24 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454567904.67.0.563239991621.issue26182@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Thank you Brett, your explanation (msg259409) and the c-api doc are really straightforward. I think I can fix it in a few days, just the time to read the devguide and be confident about the workflow.

----------

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

From report at bugs.python.org  Thu Feb  4 01:56:32 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Feb 2016 06:56:32 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <1454568992.94.0.697159309917.issue25660@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Yury!

Look like we forgot to update test_rcompleter:

======================================================================
FAIL: test_complete (test.test_rlcompleter.TestRlcompleter)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/ssd/buildbot/buildarea/3.5.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_rlcompleter.py", line 82, in test_complete
    self.assertEqual(completer.complete('', 0), '\t')
AssertionError: '' != '\t'
+ 

http://buildbot.python.org/all/builders/ARMv7%20Ubuntu%203.5/builds/576/steps/test/logs/stdio

----------

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

From report at bugs.python.org  Thu Feb  4 02:15:21 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 04 Feb 2016 07:15:21 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454570121.08.0.105337882792.issue26136@psf.upfronthosting.co.za>


Anish Shah added the comment:

Thanks @martin.panter. I learnt something new, I didn't know about annotate before.
I have updated the patch.
Thanks again.

----------
Added file: http://bugs.python.org/file41800/issue26136_20160204.patch

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

From report at bugs.python.org  Thu Feb  4 02:20:25 2016
From: report at bugs.python.org (JitterMan)
Date: Thu, 04 Feb 2016 07:20:25 +0000
Subject: [issue26115] pathlib.glob('**') returns only directories
In-Reply-To: <1452806432.12.0.827592335617.issue26115@psf.upfronthosting.co.za>
Message-ID: <1454570425.49.0.877982689389.issue26115@psf.upfronthosting.co.za>


JitterMan added the comment:

It may be what the documentation says it will do, but is not what it should do. I believe that because:

1. Currently ** in pathlib matches only directories, but **.py matches files. That seems inconsistent.
2. In bash, and csh, ** matches files and directories. To get the same in pathlib one must use **/*, which is inconsistent with what we have used for many decades.
3. With the traditional meaning of **, it is easy to constrain the match to directories by adding slash to the end of the glob (just use **/).
4. There is considerable value in supporting the traditional meaning of glob strings. Globbing is a very powerful feature, and it is often offered to the end user in shell-like situations. For example, sftp offers globbing. When offering globbing to the end users it is best to be consistent the globbing they are already familiar with.
5. There is no significant advantage to the difference between pathlib globbing and traditional globbing.

Globbing in pathlib is different from traditional globbing in another important way. pathlib does not distinguish between hidden files and directories and normal files and directories.  There may be isolated cases where that is preferred, but generally that is not true. Indeed, the primary characteristic of being hidden is that it should not be included in globbing. One marks a file or directory to be hidden specifically to mean 'do not include this one when selecting groups of files or directories'. Once the glob string has been expanded, it is possible to filter out the hidden files and directories, but it very difficult to do if there are several levels of directories because when weeding out the matches that should not be be included you have to look for hidden items at all levels of the path.

Globbing has been available and largely unchanged for almost 50 years. I encourage you to strongly consider making pathlib globbing more consistent with what we have all grown up with.

----------

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

From report at bugs.python.org  Thu Feb  4 02:24:37 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 04 Feb 2016 07:24:37 +0000
Subject: [issue26283] zipfile can not handle the path build by os.path.join()
In-Reply-To: <1454552368.89.0.734714115407.issue26283@psf.upfronthosting.co.za>
Message-ID: <1454570677.31.0.238662461954.issue26283@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Thu Feb  4 02:25:04 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 04 Feb 2016 07:25:04 +0000
Subject: [issue26115] pathlib.glob('**') returns only directories
In-Reply-To: <1452806432.12.0.827592335617.issue26115@psf.upfronthosting.co.za>
Message-ID: <1454570704.55.0.0676035564735.issue26115@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Feb  4 02:29:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 04 Feb 2016 07:29:30 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <1454570970.42.0.637412983634.issue25660@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also the Windows buildbots, where the Readline module is not available, but ?rlcompleter? still (used to) work.

----------
status: closed -> open

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

From report at bugs.python.org  Thu Feb  4 02:34:54 2016
From: report at bugs.python.org (JitterMan)
Date: Thu, 04 Feb 2016 07:34:54 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
In-Reply-To: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>
Message-ID: <1454571294.2.0.134787800981.issue26096@psf.upfronthosting.co.za>


JitterMan added the comment:

Globbing has been with us for almost 50 years, and in all that time it has never matched the hidden files/directories. There may be isolated cases where matching the hidden items is preferred, but generally that is not the case. Indeed, the primary characteristic of being hidden is that it should not be included in globbing. One marks a file or directory to be hidden specifically to mean 'do not include this one when selecting groups of files or directories'.

Once the glob string has been expanded, it is possible to filter out the hidden files and directories, but it very difficult to do so if there are several levels of directories because one has to look for hidden items at all levels of the path.

Globbing has been available and largely unchanged for almost 50 years. I am not the one that is asking for it to be changed. I am asking for it to be returned to what it has always been. Being consistent with bash and other shells is a very important feature. It allows us to offer pathlib globbing to the end user and have it work the way they expect.

----------

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

From report at bugs.python.org  Thu Feb  4 02:38:09 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 04 Feb 2016 07:38:09 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454571489.46.0.865283769774.issue26252@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Thu Feb  4 02:43:02 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 04 Feb 2016 07:43:02 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1454571782.72.0.36652391682.issue26282@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Thu Feb  4 02:46:01 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 04 Feb 2016 07:46:01 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
In-Reply-To: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>
Message-ID: <1454571961.86.0.758205287868.issue26281@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Thu Feb  4 02:56:06 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 04 Feb 2016 07:56:06 +0000
Subject: [issue26263] Serialize array.array to JSON by default
In-Reply-To: <1454352639.9.0.0979042510265.issue26263@psf.upfronthosting.co.za>
Message-ID: <1454572566.23.0.145187489832.issue26263@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From mal at egenix.com  Thu Feb  4 02:57:58 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 4 Feb 2016 08:57:58 +0100
Subject: [issue21955] ceval.c: implement fast path for integers with a
 single digit
In-Reply-To: <1454565769.63.0.45194845637.issue21955@psf.upfronthosting.co.za>
References: <1454565769.63.0.45194845637.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B30486.9020207@egenix.com>

On 04.02.2016 07:02, Yury Selivanov wrote:
> Attaching a second version of the patch.  (BTW, Serhiy, I tried your idea of using a switch statement to optimize branches (https://github.com/1st1/cpython/blob/fastint2/Python/ceval.c#L5390) -- no detectable speed improvement).

It would be better to consistently have the fast_*() helpers
return -1 in case of an error, instead of -1 or 1.

Overall, I see two problems with doing too many of these
fast paths:

 * the ceval loop may no longer fit in to the CPU cache on
   systems with small cache sizes, since the compiler will likely
   inline all the fast_*() functions (I guess it would be possible
   to simply eliminate all fast paths using a compile time
   flag)

 * maintenance will get more difficult

In a numerics heavy application it's like that all fast paths
will trigger somewhere, but those will likely be better off
using numpy or numba. For a text heavy application such as a web
server, only few fast paths will trigger and so the various
checks only add overhead.

Since 'a'+'b' is a very often used instruction type in the
latter type of applications, please make sure that this fast
path gets more priority in your patch.

Please also check the effects of the fast paths for cases
where they don't trigger, e.g. 'a'+'b' or 'a'*2.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Thu Feb  4 02:58:06 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 04 Feb 2016 07:58:06 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454565769.63.0.45194845637.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B30486.9020207@egenix.com>


Marc-Andre Lemburg added the comment:

On 04.02.2016 07:02, Yury Selivanov wrote:
> Attaching a second version of the patch.  (BTW, Serhiy, I tried your idea of using a switch statement to optimize branches (https://github.com/1st1/cpython/blob/fastint2/Python/ceval.c#L5390) -- no detectable speed improvement).

It would be better to consistently have the fast_*() helpers
return -1 in case of an error, instead of -1 or 1.

Overall, I see two problems with doing too many of these
fast paths:

 * the ceval loop may no longer fit in to the CPU cache on
   systems with small cache sizes, since the compiler will likely
   inline all the fast_*() functions (I guess it would be possible
   to simply eliminate all fast paths using a compile time
   flag)

 * maintenance will get more difficult

In a numerics heavy application it's like that all fast paths
will trigger somewhere, but those will likely be better off
using numpy or numba. For a text heavy application such as a web
server, only few fast paths will trigger and so the various
checks only add overhead.

Since 'a'+'b' is a very often used instruction type in the
latter type of applications, please make sure that this fast
path gets more priority in your patch.

Please also check the effects of the fast paths for cases
where they don't trigger, e.g. 'a'+'b' or 'a'*2.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

----------

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

From report at bugs.python.org  Thu Feb  4 03:01:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 08:01:51 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454572911.13.0.88138778729.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"In a numerics heavy application it's like that all fast paths will trigger somewhere, but those will likely be better off using numpy or numba. For a text heavy application such as a web server, only few fast paths will trigger and so the various checks only add overhead."

Hum, I disagree. See benchmark results in other messages. Examples:

### django_v2 ###
Min: 2.682884 -> 2.633110: 1.02x faster

### unpickle_list ###
Min: 1.333952 -> 1.212805: 1.10x faster

These benchmarks are not written for numeric, but are more "general" benchmarks. int is just a core feature of Python, simply used everywhere, as the str type.

----------

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

From report at bugs.python.org  Thu Feb  4 03:13:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 08:13:35 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454573615.56.0.108105825094.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+        if (Py_SIZE(left) != 0) {
+            if (Py_SIZE(right) != 0) {
+
+#ifdef HAVE_LONG_LONG
+                mul = PyLong_FromLongLong(
+                        (long long)SINGLE_DIGIT_LONG_AS_LONG(left) *
+                            SINGLE_DIGIT_LONG_AS_LONG(right));
+#else
+                mul = PyNumber_Multiply(left, right);
+#endif

Why don't you use the same code than long_mul() (you need #include "longintrepr.h")?
----------------
        stwodigits v = (stwodigits)(MEDIUM_VALUE(a)) * MEDIUM_VALUE(b);
#ifdef HAVE_LONG_LONG
        return PyLong_FromLongLong((PY_LONG_LONG)v);
#else
        /* if we don't have long long then we're almost certainly
           using 15-bit digits, so v will fit in a long.  In the
           unlikely event that we're using 30-bit digits on a platform
           without long long, a large v will just cause us to fall
           through to the general multiplication code below. */
        if (v >= LONG_MIN && v <= LONG_MAX)
            return PyLong_FromLong((long)v);
#endif
----------------

I guess that long_mul() was always well optimized, no need to experiment something new.

----------

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

From report at bugs.python.org  Thu Feb  4 03:33:48 2016
From: report at bugs.python.org (Florin Papa)
Date: Thu, 04 Feb 2016 08:33:48 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454574828.65.0.393434283286.issue26275@psf.upfronthosting.co.za>


Florin Papa added the comment:

I have tested the patch and it does not seem to solve the stability
problem.

With patch:
python performance/bm_json_v2.py -n 10 --timer perf_counter
0.02829067991115153
0.027778947027400136
0.027756798081099987
0.027362094027921557
0.027256828034296632
0.02766443998552859
0.027390124974772334
0.027398303849622607
0.02731629996560514
0.02743363007903099

Without patch:
python performance/bm_json_v2.py -n 10 --timer perf_counter
2.732215315802023
2.7394272631499916
2.731212269049138
2.7511520159896463
2.739834441104904
2.754247901029885
2.734024364966899
2.7447318979538977
2.744731454877183
2.7513630259782076

Instead, I notice that, especially for the first runs, the measured
values tend to be higher. This is expected, since the cache has not
been populated yet, but this can also happen after a context switch.
Therefore, we could eliminate these "odd" values by calculating the
median value of all the runs and only keeping measurements within 1%
of that median value.

What do you think?

----------

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

From report at bugs.python.org  Thu Feb  4 03:39:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 08:39:51 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454575191.59.0.818374659825.issue26275@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> With patch:
> python performance/bm_json_v2.py -n 10 --timer perf_counter

Oh. There is a bit of confusion here. You must *not* run directly bm_xxx.py scripts. The calibration is done in perf.py.

Try for example:
python perf.py python2 python3 -b json_dump_v2

You must see something like:
Calibrating => num_runs=10, num_loops=16 (0.50 sec < 0.55 sec)

I should maybe share the calibration code to also compute the number of iterations when a bm_xxx.py script is run directly? But the risk is that someone compares two runs of bm_xxx.py using two python binaries, and seeing different results just because the number of calibrated loops is different...

----------

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

From report at bugs.python.org  Thu Feb  4 03:56:21 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 04 Feb 2016 08:56:21 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454572911.13.0.88138778729.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B3122F.4010500@egenix.com>


Marc-Andre Lemburg added the comment:

On 04.02.2016 09:01, STINNER Victor wrote:
> 
> "In a numerics heavy application it's like that all fast paths will trigger somewhere, but those will likely be better off using numpy or numba. For a text heavy application such as a web server, only few fast paths will trigger and so the various checks only add overhead."
> 
> Hum, I disagree. See benchmark results in other messages. Examples:
> 
> ### django_v2 ###
> Min: 2.682884 -> 2.633110: 1.02x faster
> 
> ### unpickle_list ###
> Min: 1.333952 -> 1.212805: 1.10x faster
> 
> These benchmarks are not written for numeric, but are more "general" benchmarks. int is just a core feature of Python, simply used everywhere, as the str type.

Sure, some integer math is used in text applications as well,
e.g. for indexing, counting and slicing, but the patch puts more
emphasis on numeric operations, e.g. fast_add() tests for integers
and floats before then coming back to check for Unicode.

It would be interesting to know how often these paths trigger
or not in the various benchmarks.

BTW: The django_v2 benchmark result does not really say
anything much. Values of +/- 2% do not have much meaning in
benchmark results :-)

----------

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

From report at bugs.python.org  Thu Feb  4 04:24:03 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 09:24:03 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454577843.54.0.992494292733.issue26275@psf.upfronthosting.co.za>


Stefan Krah added the comment:

In my experience it is very hard to get stable benchmark results with Python.  Even long running benchmarks on an empty machine vary:

wget http://www.bytereef.org/software/mpdecimal/benchmarks/telco.py
wget http://speleotrove.com/decimal/expon180-1e6b.zip
unzip expon180-1e6b.zip

taskset -c 0 ./python telco.py full


$ taskset -c 0 ./python telco.py full

Control totals:
Actual   ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17']
Elapsed time: 7.16255
$ taskset -c 0 ./python telco.py full

Control totals:
Actual   ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17']
Elapsed time: 6.982884
$ taskset -c 0 ./python telco.py full

Control totals:
Actual   ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17']
Elapsed time: 7.095349000000001
$ taskset -c 0 ./python telco.py full

Control totals:
Actual   ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17']

----------
nosy: +skrah

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

From report at bugs.python.org  Thu Feb  4 04:27:46 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 09:27:46 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454578066.7.0.545623662429.issue26275@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I've cut off the highest result in the previous message:

Control totals:
Actual   ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17']
Elapsed time: 7.304339
$ taskset -c 0 ./python telco.py full

----------

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

From report at bugs.python.org  Thu Feb  4 04:28:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 09:28:12 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454578092.52.0.60440636195.issue26275@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> taskset -c 0 ./python telco.py full

Did you see that I just merged Florin's patch to add --affinity parameter to perf.py? :-)

You may isolate some CPU cores using the kernel command parameter isolcpus=xxx. I don't think that the core #0 is the best choice, it may be preferred.

It would be nice to collect "tricks" to get most reliable benchmark results. Maybe in perf.py README page? Or a wiki page? Whatever? :-)

----------

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

From report at bugs.python.org  Thu Feb  4 04:35:46 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 09:35:46 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454578546.27.0.41712171172.issue21955@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I agree with Marc-Andre, people doing FP-heavy math in Python use Numpy (possibly with Numba, Cython or any other additional library). Micro-optimizing floating-point operations in the eval loop makes little sense IMO.

The point of optimizing integers is that they are used for many purposes, not only "math" (e.g. indexing).

----------

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

From report at bugs.python.org  Thu Feb  4 04:35:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 09:35:48 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454578548.42.0.124725962504.issue26275@psf.upfronthosting.co.za>


STINNER Victor added the comment:

For an older project (Fusil the fuzzer), I wrote a short function to sleep until the system load is lower than a threshold. I had to write such function to reduce the noise when the system is heavily loaded. I wrote that to be able to run a very long task (it takes at least 1 hour, but may run for multiple days!) on my desktop and continue to use my desktop for various other tasks.

On Linux, we can use the "cpu xxx xxx xxx ..." line of /proc/stat to get the system load.

My code to read the system load:
https://bitbucket.org/haypo/fusil/src/32ddc281219cd90c1ad12a3ee4ce212bea1c3e0f/fusil/linux/cpu_load.py?at=default&fileviewer=file-view-default#cpu_load.py-51

My code to wait until the system load is lower than a threshold:
https://bitbucket.org/haypo/fusil/src/32ddc281219cd90c1ad12a3ee4ce212bea1c3e0f/fusil/system_calm.py?at=default&fileviewer=file-view-default#system_calm.py-5

--

I also write a script to do the opposite :-) A script to stress the system to have a system load higher or equal than a minimum load:

https://bitbucket.org/haypo/misc/src/3fd3993413b128b37e945690865ea2c5ef48c446/bin/system_load.py?at=default&fileviewer=file-view-default

This script helped to me reproduce sporadic failures like timeouts which only occur when the system is highly loaded.

----------

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

From report at bugs.python.org  Thu Feb  4 04:37:13 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 09:37:13 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454578633.63.0.108556723525.issue26275@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Core 1 fluctuates even more (My machine only has 2 cores):

$ taskset -c 1 ./python telco.py full

Control totals:
Actual   ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17']
Elapsed time: 6.783009
Control totals:
Actual   ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17']
Elapsed time: 7.335563
$ taskset -c 1 ./python telco.py full


I have some of the same concerns as Serhiy. There's a lot of statistics going on in the benchmark suite -- is it really possible to separate that cleanly from the actual runtime of the benchmarks?

----------

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

From report at bugs.python.org  Thu Feb  4 04:37:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 09:37:42 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454578662.52.0.637614714827.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I agree with Marc-Andre, people doing FP-heavy math in Python use Numpy (possibly with Numba, Cython or any other additional library). Micro-optimizing floating-point operations in the eval loop makes little sense IMO.

Oh wait, I maybe misunderstood Marc-Andre comment. If the question is only on float: I'm ok to drop the fast-path for float. By the way, I would prefer to see PyLong_CheckExact() in the main loop, and only call fast_mul() if both operands are Python int.

----------

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

From report at bugs.python.org  Thu Feb  4 04:41:16 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 04 Feb 2016 09:41:16 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454578876.51.0.481009573237.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Is there anything more I should be doing with either of these patches? I think I've incorporated all review comments I've seen. Thanks!

----------

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

From report at bugs.python.org  Thu Feb  4 05:30:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Feb 2016 10:30:04 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454581804.1.0.394728929768.issue21955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

fastint2.patch adds small regression for string multiplication:

$ ./python -m timeit -s "x = 'x'" -- "x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; "
Unpatched:  1.46 usec per loop
Patched:    1.54 usec per loop

Here is an alternative patch. It just uses existing specialized functions for integers: long_add, long_sub and long_mul. It doesn't add regression for above example with string multiplication, and it looks faster than fastint2.patch for integer multiplication.

$ ./python -m timeit -s "x = 12345" -- "x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; "
Unpatched:          0.887 usec per loop
fastint2.patch:     0.841 usec per loop
fastint_alt.patch:  0.804 usec per loop

----------
Added file: http://bugs.python.org/file41801/fastint_alt.patch

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

From report at bugs.python.org  Thu Feb  4 06:08:00 2016
From: report at bugs.python.org (Florin Papa)
Date: Thu, 04 Feb 2016 11:08:00 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454584080.54.0.844985385662.issue26275@psf.upfronthosting.co.za>


Florin Papa added the comment:

I ran perf to use calibration and there is no difference in stability
compared to the unpatched version.

With patch:

python perf.py -b json_dump_v2 -v --csv=out1.csv --affinity=2 ../cpython/python ../cpython/python
INFO:root:Automatically selected timer: perf_counter
[1/1] json_dump_v2...
Calibrating
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 1 -l 1 --timer perf_counter`
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 1 -l 2 --timer perf_counter`
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 1 -l 4 --timer perf_counter`
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 1 -l 8 --timer perf_counter`
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 1 -l 16 --timer perf_counter`
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 1 -l 32 --timer perf_counter`
Calibrating => num_runs=10, num_loops=32 (0.50 sec < 0.87 sec)
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 10 -l 32 --timer perf_counter`
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 10 -l 32 --timer perf_counter`

Report on Linux centos 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64
Total CPU cores: 18

### json_dump_v2 ###
Min: 0.877497 -> 0.886482: 1.01x slower   <----------
Avg: 0.878150 -> 0.888351: 1.01x slower
Not significant
Stddev: 0.00054 -> 0.00106: 1.9481x larger


Without patch:

python perf.py -b json_dump_v2 -v --csv=out1.csv --affinity=2 ../cpython/python ../cpython/python
INFO:root:Automatically selected timer: perf_counter
[1/1] json_dump_v2...
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 50 --timer perf_counter`
INFO:root:Running `taskset --cpu-list 2 ../cpython/python performance/bm_json_v2.py -n 50 --timer perf_counter`

Report on Linux centos 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64
Total CPU cores: 18

### json_dump_v2 ###
Min: 2.755514 -> 2.764131: 1.00x slower     <---------- (almost) same as above
Avg: 2.766546 -> 2.775587: 1.00x slower
Not significant
Stddev: 0.00538 -> 0.00382: 1.4069x smaller

----------

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

From report at bugs.python.org  Thu Feb  4 06:27:34 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Thu, 04 Feb 2016 11:27:34 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454585254.71.0.483209963554.issue26252@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

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

From report at bugs.python.org  Thu Feb  4 06:35:26 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Thu, 04 Feb 2016 11:35:26 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454585726.08.0.166413504982.issue26110@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

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

From report at bugs.python.org  Thu Feb  4 06:36:43 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 04 Feb 2016 11:36:43 +0000
Subject: [issue26269] zipfile should call lstat instead of stat if available
In-Reply-To: <1454449498.64.0.544045383692.issue26269@psf.upfronthosting.co.za>
Message-ID: <1454585803.8.0.411748762111.issue26269@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Thu Feb  4 06:37:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 11:37:12 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454585832.54.0.21571365928.issue26275@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Stefan: "In my experience it is very hard to get stable benchmark results with Python.  Even long running benchmarks on an empty machine vary: (...)"

tl; dr We *can* tune the Linux kernel to avoid most of the system noise when running kernels.


I modified Stefan's telco.py to remove all I/O from the hot code: the benchmark is now really CPU-bound. I also modified telco.py to run the benchmark 5 times. One run takes around 2.6 seconds.

I also added the following lines to check the CPU affinity and the number of context switches:

    os.system("grep -E -i 'cpu|ctx' /proc/%s/status" % os.getpid())

Well, see attached telco_haypo.py for the full script.

I used my system_load.py script to get a system load >= 5.0. Without tasksel, the benchmark result changes completly: at least 5 seconds. Well, it's not really surprising, it's known that benchmarks depend on the system load.


*BUT* I have a great kernel called Linux which has cool features called "CPU isolation" and "no HZ" (tickless kernel). On my Fedoera 23, the kernel is compiled with CONFIG_NO_HZ=y and CONFIG_NO_HZ_FULL=y.

haypo at smithers$ lscpu --extended
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
0   0    0      0    0:0:0:0       oui    5900,0000 1600,0000
1   0    0      1    1:1:1:0       oui    5900,0000 1600,0000
2   0    0      2    2:2:2:0       oui    5900,0000 1600,0000
3   0    0      3    3:3:3:0       oui    5900,0000 1600,0000
4   0    0      0    0:0:0:0       oui    5900,0000 1600,0000
5   0    0      1    1:1:1:0       oui    5900,0000 1600,0000
6   0    0      2    2:2:2:0       oui    5900,0000 1600,0000
7   0    0      3    3:3:3:0       oui    5900,0000 1600,0000

My CPU is on a single socket, has 4 physical cores, but Linux gets 8 cores because of hyper threading.


I modified the Linux command line during the boot in GRUB to add: isolcpus=2,3,6,7 nohz_full=2,3,6,7. Then I forced the CPU frequency to performance to avoid hiccups:

# for id in 2 3 6 7; do echo performance > cpu$id/cpufreq/scaling_governor; done 

Check the config with:

$ cat /sys/devices/system/cpu/isolated
2-3,6-7
$ cat /sys/devices/system/cpu/nohz_full
2-3,6-7
$ cat /sys/devices/system/cpu/cpu[2367]/cpufreq/scaling_governor
performance
performance
performance
performance


Ok now with this kernel config but still without tasksel on an idle system:
-----------------------
Elapsed time: 2.660088424000037
Elapsed time: 2.5927538629999844
Elapsed time: 2.6135682369999813
Elapsed time: 2.5819260570000324
Elapsed time: 2.5991294099999322

Cpus_allowed:	33
Cpus_allowed_list:	0-1,4-5
voluntary_ctxt_switches:	1
nonvoluntary_ctxt_switches:	21
-----------------------

With system load >= 5.0:
-----------------------
Elapsed time: 5.3484489170000415
Elapsed time: 5.336797472999933
Elapsed time: 5.187413687999992
Elapsed time: 5.24122020599998
Elapsed time: 5.10201246400004

Cpus_allowed_list:	0-1,4-5
voluntary_ctxt_switches:	1
nonvoluntary_ctxt_switches:	1597
-----------------------

And *NOW* using my isolated CPU physical cores #2 and #3 (Linux CPUs 2, 3, 6 and 7), still on the heavily loaded system:
-----------------------
$ taskset -c 2,3,6,7 python3 telco_haypo.py full 

Elapsed time: 2.579487486000062
Elapsed time: 2.5827961039999536
Elapsed time: 2.5811954810001225
Elapsed time: 2.5782033600000887
Elapsed time: 2.572370636999949

Cpus_allowed:	cc
Cpus_allowed_list:	2-3,6-7
voluntary_ctxt_switches:	2
nonvoluntary_ctxt_switches:	16
-----------------------

Numbers look *more* stable than the numbers of the first test without taskset on an idle system! You can see that number of context switches is very low (total: 18).

Example of a second run:
-----------------------
haypo at smithers$ taskset -c 2,3,6,7 python3 telco_haypo.py full 

Elapsed time: 2.538398498999868
Elapsed time: 2.544711968999991
Elapsed time: 2.5323677339999904
Elapsed time: 2.536252647000083
Elapsed time: 2.525748182999905

Cpus_allowed:	cc
Cpus_allowed_list:	2-3,6-7
voluntary_ctxt_switches:	2
nonvoluntary_ctxt_switches:	15
-----------------------

Third run:
-----------------------
haypo at smithers$ taskset -c 2,3,6,7 python3 telco_haypo.py full 

Elapsed time: 2.5819172930000605
Elapsed time: 2.5783024259999365
Elapsed time: 2.578493587999901
Elapsed time: 2.5774198510000588
Elapsed time: 2.5772148999999445

Cpus_allowed:	cc
Cpus_allowed_list:	2-3,6-7
voluntary_ctxt_switches:	2
nonvoluntary_ctxt_switches:	15
-----------------------

Well, it's no perfect, but it looks much stable than timings without specific kernel config nor CPU pinning.

Statistics on the 15 timings of the 3 runs with tunning on a heavily loaded system:

>>> times
[2.579487486000062, 2.5827961039999536, 2.5811954810001225, 2.5782033600000887, 2.572370636999949, 2.538398498999868, 2.544711968999991, 2.5323677339999904, 2.536252647000083, 2.525748182999905, 2.5819172930000605, 2.5783024259999365, 2.578493587999901, 2.5774198510000588, 2.5772148999999445]
>>> statistics.mean(times)
2.564325343866661
>>> statistics.pvariance(times)
0.0004340411190965491
>>> statistics.stdev(times)
0.021564880156747315


Compare if to the timings without tunning on an idle system:

>>> times
[2.660088424000037, 2.5927538629999844, 2.6135682369999813, 2.5819260570000324, 2.5991294099999322]
>>> statistics.mean(times)
2.6094931981999934
>>> statistics.pvariance(times)
0.0007448087075422725
>>> statistics.stdev(times)
0.030512470965620608

We get (no tuning, idle system => tuning, busy system):

* Population variance: 0.00074 => 0.00043
* Standard deviation: 0.031 => 0.022

It looks *much* better, no? Even I only used *5* timings on the benchmark without tuning, whereas I used 15 timings on the benchmark with tuning. I expect larger variance and deviation with more times.

--

Just for fun, I ran the benchmark 3 times (so to get 3x5 timings) on an idle system with tuning:

>>> times
[2.542378394000025, 2.5541740109999864, 2.5456488329998592, 2.54730951800002, 2.5495472409998, 2.56374302800009, 2.5737907220000125, 2.581463170999996, 2.578222832999927, 2.574441839999963, 2.569389365999996, 2.5792129209999075, 2.5689420860001064, 2.5681367900001533, 2.5563378829999692]
>>> import statistics
>>> statistics.mean(times)
2.563515909133321
>>> statistics.pvariance(times)
0.00016384530912002678
>>> statistics.stdev(times)
0.013249473404092065

As expected, it's even better (no tune, idle system => tuning, busy system => tuning, idle system):

* Population variance: 0.00074 => 0.00043 => 0.00016
* Standard deviation: 0.031 => 0.022 => 0.013

----------
Added file: http://bugs.python.org/file41802/telco_haypo.py

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

From report at bugs.python.org  Thu Feb  4 07:03:59 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 12:03:59 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454585832.54.0.21571365928.issue26275@psf.upfronthosting.co.za>
Message-ID: <20160204120348.GA5122@bytereef.org>


Stefan Krah added the comment:

> STINNER Victor added the comment:
> I modified Stefan's telco.py to remove all I/O from the hot code: the benchmark is now really CPU-bound. I also modified telco.py to run the benchmark 5 times. One run takes around 2.6 seconds.
> 

Nice. telco.py is an ad-hoc script from the original decimal.py sandbox,
I missed that it called "infil.read(8)". :)

> And *NOW* using my isolated CPU physical cores #2 and #3 (Linux CPUs 2, 3, 6 and 7), still on the heavily loaded system:
> -----------------------
> $ taskset -c 2,3,6,7 python3 telco_haypo.py full 
> 
> Elapsed time: 2.579487486000062
> Elapsed time: 2.5827961039999536
> Elapsed time: 2.5811954810001225
> Elapsed time: 2.5782033600000887
> Elapsed time: 2.572370636999949

Great.  I'll try that out in the weekend.

----------

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

From report at bugs.python.org  Thu Feb  4 07:16:08 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 12:16:08 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454588168.2.0.361263018645.issue26275@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Victor, this is a very interesting write-up, thank you.

----------

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

From report at bugs.python.org  Thu Feb  4 07:48:54 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 04 Feb 2016 12:48:54 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1454590134.6.0.969117544273.issue22107@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

This issue was closed, but I believe the original bug reported was not fixed: trying to create a temporary file in a directory where you don't have write permissions hangs for a long time before failing with a misleading FileExistsError, rather than failing immediately with PermissionError.

I've just run into this on Python 3.5.1 while trying to use tempfile to check if a directory is writable - which I'm doing precisely because os.access() isn't useful on Windows!

I find it hard to believe that there is no way to distinguish a failure because the name is already used for a subdirectory from a failure because we don't have permission to create a file.

----------
nosy: +takluyver

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

From report at bugs.python.org  Thu Feb  4 07:50:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 12:50:15 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454590215.47.0.488862786833.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I prefer fastint_alt.patch design, it's simpler. I added a comment on the review.

My numbers, best of 5 timeit runs:

$ ./python -m timeit -s "x = 12345" -- "x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; x*2; "

* original: 299 ns
* fastint2.patch: 282 ns (-17 ns, -6%)
* fastint_alt.patch: 267 ns (-32 ns, -11%)

----------

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

From report at bugs.python.org  Thu Feb  4 08:33:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 13:33:05 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454584080.54.0.844985385662.issue26275@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY1VbJ9kDJhSeaes8FjHXca5iUUaCpkm6LUrCqaQPksaQ@mail.gmail.com>


STINNER Victor added the comment:

Florin Papa added the comment:
> I ran perf to use calibration and there is no difference in stability
> compared to the unpatched version.

Sorry, what are you calling "stability"? For me, stability means that
you run the same benchmark 3, 5 or 10 times, and the results must be
as close as possible: see variance and standard deviation of my
previous message.

I'm not talking of variance/deviation of the N runs of bm_xxx.py
scripts, but variance/deviation of the mean value displayed by
perf.py.

perf_calibration.patch is a proof-of-concept. I changed the number of
runs from 50 to 10 to test my patch more easily. You should modify the
patch to keep 50 runs if you want to compare the stability.

By the way, --fast/--rigorous options should not only change the
minimum duration of a single run to calibrate the number of loops, but
they should also change the "maximum" duration of perf.py by using
different number of runs.

----------

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

From report at bugs.python.org  Thu Feb  4 08:45:45 2016
From: report at bugs.python.org (Christoph Sarnowski)
Date: Thu, 04 Feb 2016 13:45:45 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1454593545.31.0.289997575805.issue20160@psf.upfronthosting.co.za>


Changes by Christoph Sarnowski <pixelbrei at gmail.com>:


----------
nosy: +Christoph Sarnowski

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

From report at bugs.python.org  Thu Feb  4 08:54:55 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 13:54:55 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454594095.73.0.393687709596.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I agree with Marc-Andre, people doing FP-heavy math in Python use Numpy (possibly with Numba, Cython or any other additional library). Micro-optimizing floating-point operations in the eval loop makes little sense IMO.

I disagree.

30% faster floats (sic!) is a serious improvement, that shouldn't just be discarded.  Many applications have floating point calculations one way or another, but don't use numpy because it's an overkill.

Python 2 is much faster than Python 3 on any kind of numeric calculations.  This point is being frequently brought up in every python2 vs 3 debate.  I think it's unacceptable.


> * the ceval loop may no longer fit in to the CPU cache on
   systems with small cache sizes, since the compiler will likely
   inline all the fast_*() functions (I guess it would be possible
   to simply eliminate all fast paths using a compile time
   flag)

That's a speculation.  It may still fit.  Or it had never really fitted, it's already huge.  I tested the patch on a 8 year old desktop CPU, no performance degradation on our benchmarks.

### raytrace ###
Avg: 1.858527 -> 1.652754: 1.12x faster

### nbody ###
Avg: 0.310281 -> 0.285179: 1.09x faster

### float ###
Avg: 0.392169 -> 0.358989: 1.09x faster

### chaos ###
Avg: 0.355519 -> 0.326400: 1.09x faster

### spectral_norm ###
Avg: 0.377147 -> 0.303928: 1.24x faster

### telco ###
Avg: 0.012845 -> 0.013006: 1.01x slower

The last benchmark (telco) is especially interesting.  It uses decimals for calculation, that means that it uses overloaded numeric operators.  Still no significant performance degradation.

> * maintenance will get more difficult

Fast path for floats is easy to understand for every core dev that works with ceval, there is no rocket science there (if you want rocket science that is hard to maintain look at generators/yield from).  If you don't like inlining floating point calculations, we can make float_add, float_sub, float_div, and float_mul exported and use them in ceval.

Why not combine my patch and Serhiy's?  First we check if left & right are both longs.  Then we check if they are unicode (for +).  And then we have a fastpath for floats.

----------

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

From report at bugs.python.org  Thu Feb  4 09:01:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 14:01:39 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454594499.1.0.150189545222.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Why not combine my patch and Serhiy's?  First we check if left & right are both longs.  Then we check if they are unicode (for +).  And then we have a fastpath for floats.

See my comment on Serhiy's patch. Maybe we can start by check that the type of both operands are the same, and then use PyLong_CheckExact and PyUnicode_CheckExact.

Using such design, we may add a _PyFloat_Add(). But the next question is then the overhead on the "slow" path, which requires a benchmark too! For example, use a subtype of int.

----------

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

From report at bugs.python.org  Thu Feb  4 09:06:51 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 14:06:51 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454594095.73.0.393687709596.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B35AF7.7030500@free.fr>


Antoine Pitrou added the comment:

Le 04/02/2016 14:54, Yury Selivanov a ?crit :
> 
> 30% faster floats (sic!) is a serious improvement, that shouldn't
> just be discarded. Many applications have floating point calculations one way
> or another, but don't use numpy because it's an overkill.

Can you give any example of such an application and how they would
actually benefit from "faster floats"? I'm curious why anyone who wants
fast FP calculations would use pure Python with CPython...

Discarding Numpy because it's "overkill" sounds misguided to me.
That's like discarding asyncio because it's "less overkill" to write
your own select() loop. It's often far more productive to use the
established, robust, optimized library rather than tweak your own
low-level code.

(and Numpy is easier to learn than asyncio ;-))

I'm not violently opposing the patch, but I think maintenance effort
devoted to such micro-optimizations is a bit wasted. And once you add
such a micro-optimization, trying to remove it often faces a barrage of
FUD about making Python slower, even if the micro-optimization is
practically worthless.

> Python 2 is much faster than Python 3 on any kind of numeric
> calculations.

Actually, it shouldn't really be faster on FP calculations, since the
float object hasn't changed (as opposed to int/long). So I'm skeptical
of FP-heavy code that would have been made slower by Python 3 (unless
there's also integer handling in that, e.g. indexing).

----------

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

From report at bugs.python.org  Thu Feb  4 09:18:41 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 14:18:41 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454595521.29.0.608990518314.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

>But the next question is then the overhead on the "slow" path, which requires a benchmark too! For example, use a subtype of int.

telco is such a benchmark (although it's very unstable).  It uses decimals extensively.  I've tested it many times on three different CPUs, and it doesn't seem to become any slower.


> Discarding Numpy because it's "overkill" sounds misguided to me.
That's like discarding asyncio because it's "less overkill" to write
your own select() loop. It's often far more productive to use the
established, robust, optimized library rather than tweak your own
low-level code.

Don't get me wrong, numpy is simply amazing!  But if you have a 100,000 lines application that happens to have a a few FP-related calculations here and there, you won't use numpy (unless you had experience with it before).

My opinion on this: numeric operations in Python (and any general purpose language) should be as fast as we can make them.


> Python 2 is much faster than Python 3 on any kind of numeric
> calculations.

> Actually, it shouldn't really be faster on FP calculations, since the
float object hasn't changed (as opposed to int/long). So I'm skeptical
of FP-heavy code that would have been made slower by Python 3 (unless
there's also integer handling in that, e.g. indexing).

But it is faster.  That's visible on many benchmarks.  Even simple timeit oneliners can show that.  Probably it's because that such benchmarks usually combine floats and ints, i.e. "2 * smth" instead of "2.0 * smth".

----------

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

From report at bugs.python.org  Thu Feb  4 09:22:21 2016
From: report at bugs.python.org (Florin Papa)
Date: Thu, 04 Feb 2016 14:22:21 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454595741.89.0.465038458142.issue26275@psf.upfronthosting.co.za>


Florin Papa added the comment:

I was also talking about the variance/deviation of the mean value
displayed by perf.py, sorry if I was unclear. The perf.py output in my
previous message showed little difference between the patched and
non-patched version. I will also try increasing the number of
runs to see if there is any change.

The CPU isolation feature is a great finding, thank you.

----------

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

From report at bugs.python.org  Thu Feb  4 09:24:48 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 14:24:48 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454595521.29.0.608990518314.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B35F2D.6050504@free.fr>


Antoine Pitrou added the comment:

Le 04/02/2016 15:18, Yury Selivanov a ?crit :
> 
> But it is faster. That's visible on many benchmarks. Even simple
timeit oneliners can show that. Probably it's because that such
benchmarks usually combine floats and ints, i.e. "2 * smth" instead of
"2.0 * smth".

So it's not about FP-related calculations anymore. It's about ints
having become slower ;-)

----------

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

From report at bugs.python.org  Thu Feb  4 09:27:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 14:27:21 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <56B35F2D.6050504@free.fr>
Message-ID: <C0A9FF8E-9047-4903-8F10-8DC6F27F5EF0@gmail.com>


Yury Selivanov added the comment:

>> But it is faster. That's visible on many benchmarks. Even simple
> timeit oneliners can show that. Probably it's because that such
> benchmarks usually combine floats and ints, i.e. "2 * smth" instead of
> "2.0 * smth".
> 
> So it's not about FP-related calculations anymore. It's about ints
> having become slower ;-)

I should have written 2 * smth_float vs 2.0 * smth_float

----------
nosy: +Yury.Selivanov

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

From report at bugs.python.org  Thu Feb  4 09:28:01 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 14:28:01 +0000
Subject: [issue26284] FIx telco benchmark
Message-ID: <1454596081.41.0.621997504219.issue26284@psf.upfronthosting.co.za>


New submission from Stefan Krah:

The telco benchmark is unstable. It needs some of Victor's changes from #26275 and probably a larger data set:

http://speleotrove.com/decimal/expon180-1e6b.zip is too big for
_pydecimal, but the one that is used is probably too small for
_decimal.

----------
components: Benchmarks
messages: 259569
nosy: brett.cannon, haypo, pitrou, skrah, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: FIx telco benchmark
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Feb  4 10:05:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 15:05:24 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454598324.37.0.252389063605.issue26275@psf.upfronthosting.co.za>


STINNER Victor added the comment:

tl; dr I'm disappointed. According to the statistics module, running the bm_regex_v8.py benchmark more times with more iterations make the benchmark more unstable... I expected the opposite...


Patch version 2:

* patch also performance/bm_pickle.py
* change min_time from 100 ms to 500 ms with --fast
* compute the number of runs using a maximum time, maximum time change with --fast and --rigorous

+    if options.rigorous:
+        min_time = 1.0
+        max_time = 100.0  # 100 runs
+    elif options.fast:
+        min_time = 0.5
+        max_time = 25.0   # 50 runs
+    else:
+        min_time = 0.5
+        max_time = 50.0   # 100 runs


To measure the stability of perf.py, I pinned perf.py to CPU cores which are isolated of the system using Linux "isolcpus" kernel parameter. I also forced the CPU frequency governor to "performance" and enabled "no HZ full" on these cores.

I ran perf.py 5 times on regex_v8.


Calibration (original => patched):

* --fast: 1 iteration x 5 runs => 16 iterations x 50 runs
* (no option): 1 iteration x 50 runs => 16 iterations x 100 runs


Approximated duration of the benchmark (original => patched):

* --fast: 7 sec => 7 min 34 sec
* (no option): 30 sec => 14 min 35 sec

(I made a mistake, so I was unable to get the exact duration.)

Hum, maybe timings are not well chosen because the benchmark is really slow (minutes vs seconds) :-/


Standard deviation, --fast:

* (python2) 0.00071 (1.2%, mean=0.05961) => 0.01059 (1.1%, mean=0.96723)
* (python3) 0.00068 (1.5%, mean=0.04494) => 0.05925 (8.0%, mean=0.74248)
* (faster) 0.02986 (2.2%, mean=1.32750) => 0.09083 (6.9%, mean=1.31000)

Standard deviation, (no option):

* (python2) 0.00072 (1.2%, mean=0.05957) => 0.00874 (0.9%, mean=0.97028)
* (python3) 0.00053 (1.2%, mean=0.04477) => 0.00966 (1.3%, mean=0.72680)
* (faster) 0.02739 (2.1%, mean=1.33000) => 0.02608 (2.0%, mean=1.33600)

Variance, --fast:

* (python2) 0.00000 (0.001%, mean=0.05961) => 0.00009 (0.009%, mean=0.96723)
* (python3) 0.00000 (0.001%, mean=0.04494) => 0.00281 (0.378%, mean=0.74248)
* (faster) 0.00067 (0.050%, mean=1.32750) => 0.00660 (0.504%, mean=1.31000)

Variance, (no option):

* (python2) 0.00000 (0.001%, mean=0.05957) => 0.00006 (0.006%, mean=0.97028)
* (python3) 0.00000 (0.001%, mean=0.04477) => 0.00007 (0.010%, mean=0.72680)
* (faster) 0.00060 (0.045%, mean=1.33000) => 0.00054 (0.041%, mean=1.33600)

Legend:

* (python2) are timings of python2 ran by perf.py (of the "Min" line)
* (python3) are timings of python3 ran by perf.py (of the "Min" line)
* (faster) are the "1.34x" numbers of "faster" or "slower" of the "Min" line
* percentages are: value * 100 / mean

It's not easy to compare these values since the number of iterations is very different (1 => 16) and so timings are very different (ex: 0.059 sec => 0.950 sec). I guess that it's ok to compare percentages.


I used the stability.py script, attached to this issue, to compute deviation and variance from the "Min" line of the 5 runs. The script takes the output of perf.py as input.

I'm not sure that 5 runs are enough to compute statistics.

--

Raw data.

Original perf.py.

$ grep ^Min original.fast 
Min: 0.059236 -> 0.045948: 1.29x faster
Min: 0.059005 -> 0.044654: 1.32x faster
Min: 0.059601 -> 0.044547: 1.34x faster
Min: 0.060605 -> 0.044600: 1.36x faster

$ grep ^Min original
Min: 0.060479 -> 0.044762: 1.35x faster
Min: 0.059002 -> 0.045689: 1.29x faster
Min: 0.058991 -> 0.044587: 1.32x faster
Min: 0.060231 -> 0.044364: 1.36x faster
Min: 0.059165 -> 0.044464: 1.33x faster

Patched perf.py.

$ grep ^Min patched.fast 
Min: 0.950717 -> 0.711018: 1.34x faster
Min: 0.968413 -> 0.730810: 1.33x faster
Min: 0.976092 -> 0.847388: 1.15x faster
Min: 0.964355 -> 0.711083: 1.36x faster
Min: 0.976573 -> 0.712081: 1.37x faster

$ grep ^Min patched
Min: 0.968810 -> 0.729109: 1.33x faster
Min: 0.973615 -> 0.731308: 1.33x faster
Min: 0.974215 -> 0.734259: 1.33x faster
Min: 0.978781 -> 0.709915: 1.38x faster
Min: 0.955977 -> 0.729387: 1.31x faster

$ grep ^Calibration patched.fast 
Calibration: num_runs=50, num_loops=16 (0.73 sec per run > min_time 0.50 sec, estimated total: 36.4 sec)
Calibration: num_runs=50, num_loops=16 (0.75 sec per run > min_time 0.50 sec, estimated total: 37.3 sec)
Calibration: num_runs=50, num_loops=16 (0.75 sec per run > min_time 0.50 sec, estimated total: 37.4 sec)
Calibration: num_runs=50, num_loops=16 (0.73 sec per run > min_time 0.50 sec, estimated total: 36.6 sec)
Calibration: num_runs=50, num_loops=16 (0.73 sec per run > min_time 0.50 sec, estimated total: 36.7 sec)

$ grep ^Calibration patched
Calibration: num_runs=100, num_loops=16 (0.73 sec per run > min_time 0.50 sec, estimated total: 73.0 sec)
Calibration: num_runs=100, num_loops=16 (0.75 sec per run > min_time 0.50 sec, estimated total: 75.3 sec)
Calibration: num_runs=100, num_loops=16 (0.73 sec per run > min_time 0.50 sec, estimated total: 73.2 sec)
Calibration: num_runs=100, num_loops=16 (0.74 sec per run > min_time 0.50 sec, estimated total: 73.7 sec)
Calibration: num_runs=100, num_loops=16 (0.73 sec per run > min_time 0.50 sec, estimated total: 72.9 sec)

----------
Added file: http://bugs.python.org/file41803/stability.py

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

From report at bugs.python.org  Thu Feb  4 10:05:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 15:05:37 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454598337.87.0.167844846099.issue26275@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file41804/perf_calibration-2.patch

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

From report at bugs.python.org  Thu Feb  4 10:40:09 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 15:40:09 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454600409.52.0.487543997192.issue21955@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It's instructive to run ./python Modules/_decimal/tests/bench.py (Hit Ctrl-C after the first cdecimal result, 5 repetitions or so).

fastint2.patch speeds up floats enormously and slows down decimal by 6%.
fastint_alt.patch slows down float *and* decimal (5% or so).

Overall the status quo isn't that bad, but I concede that float benchmarks like that are useful for PR.

----------
nosy: +skrah

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

From report at bugs.python.org  Thu Feb  4 10:41:04 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 04 Feb 2016 15:41:04 +0000
Subject: [issue26269] zipfile should call lstat instead of stat if available
In-Reply-To: <1454449498.64.0.544045383692.issue26269@psf.upfronthosting.co.za>
Message-ID: <1454600464.47.0.00119807069467.issue26269@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components: +Extension Modules
nosy: +alanmcintyre, serhiy.storchaka, twouters
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Feb  4 10:42:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 04 Feb 2016 15:42:07 +0000
Subject: [issue26271] freeze.py makefile uses the wrong flags variables
In-Reply-To: <1454454135.77.0.499921177416.issue26271@psf.upfronthosting.co.za>
Message-ID: <1454600527.21.0.859920058996.issue26271@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +twouters

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

From report at bugs.python.org  Thu Feb  4 10:43:00 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 04 Feb 2016 15:43:00 +0000
Subject: [issue26283] zipfile can not handle the path build by os.path.join()
In-Reply-To: <1454552368.89.0.734714115407.issue26283@psf.upfronthosting.co.za>
Message-ID: <1454600580.23.0.282414788675.issue26283@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +alanmcintyre, serhiy.storchaka, twouters
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Thu Feb  4 10:56:28 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 04 Feb 2016 15:56:28 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
Message-ID: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>


New submission from Alecsandru Patrascu:

Hi all,

This is Alecsandru from the Dynamic Scripting Languages Optimization Team at Intel Corporation. I would like to submit a patch that enables garbage collection of unused input sections from the CPython2 and CPython3 binaries, by using the "--gc-sections" linker flag, which decides which input sections are used by examining symbols and relocations. In order for this to work, GCC must place each function or data item into its own section in the output file, thus dedicated flags are used. With this technique, an average of 1% is gained in both interpreters, with a few small regressions.

Steps:
======
1. Get the CPython source codes
    hg clone https://hg.python.org/cpython cpython
    cd cpython
    hg update 2.7 (for CPython2)

2. Build the binary
    a) Default:
        ./configure
        make
    
    b) Unused input sections patch
        Copy the attached patch files
        hg import --no-commit cpython2-deadcode-v01.patch.patch (for CPython3)
        hg import --no-commit cpython2-deadcode-v01.patch (for CPython2)
        ./configure
        make

        
Hardware and OS Configuration
=============================
Hardware:           Intel XEON (Haswell-EP) 18 Cores

BIOS settings:      Intel Turbo Boost Technology: false
                    Hyper-Threading: false                  

OS:                 Ubuntu 14.04.3 LTS Server

OS configuration:   Address Space Layout Randomization (ASLR) disabled to reduce run
                    to run variation by echo 0 > /proc/sys/kernel/randomize_va_space
                    CPU frequency set fixed at 2.6GHz

GCC version:        GCC version 4.9.2

Benchmark:          Grand Unified Python Benchmark from 
                    https://hg.python.org/benchmarks/

                    
Measurements and Results
========================
CPython2 and CPython3 sample results, measured using GUPB on a Haswell platform, can be viewed in Table 1 and 2. On the first column (Benchmark) you can see the benchmark name and on the second (%S) the speedup compared with the default version; a higher value is better.

Table 1. CPython3 results:
Benchmark           %S
----------------------
telco               11
etree_parse         7
call_simple         6
etree_iterparse     5
regex_v8            4
meteor_contest      3
etree_process       3
call_method_unknown 3
json_dump_v2        3
formatted_logging   2
hexiom2             2
chaos               2
richards            2
django_v3           2
nbody               2
etree_generate      2
pickle_list         1
go                  1
nqueens             1
call_method         1
mako_v2             1
raytrace            1
chameleon_v2        1
silent_logging      0
fastunpickle        0
2to3                0
float               0
regex_effbot        0
pidigits            0
json_load           0
simple_logging      0
normal_startup      0
startup_nosite      0
fastpickle          0
tornado_http        0
regex_compile       0
fannkuch            0
spectral_norm       0
pickle_dict         0
unpickle_list       0
call_method_slots   0
pathlib             -2
unpack_sequence     -2

Table 2. CPython2 results:
Benchmark           %S
----------------------
simple_logging      4
formatted_logging   3
slowpickle          2
silent_logging      2
pickle_dict         1
chameleon_v2        1
hg_startup          1
pickle_list         1
call_method_unknown 1
pidigits            1
regex_effbot        1
regex_v8            1
html5lib            0
normal_startup      0
regex_compile       0
etree_parse         0
spambayes           0
html5lib_warmup     0
unpack_sequence     0
richards            0
rietveld            0
startup_nosite      0
raytrace            0
etree_iterparse     0
json_dump_v2        0
fastpickle          0
slowspitfire        0
slowunpickle        0
call_simple         0
float               0
2to3                0
bzr_startup         0
json_load           0
hexiom2             0
chaos               0
unpickle_list       0
call_method_slots   0
tornado_http        0
fastunpickle        0
etree_process       0
spectral_norm       0
meteor_contest      0
pybench             0
go                  0
etree_generate      0
mako_v2             0
django_v3           0
fannkuch            0
nbody               0
nqueens             0
telco               -1
call_method         -2
pathlib             -3

Thank you,
Alecsandru

----------
components: Build
files: cpython2-deadcode-v01.patch
keywords: patch
messages: 259572
nosy: alecsandru.patrascu
priority: normal
severity: normal
status: open
title: Garbage collection of unused input sections from CPython binaries
type: performance
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41805/cpython2-deadcode-v01.patch

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

From report at bugs.python.org  Thu Feb  4 10:56:36 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 15:56:36 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454600409.52.0.487543997192.issue21955@psf.upfronthosting.co.za>
Message-ID: <5D39CE42-CF13-45C1-A922-CF083B0CC857@gmail.com>


Yury Selivanov added the comment:

> 
> Stefan Krah added the comment:
> 
> It's instructive to run ./python Modules/_decimal/tests/bench.py (Hit Ctrl-C after the first cdecimal result, 5 repetitions or so).
> 
> fastint2.patch speeds up floats enormously and slows down decimal by 6%.
> fastint_alt.patch slows down float *and* decimal (5% or so).
> 
> Overall the status quo isn't that bad, but I concede that float benchmarks like that are useful for PR.
> 

Thanks Stefan! I'll update my patch to include Serhiy's ideas. The fact that fastint_alt slows down floats *and* decimals is not acceptable.

I'm all for keeping cpython and ceval loop simple, but we should not pass on opportunities to improve some things in a significant way.

----------

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

From report at bugs.python.org  Thu Feb  4 10:56:38 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 04 Feb 2016 15:56:38 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454601398.7.0.836893673199.issue26285@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file41806/cpython3-deadcode-v01.patch

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

From report at bugs.python.org  Thu Feb  4 11:05:52 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 04 Feb 2016 16:05:52 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454601952.67.0.805995144473.issue26285@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +benjamin.peterson, brett.cannon, haypo, skrah, yselivanov

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

From report at bugs.python.org  Thu Feb  4 11:36:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Feb 2016 16:36:19 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454603779.46.0.732002937036.issue21955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is easy to extend fastint_alt.patch to support floats too. Here is new patch.

> It's instructive to run ./python Modules/_decimal/tests/bench.py (Hit Ctrl-C after the first cdecimal result, 5 repetitions or so).

Note that this benchmark is not very stable. I ran it few times and the difference betweens runs was about 20%.

----------
Added file: http://bugs.python.org/file41807/fastintfloat_alt.patch

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

From report at bugs.python.org  Thu Feb  4 11:38:45 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Thu, 04 Feb 2016 16:38:45 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454603925.83.0.785397183905.issue21328@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

I found out that if you modify Modules/_cpython/callproc.c resize function in a way that you set the obj->b_length to size, the len function returns the correct value.

To be able to provide a proper patch, I'd like to look into len's implementation, can someone tell me where to look for it?

----------
nosy: +beng94

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

From report at bugs.python.org  Thu Feb  4 11:42:00 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 16:42:00 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454604120.84.0.543988545961.issue26285@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm surprised about the speedups. Is there a logical reason for them?

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Feb  4 11:42:10 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 16:42:10 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454604130.17.0.205757522082.issue21955@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I've never seen 20% fluctuation in that benchmark between runs. The benchmark is very stable if you take the average of 10 runs.

----------

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

From report at bugs.python.org  Thu Feb  4 11:44:07 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 16:44:07 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454604247.7.0.2615883037.issue21955@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I mean, if you run the benchmark 10 times and the unpatched result is always between 11.3 and 12.0 for floats while the patched result is
between 12.3 and 12.9, for me the situation is clear.

----------

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

From report at bugs.python.org  Thu Feb  4 12:17:36 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Feb 2016 17:17:36 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <1454606256.34.0.970807806282.issue25660@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Windows issue is a blocker so I suggest reverting 64417e7a1760. We could apply the same fix in readline.c for 3.5.x but it would probably be a bit hackish.

----------

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

From report at bugs.python.org  Thu Feb  4 12:24:45 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 17:24:45 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1454606256.34.0.970807806282.issue25660@psf.upfronthosting.co.za>
Message-ID: <BF91F28B-F232-426F-84B2-FF5D07684796@gmail.com>


Yury Selivanov added the comment:

Berker, I'll fix the windows issue in a few hours. Sorry for breaking things.

----------
nosy: +Yury.Selivanov

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

From report at bugs.python.org  Thu Feb  4 12:32:26 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 04 Feb 2016 17:32:26 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454607146.56.0.580093435201.issue26285@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I thought this was the usual telco benchmark instability, but with the patch _decimal *does* seem to be faster in other areas, too.

----------

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

From report at bugs.python.org  Thu Feb  4 12:47:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Feb 2016 17:47:37 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1454608057.77.0.557218400017.issue26275@psf.upfronthosting.co.za>


Brett Cannon added the comment:

What would happen if we shifted to counting the number of executions within a set amount of time instead of how fast a single execution occurred? I believe some JavaScript benchmarks started to do this about a decade ago when they realized CPUs were getting so fast that older benchmarks were completing too quickly to be reliably measured. This also would allow one to have a very strong notion of how long a benchmark run would take based on the number of iterations and what time length bucket a benchmark was placed in (i.e., for microbenchmarks we could say a second while for longer running benchmarks we can increase that threshold). And it won't hurt benchmark comparisons since we have always done relative comparisons rather than absolute ones.

----------

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

From report at bugs.python.org  Thu Feb  4 12:49:23 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 04 Feb 2016 17:49:23 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1454608163.52.0.735157364701.issue22847@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I'm reopening this and assigning it to benjamin as the 2.7 release manager.  This change is valuable to apply to 2.7.x as well.  It is very simple and is a clear performance improvement for realistic workloads.  No API change.

When you profile Python 2.7 applications today, the _PyType_Lookup function shows up in the ~3% of all CPU cycles range.  This reduces that for a small memory tradeoff.

We're raising our cache exponent to be even larger than the 12 in this patch at work as we've got some huge applications.  Regardless, 12 is a much better default than the existing 9.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, gregory.p.smith
resolution: fixed -> 
status: closed -> open
versions: +Python 2.7

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

From report at bugs.python.org  Thu Feb  4 12:52:18 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 17:52:18 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1454608338.23.0.76543906582.issue26186@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Just stumbled on this very issue while trying to use LazyLoader.

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Feb  4 12:53:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Feb 2016 17:53:45 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1454608425.57.0.511562611775.issue26186@psf.upfronthosting.co.za>


Brett Cannon added the comment:

My current plan is to simply remove the check in 3.5 -- the docs say it's ignored so I don't think it will hurt anything -- and add the warning I proposed in 3.6. What do you think, Antoine?

----------

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

From report at bugs.python.org  Thu Feb  4 12:55:41 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 17:55:41 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1454608541.27.0.00304889342397.issue26186@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

By the way does this mean the LazyLoader won't work with ExtensionFileLoader? That would reduce its usefulness quite a bit.

----------

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

From report at bugs.python.org  Thu Feb  4 12:56:32 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 17:56:32 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1454608592.14.0.50506583022.issue26186@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't know what the impact of the error is, but it seems like at least the default loader classes should be able to work with LazyLoader...

----------

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

From report at bugs.python.org  Thu Feb  4 13:02:51 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Feb 2016 18:02:51 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1454608971.47.0.464186802227.issue26186@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You're right, it won't work with extension modules based on how ExtensionFileLoader is structured.

----------

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

From report at bugs.python.org  Thu Feb  4 13:22:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Feb 2016 18:22:18 +0000
Subject: [issue6953] readline documentation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1454610138.84.0.0814798503025.issue6953@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks good to me. I left a comment on Rietveld.

----------
nosy: +berker.peksag
versions:  -Python 3.4

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

From report at bugs.python.org  Thu Feb  4 14:08:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 04 Feb 2016 19:08:31 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <20160204190827.16570.97156@psf.io>


Roundup Robot added the comment:

New changeset 980ea968444c by Yury Selivanov in branch '3.5':
Issue #25660: Fix a unittest and rlcompleter when readline isn't available
https://hg.python.org/cpython/rev/980ea968444c

----------

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

From report at bugs.python.org  Thu Feb  4 14:09:26 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 04 Feb 2016 19:09:26 +0000
Subject: [issue25660] tabs don't work correctly in python repl
In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za>
Message-ID: <1454612966.19.0.593059240063.issue25660@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Everything should be OK now (both broken tests and using rlcompleter on Windows).  Please confirm.

----------

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

From report at bugs.python.org  Thu Feb  4 15:34:37 2016
From: report at bugs.python.org (Hans Lellelid)
Date: Thu, 04 Feb 2016 20:34:37 +0000
Subject: [issue26133] asyncio: ugly error related to signal handlers at exit
 if the loop is not closed explicitly
In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za>
Message-ID: <1454618077.44.0.766622924962.issue26133@psf.upfronthosting.co.za>


Hans Lellelid added the comment:

FWIW, I am experiencing the issue described here with Python 3.5.1.

----------
nosy: +Hans Lellelid

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

From report at bugs.python.org  Thu Feb  4 15:42:44 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 04 Feb 2016 20:42:44 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454618564.64.0.0352238694676.issue26285@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I realize now that I should have explained a bit more the background of this patch. I'll do this now, for everyone to be clear of what is the effect of those flags.

This issue was revealed after running the coverage target over various workloads, for both CPython2 and CPython3. After running, it can be observed that there are functions in the interpreter that are not called at all over the lifespan of the interpreter. Even more, these functions occupy space in the resulting binary file, and the CPU is forced to jump to longer offsets than it is required. Furthermore, for production level binaries, it is a good idea to remove these stubs, as they bring no benefit. Now, in order to do this, in the first step, every function or data item must exist in its own section (and the flags -ffunction-sections and -fdata-sections come to help in GCC). In the second step, the linker comes into play and because it has the entire picture of every piece of data or function, it is able to see if there are functions that are never called for the current build (and the flag --gc-sections come to help).

This functionality is not unique or new and are used by default in other interpreters, such as V8/Node.JS in their Release target, to achieve exactly the same goal. Another example for behind the scene usage of this functionality is the Microsoft's compiler, which does it automatically in their interprocedural optimization phase.

To compress all of the above, the main reason for this speedup is the reduction of the code path length and having the useful function close together, so that the CPU will be able to prefetch them in advance and use them instead of trowing them away because they are not used.

----------

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

From report at bugs.python.org  Thu Feb  4 16:06:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Feb 2016 21:06:56 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454620016.24.0.673745744117.issue26285@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Can we get the list of removed functions?

Some functions are not used in interpreter, but they provide API for extensions.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Feb  4 16:08:00 2016
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 04 Feb 2016 21:08:00 +0000
Subject: [issue26286] dis module: coroutine opcode documentation clarity
Message-ID: <1454620080.04.0.670513123841.issue26286@psf.upfronthosting.co.za>


New submission from Jim Jewett:

https://docs.python.org/3/library/dis.html includes a section describing the various opcodes.

Current documentation: """
Coroutine opcodes

GET_AWAITABLE
Implements TOS = get_awaitable(TOS), where get_awaitable(o) returns o if o is a coroutine object or a generator object with the CO_ITERABLE_COROUTINE flag, or resolves o.__await__.

GET_AITER
Implements TOS = get_awaitable(TOS.__aiter__()). See GET_AWAITABLE for details about get_awaitable

GET_ANEXT
Implements PUSH(get_awaitable(TOS.__anext__())). See GET_AWAITABLE for details about get_awaitable

BEFORE_ASYNC_WITH
Resolves __aenter__ and __aexit__ from the object on top of the stack. Pushes __aexit__ and result of __aenter__() to the stack.

SETUP_ASYNC_WITH
Creates a new frame object.
"""

(1)  There is a PUSH macro in ceval.c, but no PUSH bytecode.  I spent a few minutes trying to figure out what a PUSH command was, and how the GET_ANEXT differed from 
    TOS = get_awaitable(TOS.__anext__())
which would match the bytecodes right above it.

After looking at ceval.c, I think GET_ANEXT is the only such bytecode to leave the original TOS in place, but I'm not certain about that.  Please be explicit.  (Unless they are the same, in which case, please use the same wording.)
 
(2)  The coroutine bytecode instructions should have a "New in 3.5" marker, as the GET_YIELD_FROM_ITER does.  It might make sense to just place the mark under Coroutine opcodes section header and say it applies to all of them, instead of marking each individual opcode.  

(3)  The GET_AITER and GET_ANEXT descriptions do not show the final period.  Opcodes such as INPLACE_LSHIFT also end with a code quote, but still include a (not-marked-as-code) final period.

(4)  Why does SETUP_ASYNC_WITH talk about frames?  Is there actually a python frame involved, or is this another bytecode "block", similar to that used for except and finally?

----------
assignee: yselivanov
components: Documentation
messages: 259595
nosy: Jim.Jewett, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: dis module: coroutine opcode documentation clarity
versions: Python 3.5

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

From report at bugs.python.org  Thu Feb  4 16:30:45 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 04 Feb 2016 21:30:45 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454621445.73.0.332458989306.issue26285@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Sure, I attached them as files because they have a lot of lines for posting here (~90 in total).

The linker offers the possibility to show what piece of data/functions was removed, but I intentionally omitted it in order not to clutter the build trace. If you think it will be useful for the user to see it, I can add them to the patch also.

----------
Added file: http://bugs.python.org/file41808/gc-removed-cpython2.txt

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

From report at bugs.python.org  Thu Feb  4 16:30:52 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 04 Feb 2016 21:30:52 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454621452.16.0.449161023815.issue26285@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file41809/gc-removed-cpython3.txt

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

From report at bugs.python.org  Thu Feb  4 16:35:27 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 21:35:27 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454618564.64.0.0352238694676.issue26285@psf.upfronthosting.co.za>
Message-ID: <56B3C41D.9090701@free.fr>


Antoine Pitrou added the comment:

Le 04/02/2016 21:42, Alecsandru Patrascu a ?crit :
> 
> To compress all of the above, the main reason for this speedup is the
> reduction of the code path length and having the useful function
> close together, so that the CPU will be able to prefetch them in
> advance and use them instead of trowing them away because they are
> not used.

I'm expecting this patch to have an impact on executable or library
size, but not really on runtime performance, as the CPU instruction
cache only fetches whichever pieces of code are actually called.  In
other words, unused sections of code should remain cold wrt. the CPU
caches.  Apart from more or less random aliasing effects (and perhaps
TLB effects, but those should be very minor) I'm surprised that it has
positive performance effects.  But since you work at Intel, perhaps you
know things that I don't ;-)

Also any name starting with Py_ or _Py_ is an API that may be called by
third-party code, so it shouldn't be removed at all...

----------

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

From report at bugs.python.org  Thu Feb  4 16:53:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Feb 2016 21:53:16 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <56B3C41D.9090701@free.fr>
Message-ID: <CAMpsgwb+cQ3qoqH0SeOmUPr=4Ovb+a97eJfyn-F7us7SLSaLxQ@mail.gmail.com>


STINNER Victor added the comment:

> Also any name starting with Py_ or _Py_ is an API that may be called by third-party code, so it shouldn't be removed at all...

Right. You cannot remove the following functions, they are part of the
public C API (Include/pymem.h).

/usr/bin/ld: Removing unused section '.text.PyMem_RawMalloc' in file
'Objects/obmalloc.o'
/usr/bin/ld: Removing unused section '.text.PyMem_RawCalloc' in file
'Objects/obmalloc.o'
/usr/bin/ld: Removing unused section '.text.PyMem_RawRealloc' in file
'Objects/obmalloc.o'
/usr/bin/ld: Removing unused section '.text.PyMem_RawFree' in file
'Objects/obmalloc.o'

----------

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

From report at bugs.python.org  Thu Feb  4 16:58:37 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Thu, 04 Feb 2016 21:58:37 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1454623117.84.0.319657257844.issue23551@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

I am trying to make a Tk based GUI for pip package manager. In reference to msg256736, I am confused about the discovery method mentioned. Is there any way already implemented to detect the Python versions installed systemwide?

Moreover, how to manage the non-standard installation of Python by users? I think in that case, it would be very difficult to detect the Python versions installed in the user's system. In addition to it different tools used for installation of Python generally end up in installing in different folders or paths. 

Therefore, initially what functionality should I try to implement in it? Can anyone please suggest me?

----------
nosy: +upendra-k14

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

From report at bugs.python.org  Thu Feb  4 17:45:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 04 Feb 2016 22:45:10 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454625910.39.0.74239071992.issue21328@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not sure if resize() should change the len(). Dustin, why do you think it should? Not all ctypes objects even implement len(). The len() of 10 seems embedded in the class of the return value:

>>> b
<ctypes.c_char_Array_10 object at 0x7f143362fd90>

Also, how would this affect create_unicode_buffer(), if the buffer is resized to a non-multiple of sizeof(c_wchar)?

Gedai: I?m not that familiar with the ctypes internals, but it looks like __len__() is implemented on the Array base class:

>>> type(b).__len__
<slot wrapper '__len__' of '_ctypes.Array' objects>

Maybe look for the implementation of this method: <https://docs.python.org/3/c-api/typeobj.html#c.PySequenceMethods.sq_length>.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Thu Feb  4 17:55:42 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 22:55:42 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454626542.04.0.269410613953.issue21955@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

People should stop getting hung up about benchmarks numbers and instead should first think about what they are trying to *achieve*. FP performance in pure Python does not seem like an important goal in itself. Also, some benchmarks may show variations which are randomly correlated with a patch (e.g. before of different code placement by the compiler interfering with instruction cache wayness). It is important not to block a patch because some random benchmark on some random machine shows an unexpected slowdown.

That said, both of Serhiy's patches are probably ok IMO.

----------

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

From report at bugs.python.org  Thu Feb  4 18:00:40 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2016 23:00:40 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454626840.85.0.842552008076.issue26280@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I'm pretty sure that optimizing lists (and tuples?) is a great idea.

I think it's a good idea indeed.

> It would also be nice to optimize [-1] lookup

How is that different from the above? :)

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Feb  4 18:19:57 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Feb 2016 23:19:57 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1454627997.21.0.416472046457.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think an initial version of a pip gui need only install to the Python version running it.

The py launcher must discover some version of 'all' Python installs to choose, for instance, the latest 3.x version.  I do not know the details, nor which system py.exe runs on.  I was suggesting looking into the details after a first version.

A few days ago Steve Dower reported on pydev list how PSF installs on Windows register themselves in the registry (the keys used).  He also proposed a standard convention for other distributions to register, if they wish be be discovered by other apps, in a way that does not interfere with the entries for PSF installations.

Upendra, are you an intended GSOC student or simply a volunteer?  I am asking because, in the absence of submissions in nearly a year, I proposed on core-mentorship that this might be a good GSOC project.  I will not reserve this for GSOC if someone else is actually going to submit something.  But I also do not want to withdraw the idea unless someone is.

----------

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

From report at bugs.python.org  Thu Feb  4 18:50:00 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Thu, 04 Feb 2016 23:50:00 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454629800.28.0.962034036562.issue21328@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

I've added a patch, that solves the problem with the built-in len. Even if it turns out that this functionality is not needed, it was quite of a challenge to track down the issue, I've learned a lot. :)

Here are some functions, that I looked through, might be useful for someone, who'd like to look into this issue.

https://github.com/python/cpython/blob/master/Python/bltinmodule.c#L1443
static PyObject *
builtin_len(PyModuleDef *module, PyObject *obj)
/*[clinic end generated code: output=8e5837b6f81d915b input=bc55598da9e9c9b5]*/
{
    Py_ssize_t res;

    res = PyObject_Size(obj);
    if (res < 0 && PyErr_Occurred())
        return NULL;
    return PyLong_FromSsize_t(res);
}

https://github.com/python/cpython/blob/master/Objects/abstract.c#L42
Py_ssize_t
PyObject_Size(PyObject *o)
{
    /*...*/
    m = o->ob_type->tp_as_sequence;
    if (m && m->sq_length)
        return m->sq_length(o);
    /*...*/
}

https://github.com/python/cpython/blob/master/Modules/_ctypes/_ctypes.c#L4449
static PySequenceMethods Array_as_sequence = {
    Array_length,                               /* sq_length; */
    /*...*/
};

https://github.com/python/cpython/blob/master/Modules/_ctypes/_ctypes.c#L4442
static Py_ssize_t
Array_length(PyObject *myself)
{
    CDataObject *self = (CDataObject *)myself;
    return self->b_length;
}

----------
keywords: +patch
Added file: http://bugs.python.org/file41810/resize.patch

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

From report at bugs.python.org  Thu Feb  4 19:09:37 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 00:09:37 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454630977.91.0.881600344597.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> People should stop getting hung up about benchmarks numbers and instead should first think about what they are trying to *achieve*. FP performance in pure Python does not seem like an important goal in itself.

I'm not sure how to respond to that.  Every performance aspect *is* important.  numpy isn't shipped with CPython, not everyone uses it.  In one of my programs I used colorsys extensively -- did I need to rewrite it using numpy?  Probably I could, but that was a simple shell script without any dependencies.

It also harms Python 3 adoption a little bit, since many benchmarks are still slower.  Some of them are FP related.

In any case, I think that if we can optimize something - we should.


> Also, some benchmarks may show variations which are randomly correlated with a patch (e.g. before of different code placement by the compiler interfering with instruction cache wayness). 

30-50% speed improvement is not a variation.  It's just that a lot less code gets executed if we inline some operations.


> It is important not to block a patch because some random benchmark on some random machine shows an unexpected slowdown.

Nothing is blocked atm, we're just discussing various approaches.


> That said, both of Serhiy's patches are probably ok IMO.

Current Serhiy's patches are incomplete.  In any case, I've been doing some research and will post another message shortly.

----------

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

From report at bugs.python.org  Thu Feb  4 19:53:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 00:53:18 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454633598.74.0.524929783448.issue21328@psf.upfronthosting.co.za>


Martin Panter added the comment:

I can?t really comment on the patch, but I?m a bit worried that this is not the purpose of the b_length field.

----------
stage:  -> patch review

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

From report at bugs.python.org  Thu Feb  4 20:06:01 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2016 01:06:01 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454630977.91.0.881600344597.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B3F572.7070003@free.fr>


Antoine Pitrou added the comment:

Hi Yury,

> I'm not sure how to respond to that. Every performance aspect *is*
> important.

Performance is not a religion (not any more than security or any other
matter).  It is not helpful to brandish results on benchmarks which have
no relevance to real-world applications.

It helps to define what we should achieve and why we want to achieve it.
 Once you start asking "why", the prospect of speeding up FP
computations in the eval loop starts becoming dubious.

> numpy isn't shipped with CPython, not everyone uses it.

That's not the point. *People doing FP-heavy computations* should use
Numpy or any of the packages that can make FP-heavy computations faster
(Numba, Cython, Pythran, etc.).

You should use the right tool for the job.  There is no need to
micro-optimize a hammer for driving screws when you could use a
screwdriver instead.  Lists or tuples of Python float objects are an
awful representation for what should be vectorized native data.  They
eat more memory in addition to being massively slower (they will also be
slower to serialize from/to disk, etc.).

"Not using" Numpy when you would benefit from it is silly.
Numpy is not only massively faster on array-wide tasks, it also makes it
easier to write high-level, readable, reusable code instead of writing
loops and iterating by hand.  Because it has been designed explicitly
for such use cases (which the Python core was not, despite the existence
of the colorsys module ;-)).  It also gives you access to a large
ecosystem of third-party modules implementing various domain-specific
operations, actively maintained by experts in the field.

Really, the mindset of "people shouldn't need to use Numpy, they can do
FP computations in the interpreter loop" is counter-productive.  I
understand that it's seductive to think that Python core should stand on
its own, but it's also a dangerous fallacy.

You *should* advocate people use Numpy for FP computations.  It's an
excellent library, and it's currently a major selling point for Python.
Anyone doing FP-heavy computations with Python should learn to use
Numpy, even if they only use it from time to time.  Downplaying its
importance, and pretending core Python is sufficient, is not helpful.

> It also harms Python 3 adoption a little bit, since many benchmarks
> are still slower. Some of them are FP related.

The Python 3 migration is happening already. There is no need to worry
about it... Even the diehard 3.x haters have stopped talking of
releasing a 2.8 ;-)

> In any case, I think that if we can optimize something - we should.

That's not true. Some optimizations add maintenance overhead for no real
benefit. Some may even hinder performance as they add conditional
branches in a critical path (increasing the load on the CPU's branch
predictors and making them potentially less efficient).

Some optimizations are obviously good, like the method call optimization
which caters to real-world use cases (and, by the way, kudos for that...
you are doing much better than all previous attempts ;-)). But some are
solutions waiting for a problem to solve.

----------

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

From report at bugs.python.org  Thu Feb  4 20:19:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 01:19:38 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1454635178.42.0.968725823843.issue1927@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy, was your comment an objection to changing away from stderr, or was that just an observation that Python?s design is inconsistent with the rest of the world?

----------

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

From report at bugs.python.org  Thu Feb  4 20:21:25 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 05 Feb 2016 01:21:25 +0000
Subject: [issue26287] Core dump in f-string with lambda and format
 specification
Message-ID: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

Evaluating the expression f"{(lambda: 0):x}" crashes Python.

$ ./python
Python 3.6.0a0 (default, Feb  5 2016, 02:14:48) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f"{(lambda: 0):x}"  
Fatal Python error: Python/ceval.c:3576 object at 0x7f6b42f21338 has negative ref count -2604246222170760230
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
Aborted (core dumped)

----------
messages: 259609
nosy: encukou, eric.smith
priority: normal
severity: normal
status: open
title: Core dump in f-string with lambda and format specification
versions: Python 3.6

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

From report at bugs.python.org  Thu Feb  4 20:22:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Feb 2016 01:22:19 +0000
Subject: [issue12923] test_urllib fails in refleak mode
In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>
Message-ID: <20160205012215.2641.8409@psf.io>


Roundup Robot added the comment:

New changeset eb69070e5382 by Martin Panter in branch '3.5':
Issue #12923: Reset FancyURLopener's redirect counter even on exception
https://hg.python.org/cpython/rev/eb69070e5382

New changeset a8aa7944c5a8 by Martin Panter in branch '2.7':
Issue #12923: Reset FancyURLopener's redirect counter even on exception
https://hg.python.org/cpython/rev/a8aa7944c5a8

New changeset d3be5c4507b4 by Martin Panter in branch 'default':
Issue #12923: Merge FancyURLopener fix from 3.5
https://hg.python.org/cpython/rev/d3be5c4507b4

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Feb  4 20:28:24 2016
From: report at bugs.python.org (Zach Byrne)
Date: Fri, 05 Feb 2016 01:28:24 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454635704.93.0.931067247413.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

Ok, I've started on the instrumenting, thanks for that head start, that would have taken me a while to figure out where to call the stats dump function from. Fun fact: BINARY_SUBSCR is called 717 starting python.

----------

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

From report at bugs.python.org  Thu Feb  4 20:37:43 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 01:37:43 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454636263.61.0.377841355544.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

tl;dr   I'm attaching a new patch - fastint4 -- the fastest of them all. It incorporates Serhiy's suggestion to export long/float functions and use them.  I think it's reasonable complete -- please review it, and let's get it committed.

== Benchmarks ==

spectral_norm (fastint_alt)    -> 1.07x faster
spectral_norm (fastintfloat)   -> 1.08x faster
spectral_norm (fastint3.patch) -> 1.29x faster
spectral_norm (fastint4.patch) -> 1.16x faster

spectral_norm (fastint**.patch)-> 1.31x faster
nbody (fastint**.patch)        -> 1.16x faster

Where:
- fastint3 - is my previous patch that nobody likes (it inlined a lot of logic from longobject/floatobject)

- fastint4 - is the patch I'm attaching and ideally want to commit

- fastint** - is a modification of fastint4.  This is very interesting -- I started to profile different approaches, and found two bottlenecks, that really made Serhiy's and my other patches slower than fastint3.  What I found is that PyLong_AsDouble can be significantly optimized, and PyLong_FloorDiv is super inefficient.

PyLong_AsDouble can be sped up several times if we add a fastpath for 1-digit longs:

    // longobject.c: PyLong_AsDouble
    if (PyLong_CheckExact(v) && Py_ABS(Py_SIZE(v)) <= 1) {
        /* fast path; single digit will always fit decimal */
        return (double)MEDIUM_VALUE((PyLongObject *)v);
    }


PyLong_FloorDiv (fastint4 adds it) can be specialized for single digits, which gives it a tremendous boost.

With those too optimizations, fastint4 becomes as fast as fastint3.  I'll create separate issues for PyLong_AsDouble and FloorDiv.

== Micro-benchmarks ==

Floats + ints:  -m timeit -s "x=2" "x*2.2 + 2 + x*2.5 + 1.0 - x / 2.0 + (x+0.1)/(x-0.1)*2 + (x+10)*(x-30)"

2.7:          0.42 (usec)
3.5:          0.619
fastint_alt   0.619
fastintfloat: 0.52
fastint3:     0.289
fastint4:     0.51
fastint**:    0.314

===

Ints:  -m timeit -s "x=2" "x + 10 + x * 20 - x // 3 + x* 10 + 20 -x"

2.7:          0.151 (usec)
3.5:          0.19
fastint_alt:  0.136
fastintfloat: 0.135
fastint3:     0.135
fastint4:     0.122
fastint**:    0.122


P.S. I have another variant of fastint4 that uses fast_* functions in ceval loop, instead of a big macro.  Its performance is slightly worse than with the macro.

----------
Added file: http://bugs.python.org/file41811/fastint4.patch

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

From report at bugs.python.org  Thu Feb  4 20:40:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 01:40:00 +0000
Subject: [issue26287] Core dump in f-string with lambda and format
 specification
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <1454636400.36.0.857806534536.issue26287@psf.upfronthosting.co.za>


Martin Panter added the comment:

I had to recompile with ?--with-pydebug? to get the crash. I know f-strings don?t support the lambda syntax very well, but I can also make it crash without using lambda:

>>> f"{ {1: 2}:x}"
Fatal Python error: Python/ceval.c:3576 object at 0x7fa32ab030c8 has negative ref count -1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
Aborted (core dumped)

----------
components: +Interpreter Core
nosy: +martin.panter
type:  -> crash

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

From report at bugs.python.org  Thu Feb  4 20:48:02 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 01:48:02 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454636882.37.0.485877556571.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Antoine, FWIW I agree on most of your points :)  And yes, numpy, scipy, numba, etc rock.

Please take a look at my fastint4.patch.  All tests pass, no performance regressions, no crazy inlining of floating point exceptions etc.  And yet we have a nice improvement for both ints and floats.

----------

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

From report at bugs.python.org  Thu Feb  4 20:55:00 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 01:55:00 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
Message-ID: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The attached patch drastically speeds up PyLong_AsDouble for single digit longs:


-m timeit -s "x=2" "x*2.2 + 2 + x*2.5 + 1.0 - x / 2.0 + (x+0.1)/(x-0.1)*2 + (x+10)*(x-30)"

with patch: 0.414
without: 0.612

spectral_norm: 1.05x faster.    The results are even better when paired with patch from issue #21955.

----------
components: Interpreter Core
files: as_double.patch
keywords: patch
messages: 259615
nosy: haypo, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Optimize PyLong_AsDouble for single-digit longs
versions: Python 3.6
Added file: http://bugs.python.org/file41812/as_double.patch

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

From report at bugs.python.org  Thu Feb  4 20:57:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 01:57:05 +0000
Subject: [issue12923] test_urllib fails in refleak mode
In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>
Message-ID: <1454637425.88.0.348681824092.issue12923@psf.upfronthosting.co.za>


Martin Panter added the comment:

One extra change I made to test_redirect_limit_independent() was to stop relying on _urlopener being created before we call urlopen(). As a consequence, in the Python 3 tests I made a wrapper around FancyURLopener to suppress the deprecation warning.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 21:07:54 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 02:07:54 +0000
Subject: [issue26289] Optimize floor division for ints
Message-ID: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The attached patch optimizes floor division for ints.

### spectral_norm ###
Min: 0.319087 -> 0.289172: 1.10x faster
Avg: 0.322564 -> 0.294319: 1.10x faster
Significant (t=21.71)
Stddev: 0.00249 -> 0.01277: 5.1180x larger


-m timeit -s "x=22331" "x//2;x//3;x//4;x//5;x//6;x//7;x//8;x/99;x//100;"

with patch: 0.298
without:    0.515

----------
components: Interpreter Core
files: floor_div.patch
keywords: patch
messages: 259617
nosy: haypo, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize floor division for ints
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41813/floor_div.patch

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

From report at bugs.python.org  Thu Feb  4 21:25:00 2016
From: report at bugs.python.org (Michael Cuthbert)
Date: Fri, 05 Feb 2016 02:25:00 +0000
Subject: [issue17446] doctest test finder doesnt find line numbers of
 properties
In-Reply-To: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>
Message-ID: <1454639100.1.0.658936659283.issue17446@psf.upfronthosting.co.za>


Michael Cuthbert added the comment:

The test looks great to me.  Does anyone on nosy know the proper way to request a patch review?

----------

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

From report at bugs.python.org  Thu Feb  4 21:30:26 2016
From: report at bugs.python.org (Don Hatch)
Date: Fri, 05 Feb 2016 02:30:26 +0000
Subject: [issue26290] fileinput and 'for line in sys.stdin' do strange mockery
 of input buffering
Message-ID: <1454639426.39.0.789860369492.issue26290@psf.upfronthosting.co.za>


New submission from Don Hatch:

Iterating over input using either 'for line in fileinput.input():'
or 'for line in sys.stdin:' has the following unexpected behavior:
no matter how many lines of input the process reads, the loop body is not
entered until either (1) at least 8193 chars have been read and at least one of
them was a newline, or (2) EOF is read (i.e. the read() system call returns
zero bytes).

The behavior I expect instead is what
"for line in iter(sys.stdin.readline, ''):" does: that is, the loop body is
entered for the first time as soon as a newline or EOF is read.
Furthermore strace reveals that this well-behaved alternative code does
sensible input buffering, in the sense that the underlying system call being
made is read(0,buf,8192), thereby allowing it to get as many characters as are
available on input, up to 8192 of them, to be buffered and used in subsequent
loop iterations.  This is familiar and sensible behavior, and is what I think
of as "input buffering".

I anticipate there will be responses to this bug report of the form "this is
documented behavior; the fileinput and sys.stdin iterators do input buffering".
To that, I say: no, these iterators' unfriendly behavior is *not* input
buffering in any useful sense; my impression is that someone may have
implemented what they thought the words "input buffering" meant, but if so,
they really botched it.

This bug is most noticeable and harmful when using a filter written in python
to filter the output of an ongoing process that may have long pauses between
lines of output; e.g. running "tail -f" on a log file.  In this case, the
python filter spends a lot of time in a state where it is paused without
reason, having read many input lines that it has not yet processed.

If there is any suspicion that the delayed output is due to the previous
program in the pipeline buffering its output instead, strace can be used on the
python filter process to confirm that its input lines are in fact being read in
a timely manner.  This is certainly true if the previous process in the
pipeline is "tail -f", at least on my ubuntu linux system.

To demonstrate the bug, run each of the following from the bash command line.
This was observed using bash 4.3.11(1), python 2.7.6, and python 3.4.3,
on ubuntu 14.04 linux.

----------------------------------------------
{ echo a;echo b;echo c;sleep 1;} | python2.7 -c $'import fileinput,sys\nfor line in fileinput.input(): sys.stdout.write("line: "+line)'
    # result (BAD): pauses for 1 second, prints the three lines, returns to prompt

{ echo a;echo b;echo c;sleep 1;} | python2.7 -c $'import sys\nfor line in sys.stdin: sys.stdout.write("line: "+line)'
    # result (BAD): pauses for 1 second, prints the three lines, returns to prompt

{ echo a;echo b;echo c;sleep 1;} | python2.7 -c $'import sys\nfor line in iter(sys.stdin.readline, ""): sys.stdout.write("line: "+line)'
    # result (GOOD): prints the three lines, pauses for 1 second, returns to prompt

{ echo a;echo b;echo c;sleep 1;} | python3.4 -c $'import fileinput,sys\nfor line in fileinput.input(): sys.stdout.write("line: "+line)'
    # result (BAD): pauses for 1 second, prints the three lines, returns to prompt

{ echo a;echo b;echo c;sleep 1;} | python3.4 -c $'import sys\nfor line in sys.stdin: sys.stdout.write("line: "+line)'
    # result (GOOD): prints the three lines, pauses for 1 second, returns to prompt

{ echo a;echo b;echo c;sleep 1;} | python3.4 -c $'import sys\nfor line in iter(sys.stdin.readline, ""): sys.stdout.write("line: "+line)'
    # result (GOOD): prints the three lines, pauses for 1 second, returns to prompt
----------------------------------------------

Notice the 'for line in sys.stdin:' behavior is apparently fixed in python 3.4.
So the matrix of behavior observed above can be summarized as follows:

                                           2.7  3.4
for line in fileinput.input():             BAD  BAD
for line in sys.stdin:                     BAD  GOOD
for line in iter(sys.stdin.readline, ""):  GOOD GOOD

Note that adding '-u' to the python args makes no difference in behavior, in
any of the above 6 command lines.

Finally, if I insert "strace -T" before "python" in each of the 6 command lines
above, it confirms that the python process is reading the 3 lines of input
immediately in all cases, in a single read(..., ..., 4096 or 8192) which seems
reasonable.

----------
components: Library (Lib)
messages: 259619
nosy: Don Hatch
priority: normal
severity: normal
status: open
title: fileinput and 'for line in sys.stdin' do strange mockery of input buffering
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Feb  4 21:30:56 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 05 Feb 2016 02:30:56 +0000
Subject: [issue17446] doctest test finder doesnt find line numbers of
 properties
In-Reply-To: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>
Message-ID: <1454639456.82.0.438676113723.issue17446@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Left a comment on Rietveld. I don't have time right now to check the test, but I suspect you tested it before submitting the patch, so it should probably be fine.

----------
nosy: +ebarry
stage:  -> patch review

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

From report at bugs.python.org  Thu Feb  4 21:41:56 2016
From: report at bugs.python.org (Timo Furrer)
Date: Fri, 05 Feb 2016 02:41:56 +0000
Subject: [issue17446] doctest test finder doesnt find line numbers of
 properties
In-Reply-To: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>
Message-ID: <1454640116.81.0.298901529369.issue17446@psf.upfronthosting.co.za>


Timo Furrer added the comment:

Yes, I've tested it.

----------

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

From report at bugs.python.org  Thu Feb  4 21:54:53 2016
From: report at bugs.python.org (good.bad)
Date: Fri, 05 Feb 2016 02:54:53 +0000
Subject: [issue26291] Floating-point arithmetic
Message-ID: <1454640893.5.0.780875316779.issue26291@psf.upfronthosting.co.za>


New submission from good.bad:

print(1 - 0.8)
0.19999999999999996
print(1 - 0.2)
0.8

why not 0.2?

----------
messages: 259622
nosy: goodbad
priority: normal
severity: normal
status: open
title: Floating-point arithmetic
versions: Python 3.5

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

From report at bugs.python.org  Thu Feb  4 22:00:43 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 05 Feb 2016 03:00:43 +0000
Subject: [issue26291] Floating-point arithmetic
In-Reply-To: <1454640893.5.0.780875316779.issue26291@psf.upfronthosting.co.za>
Message-ID: <1454641243.91.0.969980054663.issue26291@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

This is due to how floating point numbers are handled under the hood. See http://effbot.org/pyfaq/why-are-floating-point-calculations-so-inaccurate.htm and https://docs.python.org/3/tutorial/floatingpoint.html for some useful read about why Python behaves like this regarding floating point numbers. Both these link state that this isn't a bug in Python, rightly so as it isn't.

----------
nosy: +ebarry
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 22:46:05 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Feb 2016 03:46:05 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454643965.48.0.112968859194.issue21328@psf.upfronthosting.co.za>


Eryk Sun added the comment:

You can't reassign the array object's __class__, and you can't modify the array type itself, so I think modifying the internal b_length field of the object is a confused result. 

Even if you ignore this confusion, it's still not as simple as using the size in bytes as the length. That's what b_size is for, after all. The array length is the new size divided by the element size, which you can get from PyType_stgdict(dict->proto)->size. Also, you'd have to ensure it's only updating b_length for arrays, i.e. ArrayObject_Check(obj), since it makes no sense to modify the length of a simple type, struct, union, or [function] pointer.

However, I don't think this result is worth the confusion. ctypes buffers can grow, but arrays have a fixed size by design. There are already ways to access a resized buffer. For example, you can use the from_buffer method to create an instance of a new array type that has the desired length, or you can dereference a pointer for the new array type. So I'm inclined to close this issue as "not a bug".

Note: 
Be careful when resizing buffers that are shared across objects. Say you resize array "a" and share it as array "b" using from_buffer or a pointer dereference. Then later you resize "a" again. The underlying realloc might change the base address of the buffer, while "b" still uses the old address. For example:

    >>> a = (ctypes.c_int * 5)(*range(5))
    >>> ctypes.resize(a, 4 * 10)
    >>> b = ctypes.POINTER(ctypes.c_int * 10)(a)[0]
    >>> ctypes.addressof(a)
    20136704
    >>> ctypes.addressof(b)
    20136704
    >>> b._b_needsfree_ # b doesn't own the buffer
    0
    >>> b[:] # the reallocation is not zeroed
    [0, 1, 2, 3, 4, 0, 0, 32736, 48, 0]

Here's the problem to keep in mind:

    >>> ctypes.resize(a, 4 * 1000)
    >>> ctypes.addressof(a)
    22077952
    >>> ctypes.addressof(b)
    20136704
    >>> b[:] # garbage; maybe a segfault
    [1771815800, 32736, 1633841761, 540763495, 1652121965,
     543236197, 1718052211, 1953264993, 10, 0]

----------
nosy: +eryksun
type:  -> enhancement

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

From report at bugs.python.org  Thu Feb  4 22:46:19 2016
From: report at bugs.python.org (Zach Byrne)
Date: Fri, 05 Feb 2016 03:46:19 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454643979.89.0.231361462956.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

I'll put together something comprehensive in a bit, but here's a quick preview:

$ ./python
Python 3.6.0a0 (default, Feb  4 2016, 20:08:03) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
Total BINARY_SUBSCR calls: 726
List BINARY_SUBSCR calls: 36
Tuple BINARY_SUBSCR calls: 103
Dict BINARY_SUBSCR calls: 227
Unicode BINARY_SUBSCR calls: 288
Bytes BINARY_SUBSCR calls: 68
[-1] BINARY_SUBSCR calls: 0

$ python bm_elementtree.py -n 100 --timer perf_counter
...[snip]...
Total BINARY_SUBSCR calls: 1078533
List BINARY_SUBSCR calls: 513
Tuple BINARY_SUBSCR calls: 1322
Dict BINARY_SUBSCR calls: 1063075
Unicode BINARY_SUBSCR calls: 13150
Bytes BINARY_SUBSCR calls: 248
[-1] BINARY_SUBSCR calls: 0

Lib/test$ ../../python -m unittest discover
...[snip]...^C <== I got bored waiting
KeyboardInterrupt
Total BINARY_SUBSCR calls:  4732885
List BINARY_SUBSCR calls:   1418730
Tuple BINARY_SUBSCR calls:  1300717
Dict BINARY_SUBSCR calls:   1151766
Unicode BINARY_SUBSCR calls: 409924
Bytes BINARY_SUBSCR calls:   363029
[-1] BINARY_SUBSCR calls:     26623

So dict seems to be the winner here

----------
keywords: +patch
Added file: http://bugs.python.org/file41814/26280_stats.diff

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

From report at bugs.python.org  Thu Feb  4 23:04:35 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 04:04:35 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454645075.56.0.555415188993.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching another approach -- fastint5.patch.

Similar to what fastint4.patch does, but doesn't export any new APIs.  Instead, similarly to abstract.c, it uses type slots directly.

----------
Added file: http://bugs.python.org/file41815/fastint5.patch

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

From report at bugs.python.org  Thu Feb  4 23:10:03 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 04:10:03 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454645403.58.0.540372911249.issue26280@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Looks like we want to specialize it for lists, tuples, and dicts; as expected.  Not so sure about [-1, but I suggest to benchmark it anyways ;)

----------

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

From report at bugs.python.org  Thu Feb  4 23:13:56 2016
From: report at bugs.python.org (Zach Byrne)
Date: Fri, 05 Feb 2016 04:13:56 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454645636.95.0.0338882731272.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

One thing I forgot to do was count slices.

----------

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

From report at bugs.python.org  Thu Feb  4 23:39:31 2016
From: report at bugs.python.org (Don Hatch)
Date: Fri, 05 Feb 2016 04:39:31 +0000
Subject: [issue26290] fileinput and 'for line in sys.stdin' do strange mockery
 of input buffering
In-Reply-To: <1454639426.39.0.789860369492.issue26290@psf.upfronthosting.co.za>
Message-ID: <1454647171.55.0.0178920862894.issue26290@psf.upfronthosting.co.za>


Don Hatch added the comment:

Possibly related to http://bugs.python.org/issue1633941 .
Note that the matrix of GOOD and BAD versions and input methods is
exactly the same for this bug as for that one.  To verify: run
each of the 6 python commands I mentioned on its own, being sure to type
at least one line of input ending in newline before hitting ctrl-D -- if it exits after one ctrl-D it's GOOD; having to type a second ctrl-D is BAD.

----------

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

From report at bugs.python.org  Thu Feb  4 23:56:10 2016
From: report at bugs.python.org (Don Hatch)
Date: Fri, 05 Feb 2016 04:56:10 +0000
Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first
 time
Message-ID: <1454648170.08.0.49846870026.issue1633941@psf.upfronthosting.co.za>


Don Hatch added the comment:

I've reported the unfriendly input withholding that several people have
observed and mentioned here as a separate bug: http://bugs.python.org/issue26290 . The symptom is different but I suspect it has exactly the same underlying cause (incorrect use of stdio) and fix that Ralph Corderoy has described clearly here.

----------
nosy: +Don Hatch

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

From report at bugs.python.org  Fri Feb  5 00:50:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 05:50:00 +0000
Subject: [issue26290] fileinput and 'for line in sys.stdin' do strange mockery
 of input buffering
In-Reply-To: <1454639426.39.0.789860369492.issue26290@psf.upfronthosting.co.za>
Message-ID: <1454651400.57.0.999923432169.issue26290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For fileinput see issue15068.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Feb  5 00:53:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 05:53:03 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454651583.48.0.877183114283.issue26280@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as statistics varies from test to test too much. Could you please collect the statistics for running all tests?

----------

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

From report at bugs.python.org  Fri Feb  5 01:23:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Feb 2016 06:23:35 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <20160205062332.6667.60315@psf.io>


Roundup Robot added the comment:

New changeset 6357d851029d by Antoine Pitrou in branch '2.7':
Issue #22847: Improve method cache efficiency.
https://hg.python.org/cpython/rev/6357d851029d

----------

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

From report at bugs.python.org  Fri Feb  5 01:24:08 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Feb 2016 06:24:08 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1454653448.34.0.560644666023.issue22847@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I suppose we've backported scarier things.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 01:38:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 06:38:28 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1454654308.02.0.399297892153.issue1927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is rather an objection.

If Gnu Readline is configured for stdout, why bash outputs to stderr? We should investigate what exactly do bash and other popular programs with readline, and implement this in Python.

Changing the documentation usually is a less drastic change than changing behavior.

----------

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

From report at bugs.python.org  Fri Feb  5 02:41:00 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 05 Feb 2016 07:41:00 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1454658060.54.0.332545183317.issue20160@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Fri Feb  5 02:59:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 07:59:35 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1454659175.06.0.291530130612.issue1927@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay, I see. To clarify, it is Python that sets up Gnu Readline for stdout: <https://hg.python.org/cpython/file/v3.5.1/Python/bltinmodule.c#l1941>. The problem is whichever way we go, we will have to change some part of the behaviour to make it internally consistent. I think my patch is the minimal change required.

----------

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

From report at bugs.python.org  Fri Feb  5 02:59:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 07:59:36 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1454659176.15.0.29315667733.issue1927@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay, I see. To clarify, it is Python that sets up Gnu Readline for stdout: <https://hg.python.org/cpython/file/v3.5.1/Python/bltinmodule.c#l1941>. The problem is whichever way we go, we will have to change some part of the behaviour to make it internally consistent. I think my patch is the minimal change required.

----------

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

From report at bugs.python.org  Fri Feb  5 02:59:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 07:59:54 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1454659194.64.0.405634599179.issue1927@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
Removed message: http://bugs.python.org/msg259637

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

From report at bugs.python.org  Fri Feb  5 03:29:59 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Fri, 05 Feb 2016 08:29:59 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454660999.19.0.304033887918.issue21328@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

Thanks for the remarks, I think the issue can be closed as well.

----------

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

From report at bugs.python.org  Fri Feb  5 03:40:40 2016
From: report at bugs.python.org (Dustin Oprea)
Date: Fri, 05 Feb 2016 08:40:40 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454661640.56.0.471440212558.issue21328@psf.upfronthosting.co.za>


Dustin Oprea added the comment:

I'm closing it. The ticket has been open two-years and no one else seemed to be interested in this issue until now, which leads me to believe that it's a PEBCAK/understanding issue. The rationale for why it's irrelevant seems sound. Thanks for digging through the code, Tam?s. Thank you for your comments, Martin and Eryk.

----------
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 03:44:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 08:44:20 +0000
Subject: [issue26292] Raw I/O writelines() broken
Message-ID: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Copy of Antoine Pitrou's email (sent in 2012 ;-):
https://mail.python.org/pipermail/python-dev/2012-August/121396.html

Hello,

I was considering a FileIO.writelines() implementation based on
writev() and I noticed that the current RawIO.writelines()
implementation is broken: RawIO.write() can return a partial write but
writelines() ignores the result and happily proceeds to the next
iterator item (and None is returned at the end).

(it's probably broken with non-blocking streams too, for the same
reason)

In the spirit of RawIO.write(), I think RawIO.writelines() could return
the number of bytes written (allowing for partial writes).

Regards

Antoine.

-- 
Software development and contracting: http://pro.pitrou.net

----------
components: IO
messages: 259640
nosy: haypo
priority: normal
severity: normal
status: open
title: Raw I/O writelines() broken
versions: Python 3.6

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

From report at bugs.python.org  Fri Feb  5 03:48:06 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Feb 2016 08:48:06 +0000
Subject: [issue21328] Resize doesn't change reported length on
 create_string_buffer()
In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>
Message-ID: <1454662086.27.0.972800847426.issue21328@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
resolution:  -> not a bug
stage: patch review -> resolved

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

From report at bugs.python.org  Fri Feb  5 03:51:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 08:51:44 +0000
Subject: [issue26292] Raw I/O writelines() broken
In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>
Message-ID: <1454662304.81.0.425784794652.issue26292@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"(it's probably broken with non-blocking streams too, for the same
reason)"

Yes it is :-)

We hitted this issue on eventlet when I changed the socket.send() method in eventlet 0.18 to stop sending data on partial write, whereas eventlet < 0.18 used a loop to ensure that all bytes are written.

The side effect of my change is that (indirectly) socket.makefile().writelines() may also use partial write if the underlying send() only writes partially data.

The problem is that writelines() has *no* result, so the caller cannot be aware of the partial write and data is lost...

eventlet:

* send() change: https://github.com/eventlet/eventlet/issues/274
* writelines() bug: https://github.com/eventlet/eventlet/issues/295


"In the spirit of RawIO.write(), I think RawIO.writelines() could return
the number of bytes written (allowing for partial writes)."

I don't know yet what is the best option for eventlet, but we should probaly enhance the Python stdlib io module to return something on writelines() and *document* the behaviour on partial write.

The problem writelines() API is that writelines() not only takes a single text/bytes string, but a *list* of text/bytes strings.

Another option is to modify to retry on partial write to ensure that all data is written. If the underlying write() method returns None (blocking I/O error), we must raise an error. It doesn't make sense to retry writing on a non-blocking I/O error.

In this case, we must document that writelines() *must not* be used on non-blocking I/O (ex: non-blocking socket, pipe, whatever).

----------

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

From report at bugs.python.org  Fri Feb  5 03:51:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 08:51:55 +0000
Subject: [issue26292] Raw I/O writelines() broken
In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>
Message-ID: <1454662315.35.0.696806179947.issue26292@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +pitrou
versions: +Python 3.5

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

From report at bugs.python.org  Fri Feb  5 03:52:35 2016
From: report at bugs.python.org (spoo)
Date: Fri, 05 Feb 2016 08:52:35 +0000
Subject: [issue26293] Embedded zipfile fields dependent on absolute position
Message-ID: <1454662355.53.0.48718125489.issue26293@psf.upfronthosting.co.za>


New submission from spoo:

Example:

from zipfile import ZipFile
with open('a.zipp', 'wb') as base:
    base.write(b'old\n')
    with ZipFile(base, 'a') as myzip:
        myzip.write('eggs.txt')

If the embedded zip portion of the file is extracted (first four bytes deleted), some fields will be incorrect in the resultant file - commenting out line 3 produces a file that can serve as a comparison.  These differences cause issues opening with some zip library implementations.

My best guess is that this is related to this line: https://github.com/python/cpython/blob/master/Lib/zipfile.py#L1459

----------
components: Library (Lib)
messages: 259642
nosy: spoo
priority: normal
severity: normal
status: open
title: Embedded zipfile fields dependent on absolute position
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Feb  5 03:53:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 08:53:40 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1454662420.13.0.468105745463.issue1927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think we first should fix 3.6 in correct way, and then see what we can backport to other branches without breaking too much. Or left them as is. For example the output of --version was changed from strerr to stdout (issue18338, issue18920) in default branch, but this was not backported.

----------

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

From report at bugs.python.org  Fri Feb  5 03:59:20 2016
From: report at bugs.python.org (spoo)
Date: Fri, 05 Feb 2016 08:59:20 +0000
Subject: [issue26293] Embedded zipfile fields dependent on absolute position
In-Reply-To: <1454662355.53.0.48718125489.issue26293@psf.upfronthosting.co.za>
Message-ID: <1454662760.08.0.451752044132.issue26293@psf.upfronthosting.co.za>


spoo added the comment:

I'm not familiar with iOS development, but I'd hazard a guess that "some zip library implementations" means a (the official?) iOS zip library.

----------

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

From report at bugs.python.org  Fri Feb  5 04:00:58 2016
From: report at bugs.python.org (Frank Millman)
Date: Fri, 05 Feb 2016 09:00:58 +0000
Subject: [issue26294] Queue().unfinished_tasks not in docs - deliberate?
Message-ID: <1454662858.22.0.0628824582163.issue26294@psf.upfronthosting.co.za>


New submission from Frank Millman:

dir(queue.Queue()) shows an attribute 'unfinished_tasks'.

It appears to be the counter referred to in the docs to 'join()', but it is not documented itself.

I would like to make use of it, but I don't know if it is part of the official API for this module.

Please advise.

----------
assignee: docs at python
components: Documentation
messages: 259645
nosy: docs at python, frankmillman
priority: normal
severity: normal
status: open
title: Queue().unfinished_tasks not in docs - deliberate?
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Feb  5 04:10:10 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Fri, 05 Feb 2016 09:10:10 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1454663410.94.0.518881721145.issue23551@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

@Terry, I am an intended GSOC student and I came through this idea of developing a GUI based on Tkinter in the python core-mentorship mailing lists. You highlighted/mentioned this issue in the mailing list.

----------

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

From report at bugs.python.org  Fri Feb  5 04:15:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 09:15:07 +0000
Subject: [issue26295] Random failures when running test suite in parallel (-m
 test -j0) caused by test_regrtest
Message-ID: <1454663707.24.0.201658170139.issue26295@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_regrtest creates temporary test files called test_regrtest_pid_xxx.py in Lib/test/. The problem is that some tests like test___all__ and test_zipfile haves test relying on the list of Lib/test/test_*.py.

When tests are run in parallel, test_regrtest can creates temporary test_regrtest_pid_xxx.py files, test_zipfile sees them, test_regrtest removes them, and then test_zipfiles fails.

The best would be to write these temporary files into a temporary directory, but I failed to fix Lib/test/regrtest.py to load tests from a different directory. In theory, Python 3 supports packages with files splitted into multiple directories, in practice it doesn't seem to work :-p

Maybe test_regrtest should use a test submodule like Lib/test/temp_regrtest/ ?

test_regrtest started to create temporary test_xxx.py files since issue #25220. (Other changes to test_regrtest: issues #18174, #22806, #25260, #25306,  #25369, #25373, #25694).

======================================================================
ERROR: test_all (test.test___all__.AllTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test___all__.py", line 102, in test_all
    with open(path, "rb") as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/haypo/prog/python/default/Lib/test/test_regrtest_25743_noop20.py'

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

----------
components: Tests
messages: 259647
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: Random failures when running test suite in parallel (-m test -j0) caused by test_regrtest
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Feb  5 04:16:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 09:16:08 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1454663768.49.0.848387733947.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Rebased patch combining also pycf_transformed_ast.patch.

----------
Added file: http://bugs.python.org/file41816/transformers-5.patch

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

From report at bugs.python.org  Fri Feb  5 04:33:10 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 05 Feb 2016 09:33:10 +0000
Subject: [issue26287] Core dump in f-string with lambda and format
 specification
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <1454664790.98.0.102472258987.issue26287@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

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

From report at bugs.python.org  Fri Feb  5 04:36:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 09:36:49 +0000
Subject: [issue26295] Random failures when running test suite in parallel (-m
 test -j0) caused by test_regrtest
In-Reply-To: <1454663707.24.0.201658170139.issue26295@psf.upfronthosting.co.za>
Message-ID: <1454665009.28.0.642568449289.issue26295@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The directory with test files can be read-only. test_regrtest should use temporary directory.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Feb  5 04:38:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 09:38:45 +0000
Subject: [issue26295] Random failures when running test suite in parallel (-m
 test -j0) caused by test_regrtest
In-Reply-To: <1454663707.24.0.201658170139.issue26295@psf.upfronthosting.co.za>
Message-ID: <1454665125.97.0.0819805126887.issue26295@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The directory with test files can be read-only.

test_regrtest skips tests which requires to write in Lib/test/ if the write fails.

        except PermissionError as exc:
            if not sysconfig.is_python_build():
                self.skipTest("cannot write %s: %s" % (path, exc))

> test_regrtest should use temporary directory.

Yes! That's the purpose of this issue!

But I was unable to find a technical solution to implement this. I need to try harder :-)

----------

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

From report at bugs.python.org  Fri Feb  5 04:43:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 09:43:39 +0000
Subject: [issue26293] Embedded zipfile fields dependent on absolute position
In-Reply-To: <1454662355.53.0.48718125489.issue26293@psf.upfronthosting.co.za>
Message-ID: <1454665419.64.0.690976298943.issue26293@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +alanmcintyre, serhiy.storchaka, twouters

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

From report at bugs.python.org  Fri Feb  5 04:46:20 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Fri, 05 Feb 2016 09:46:20 +0000
Subject: [issue26292] Raw I/O writelines() broken
In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>
Message-ID: <1454665580.48.0.528289721691.issue26292@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

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

From report at bugs.python.org  Fri Feb  5 04:52:53 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2016 09:52:53 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454665973.77.0.487518711315.issue26280@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The test suite is not an appropriate workload to run benchmarks or statistics. Can you run with the benchmarks suite instead?

----------

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

From report at bugs.python.org  Fri Feb  5 04:54:07 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2016 09:54:07 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454666047.41.0.0249882178279.issue26280@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I also suggest counting the number of BINARY_SUBSCR calls that are *not* one of the builtin types under consideration. Also, it would be good to distinguish slicing from integer indexing, for lists and tuples.

----------

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

From report at bugs.python.org  Fri Feb  5 05:25:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 10:25:19 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1454667919.4.0.0367845580028.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 7:

* Fix a random crash related to _testcapi.PyGuard: implement tp_traverse on PyFuncGuard and "inherit" tp_traverse on PyGuard
* Fix a typo Include/funcobject.h
* (rebase the patch)

----------
Added file: http://bugs.python.org/file41817/specialize-7.patch

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

From report at bugs.python.org  Fri Feb  5 05:29:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 10:29:42 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1454668182.69.0.157579148394.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I missed comments on the code review. Fixed on patch version 8.

----------
Added file: http://bugs.python.org/file41818/specialize-8.patch

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

From report at bugs.python.org  Fri Feb  5 07:05:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 12:05:50 +0000
Subject: [issue26292] Raw I/O writelines() broken
In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>
Message-ID: <1454673950.71.0.473737065174.issue26292@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is deprecating RawIOBase.writelines() an option, and only recommending BufferedIOBase.writelines() and TextIOBase.writelines()?

Otherwise, I think it would make most sense to keep retrying until all the data is written. This mirrors how I understand readline() and readall() work (keeps reading until it gets as much as necessary).

For non-blocking mode, readline() does not support that (see Issue 13858). It does not make much sense to me to have writelines() support non-blocking mode either.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Fri Feb  5 07:13:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 12:13:20 +0000
Subject: [issue26292] Raw I/O writelines() broken
In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>
Message-ID: <1454674400.89.0.471444535501.issue26292@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Is deprecating RawIOBase.writelines() an option, and only recommending BufferedIOBase.writelines() and TextIOBase.writelines()?

IMHO the problem is the same for other classes.

----------

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

From report at bugs.python.org  Fri Feb  5 07:50:48 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Fri, 05 Feb 2016 12:50:48 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454676648.96.0.871832063279.issue26285@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I've done again the experiments on larger workloads, such as our OpenStack Swift cluster, and it works without any issues.

Also, I've attached an archive with a simple external module in CPython3 that uses PyMem_RawMalloc. The output is ok, and it's copied bellow.


u at palecsandru:~/w/experimente/c_ext3$ /home/u/w/cpython3_deadcode/python setup.py build_ext --inplace
running build_ext
building 'mytest' extension
creating build
creating build/temp.linux-x86_64-3.6
gcc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fdata-sections -ffunction-sections -Wl,--gc-sections -fPIC -I/home/u/w/cpython3_deadcode/Include -I/home/u/w/cpython3_deadcode -c mytest.c -o build/temp.linux-x86_64-3.6/mytest.o
gcc -pthread -shared build/temp.linux-x86_64-3.6/mytest.o -o /home/u/w/experimente/c_ext3/mytest.cpython-36m-x86_64-linux-gnu.so

u at palecsandru:~/w/experimente/c_ext3$ ll
total 40
drwxrwxr-x  3 u u  4096 Feb  5 14:29 ./
drwxr-xr-x 12 u u  4096 Feb  5 14:00 ../
drwxrwxr-x  3 u u  4096 Feb  5 14:29 build/
-rw-rw-r--  1 u u   619 Feb  5 14:16 mytest.c
-rwxrwxr-x  1 u u 17856 Feb  5 14:29 mytest.cpython-36m-x86_64-linux-gnu.so*
-rw-rw-r--  1 u u   132 Feb  5 14:15 setup.py

u at palecsandru:~/w/experimente/c_ext3$ /home/u/w/cpython3_deadcode/python
Python 3.6.0a0 (default:87dfadd61e0d+, Feb  5 2016, 14:22:57) 
[GCC 5.2.1 20151010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mytest
>>> mytest.mytest()
'test'
>>>

----------
Added file: http://bugs.python.org/file41819/c_ext3.zip

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

From report at bugs.python.org  Fri Feb  5 08:03:36 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 05 Feb 2016 13:03:36 +0000
Subject: [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <1454677416.13.0.560020541232.issue26248@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Seeing this has been merged (thanks Victor), can this issue be closed? Guido, are you happy with the changes given your comments at http://bugs.python.org/issue26032#msg257665?

----------

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

From report at bugs.python.org  Fri Feb  5 09:00:12 2016
From: report at bugs.python.org (Mats Luspa)
Date: Fri, 05 Feb 2016 14:00:12 +0000
Subject: [issue26296] colorys rgb_to_hls algorithm error
Message-ID: <1454680812.05.0.172060571572.issue26296@psf.upfronthosting.co.za>


New submission from Mats Luspa:

In the colorsys library function rgb_to_hls the algorithm is not implemented quite correctly.

According to algorithm the correct implementation should be (the error is in the condition r == maxc). In the current code g<b is not tested:

def rgb_to_hls(r, g, b):
    maxc = max(r, g, b)
    minc = min(r, g, b)
    # XXX Can optimize (maxc+minc) and (maxc-minc)
    l = (minc+maxc)/2.0
    if minc == maxc:
        return 0.0, l, 0.0
    if l <= 0.5:
        s = (maxc-minc) / (maxc+minc)
    else:
        s = (maxc-minc) / (2.0-maxc-minc)
    rc = (maxc-r) / (maxc-minc)
    gc = (maxc-g) / (maxc-minc)
    bc = (maxc-b) / (maxc-minc)
    if r == maxc:
        if (g<b):
            h = bc-gc+6
        else:
            h = bc-gc
    elif g == maxc:
        h = 2.0+rc-bc
    else:
        h = 4.0+gc-rc
    h = (h/6.0) % 1.0
    return h, l, s

----------
components: Library (Lib)
messages: 259659
nosy: Mats Luspa
priority: normal
severity: normal
status: open
title: colorys rgb_to_hls algorithm error

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

From report at bugs.python.org  Fri Feb  5 09:02:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 14:02:07 +0000
Subject: [issue26296] colorys rgb_to_hls algorithm error
In-Reply-To: <1454680812.05.0.172060571572.issue26296@psf.upfronthosting.co.za>
Message-ID: <1454680927.26.0.0180995461662.issue26296@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, someone uses colorsys :-)

----------
nosy: +haypo, yselivanov

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

From report at bugs.python.org  Fri Feb  5 09:04:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 14:04:45 +0000
Subject: [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454677416.13.0.560020541232.issue26248@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY6M1_rsJFt0W8GgwSJX0KiJ2SjdOU-7nCFipeU1Np=gw@mail.gmail.com>


STINNER Victor added the comment:

Ben Hoyt added the comment:
> Seeing this has been merged (thanks Victor), can this issue be closed?

As I wrote, I left the issue open for wait for feedback. I know that
some people to read the doc online:
https://docs.python.org/dev/library/os.html#os.DirEntry

----------

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

From report at bugs.python.org  Fri Feb  5 09:10:28 2016
From: report at bugs.python.org (Jens Diemer)
Date: Fri, 05 Feb 2016 14:10:28 +0000
Subject: [issue18199] Windows: support path longer than 260 bytes using "\\?\"
 prefix
In-Reply-To: <1371050681.12.0.381093438517.issue18199@psf.upfronthosting.co.za>
Message-ID: <1454681428.2.0.451579301637.issue18199@psf.upfronthosting.co.za>


Jens Diemer added the comment:

I also with this problems.

I have made a test script.

There is a problem with os.chdir(): It doesn't work with \\?\ notation.
And there is also a problem, if you use 

```
import os
import pathlib
import tempfile

with tempfile.TemporaryDirectory(prefix="path_test_") as path:
    new_path = pathlib.Path(path, "A"*255, "B"*255)
    extended_path = "\\\\?\\%s" % new_path
    os.makedirs(extended_path)
    print(len(extended_path), extended_path)
```
os.makedirs() will work, but the cleanup will failed.
Output is:
```
567 \\?\C:\Users\jens\AppData\Local\Temp\path_test_8fe6utdz\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Traceback (most recent call last):
  File "D:\test2.py", line 18, in <module>
    print(len(extended_path), extended_path)
  File "C:\Program Files (x86)\Python35-32\lib\tempfile.py", line 807, in __exit__
    self.cleanup()
  File "C:\Program Files (x86)\Python35-32\lib\tempfile.py", line 811, in cleanup
    _shutil.rmtree(self.name)
  File "C:\Program Files (x86)\Python35-32\lib\shutil.py", line 488, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\Program Files (x86)\Python35-32\lib\shutil.py", line 383, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "C:\Program Files (x86)\Python35-32\lib\shutil.py", line 381, in _rmtree_unsafe
    os.unlink(fullname)
FileNotFoundError: [WinError 3] Das System kann den angegebenen Pfad nicht finden: 'C:\\Users\\jens\\AppData\\Local\\Temp\\path_test_8fe6utdz\\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
```

----------
nosy: +jens
Added file: http://bugs.python.org/file41820/test.py

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

From report at bugs.python.org  Fri Feb  5 09:33:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 14:33:48 +0000
Subject: [issue26296] colorys rgb_to_hls algorithm error
In-Reply-To: <1454680812.05.0.172060571572.issue26296@psf.upfronthosting.co.za>
Message-ID: <1454682828.7.0.809367567641.issue26296@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Fri Feb  5 09:44:25 2016
From: report at bugs.python.org (Will Harris)
Date: Fri, 05 Feb 2016 14:44:25 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1454683465.73.0.880531137999.issue25228@psf.upfronthosting.co.za>


Changes by Will Harris <will at harris.ch>:


----------
nosy: +harris

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

From report at bugs.python.org  Fri Feb  5 10:10:26 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 15:10:26 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454685026.69.0.999089614867.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Unless there are any objections, I'll commit fastint5.patch in a day or two.

----------

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

From report at bugs.python.org  Fri Feb  5 10:14:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 15:14:25 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454685265.51.0.152529141921.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Unless there are any objections, I'll commit fastint5.patch in a day or two.

Please don't. I would like to have time to benchmark all these patches (there are now 9 patches attached to the issue :-)) and I would like to hear Serhiy's feedback on your latest patches.

----------

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

From report at bugs.python.org  Fri Feb  5 10:14:44 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 05 Feb 2016 15:14:44 +0000
Subject: [issue26287] Core dump in f-string with formatting errors due to
 refcount bug
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <1454685284.03.0.473409112762.issue26287@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

The problem has to do with refcounting when an error occurs. Adjusting the title accordingly.

I'm not sure yet if the problem is in PyObject_Format(), or in handling errors in the eval loop when processing FORMAT_VALUE opcodes. I'm slowly tracking it down. It doesn't happen with format(), so I suspect it's in FORMAT_VALUE.

Here's an example showing the error with a large, non-cached int. You need to call it twice to trigger the refcount problem.

>>> f'{1000:j}'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'j' for object of type 'int'
>>> f'{1000:j}'
Fatal Python error: Objects/tupleobject.c:233 object at 0x7f904006b360 has negative ref count -2604246222170760230

Current thread 0x00007f9041278700 (most recent call first):
Aborted (core dumped)

----------
title: Core dump in f-string with lambda and format specification -> Core dump in f-string with formatting errors due to refcount bug

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

From mal at egenix.com  Fri Feb  5 10:26:05 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 5 Feb 2016 16:26:05 +0100
Subject: [issue21955] ceval.c: implement fast path for integers with a
 single digit
In-Reply-To: <1454685265.51.0.152529141921.issue21955@psf.upfronthosting.co.za>
References: <1454685265.51.0.152529141921.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B4BF0D.2050301@egenix.com>

On 05.02.2016 16:14, STINNER Victor wrote:
> 
> Please don't. I would like to have time to benchmark all these patches (there are now 9 patches attached to the issue :-)) and I would like to hear Serhiy's feedback on your latest patches.

Regardless of the performance, the fastint5.patch looks like the
least invasive approach to me. It also doesn't incur as much
maintenance overhead as the others do.

I'd only rename the macro MAYBE_DISPATCH_FAST_NUM_OP to
TRY_FAST_NUMOP_DISPATCH :-)

BTW: I do wonder why this approach is as fast as the others. Have
compilers grown smart enough to realize that the number slot
functions will not change and can thus be inlined ?

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Feb  5 10:26:13 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 05 Feb 2016 15:26:13 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1454685265.51.0.152529141921.issue21955@psf.upfronthosting.co.za>
Message-ID: <56B4BF0D.2050301@egenix.com>


Marc-Andre Lemburg added the comment:

On 05.02.2016 16:14, STINNER Victor wrote:
> 
> Please don't. I would like to have time to benchmark all these patches (there are now 9 patches attached to the issue :-)) and I would like to hear Serhiy's feedback on your latest patches.

Regardless of the performance, the fastint5.patch looks like the
least invasive approach to me. It also doesn't incur as much
maintenance overhead as the others do.

I'd only rename the macro MAYBE_DISPATCH_FAST_NUM_OP to
TRY_FAST_NUMOP_DISPATCH :-)

BTW: I do wonder why this approach is as fast as the others. Have
compilers grown smart enough to realize that the number slot
functions will not change and can thus be inlined ?

----------

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

From report at bugs.python.org  Fri Feb  5 10:32:31 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 15:32:31 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454686351.01.0.317722204105.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

>> Unless there are any objections, I'll commit fastint5.patch in a day or two.

> Please don't. I would like to have time to benchmark all these patches (there are now 9 patches attached to the issue :-)) and I would like to hear Serhiy's feedback on your latest patches.

Sure, I'd very appreciate a review of fastint5.

I can save you sometime on benchmarking -- it's really about fastint_alt vs fastint5.  The latter optimizes ALL ops on longs AND floats.  The former only optimizes some ops on longs.  So please be sure you're comparing oranges to oranges ;)

----------

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

From report at bugs.python.org  Fri Feb  5 10:43:39 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 15:43:39 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454687019.52.0.771779064581.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Regardless of the performance, the fastint5.patch looks like the
least invasive approach to me. It also doesn't incur as much
maintenance overhead as the others do.

Thanks.  It's a result of an enlightenment that can only come
after running benchmarks all day :)

> I'd only rename the macro MAYBE_DISPATCH_FAST_NUM_OP to
TRY_FAST_NUMOP_DISPATCH :-)

Yeah, your name is better.

> BTW: I do wonder why this approach is as fast as the others. Have
compilers grown smart enough to realize that the number slot
functions will not change and can thus be inlined ?

Looks like so, I'm very impressed myself.  I'd expect fastint3 (which just inlines a lot of logic directly in ceval.c) to be the fastest one.  But it seems that compiler does an excellent job here.

Victor, BTW, if you want to test fastint3 vs fastint5, don't forget to apply the patch from issue #26288 over fastint5 (fixes slow performance of PyLong_AsDouble)

----------

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

From report at bugs.python.org  Fri Feb  5 10:58:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 15:58:18 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454687898.46.0.620652867332.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

bench_long2.py: my updated microbenchmark to test many types and more operations.

compare.txt: compare Python original, fastint_alt.patch, fastintfloat_alt.patch and fastint5.patch. "(*)" marks the minimum of the line, percents are relative to the minimum (if larger than +/-5%).

compare_to.txt: similar to compare.txt, but percents are relative to the original Python.

----------
Added file: http://bugs.python.org/file41821/bench_long2.py

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

From report at bugs.python.org  Fri Feb  5 10:58:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 15:58:24 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454687904.36.0.445730548962.issue21955@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file41822/compare.txt

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

From report at bugs.python.org  Fri Feb  5 10:58:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 15:58:30 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454687910.78.0.543147541201.issue21955@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file41823/compare_to.txt

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

From report at bugs.python.org  Fri Feb  5 11:15:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 16:15:24 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454688924.97.0.940226921189.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

My analysis of benchmarks.

Even using CPU isolation to run benchmarks, the results look unreliable for very short benchmarks like 3 ** 2.0: I don't think that fastint_alt can make the operation 16% slower since it doesn't touch this code, no?

Well... as expected, speedup is quite *small*: the largest difference is on "3 * 2" ran 100 times: 18% faster with fastint_alt. We are talking about 1.82 us => 1.49 us: delta of 330 ns. I expect a much larger difference is you compile a function to machine code using Cython or a JIT like Numba and PyPy. Remember that we are running *micro*-benchmarks, so we should not push overkill optimizations except if the speedup is really impressive.

It's quite obvious from the tables than fastint_alt.patch only optimize int (float is not optimized). If we choose to optimize float too, fastintfloat_alt.patch and fastint5.patch look to have the *same* speed.

I don't see any overhead on Decimal + Decimal with any patch: good.

--

Between fastintfloat_alt.patch and fastint5.patch, I prefer fastintfloat_alt.patch which is much easier to read, so probably much easier to debug. I hate huge macro when I have to debug code in gdb :-( I also like very much the idea of *reusing* existing functions, rather than duplicating code.

Even if Antoine doesn't seem interested by optimizations on float, I think that it's ok to add a few lines for this type, fastintfloat_alt.patch is not so complex. What do *you* think?

Why not optimizing a**b? It's a common operation, especially 2**k, no?

----------

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

From report at bugs.python.org  Fri Feb  5 11:18:59 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 16:18:59 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454689139.54.0.847757149171.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Between fastintfloat_alt.patch and fastint5.patch, I prefer fastintfloat_alt.patch which is much easier to read, so probably much easier to debug. I hate huge macro when I have to debug code in gdb :-( I also like very much the idea of *reusing* existing functions, rather than duplicating code.

I disagree.

fastintfloat_alt exports a lot of functions from longobject/floatobject, something that I really don't like.  Lots of repetitive code in ceval.c also make it harder to make sure everything is correct.

----------

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

From report at bugs.python.org  Fri Feb  5 11:22:39 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 16:22:39 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454689359.24.0.534961799408.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Anyways, if it's about macro vs non-macro, I can inline the macro by hand (which I think is an inferior approach here).  But I'd like the final code to use my approach of using slots directly, instead of modifying longobject/floatobject to export lots of *internal* stuff.

----------

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

From report at bugs.python.org  Fri Feb  5 11:32:58 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 16:32:58 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454689978.57.0.604322118797.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

As to weather we want this patch committed or not, here's a mini-macro-something benchmark:


$ ./python.exe -m timeit -s "x=2" "x + 10 + x * 20  + x* 10 + 20 -x"
10000000 loops, best of 3: 0.115 usec per loop

$ python3.5 -m timeit -s "x=2" "x + 10 + x * 20  + x* 10 + 20 -x"
10000000 loops, best of 3: 0.141 usec per loop


$ ./python.exe -m timeit -s "x=2" "x*2.2 + 2 + x*2.5 + 1.0 - x / 2.0 + (x+0.1)/(x-0.1)*2 + (x+10)*(x-30)"
1000000 loops, best of 3: 0.308 usec per loop

$ python3.5 -m timeit -s "x=2" "x*2.2 + 2 + x*2.5 + 1.0 - x / 2.0 + (x+0.1)/(x-0.1)*2 + (x+10)*(x-30)"
1000000 loops, best of 3: 0.652 usec per loop


Still, longs are faster 30-50%, FP are faster 100%.  I think it's a very good result.  Please don't block this patch.

----------

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

From report at bugs.python.org  Fri Feb  5 11:48:15 2016
From: report at bugs.python.org (Chris AtLee)
Date: Fri, 05 Feb 2016 16:48:15 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1454690895.95.0.752010536846.issue19217@psf.upfronthosting.co.za>


Chris AtLee added the comment:

Switching this to unified_diff allows the test case to finish nearly instantly.

The downside is that the output is changed in the case of a difference found:

FF
======================================================================
FAIL: test_compare (__main__.SCSE)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_case.py", line 14, in test_compare
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,[29953 chars]1, 1] != [2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,[29953 chars]2, 2]

First differing element 0:
1
2

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

======================================================================
FAIL: test_compare_2 (__main__.SCSE)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_case.py", line 24, in test_compare_2
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] != [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2]

First differing element 9999:
1
2

--- 
+++ 
@@ -9997,4 +9997,4 @@
  1,
  1,
  1,
- 1]
+ 2]

----------------------------------------------------------------------
Ran 2 tests in 0.098s

FAILED (failures=2)
------------------------------------------------------------

----------
nosy: +Chris AtLee

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

From report at bugs.python.org  Fri Feb  5 11:51:58 2016
From: report at bugs.python.org (Chris AtLee)
Date: Fri, 05 Feb 2016 16:51:58 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1454691118.75.0.721331382558.issue19217@psf.upfronthosting.co.za>


Changes by Chris AtLee <chris.atlee at gmail.com>:


Added file: http://bugs.python.org/file41824/cpython-issue19217.diff

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

From report at bugs.python.org  Fri Feb  5 12:01:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 17:01:35 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454691695.77.0.686746883415.issue21955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

My patches were just samples. I'm glad that Yury incorporated the main idea and that this helps. If apply any patch I would prefer fastint5.patch. But I don't quite understand why it adds any gain. Is this just due to overhead of calling PyNumber_Add? Then we should test with other compilers and with the LTO option. fastint5.patch adds an overhead for type checks and increases the size of ceval loop. What is outweigh this overhead?

As for tests, it would be more honest to test data that results out of small ints range (-5..256).

----------

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

From report at bugs.python.org  Fri Feb  5 12:03:45 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Fri, 05 Feb 2016 17:03:45 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1454691825.81.0.825231260641.issue23551@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

I trying to write the Tk application for the pip package manager. It is in very initial stage, with none of the functionalities implemented yet. I have attached the current state of code written by me. I have also included the wrapper provided by Terri for pip command line. 

Please can someone review my current code , if I am on correct path? If there are some objections to my coding style and the structure of program, please do tell me.

----------
Added file: http://bugs.python.org/file41825/tem_pip_v2.py

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

From report at bugs.python.org  Fri Feb  5 12:04:45 2016
From: report at bugs.python.org (Zach Byrne)
Date: Fri, 05 Feb 2016 17:04:45 +0000
Subject: [issue26280] ceval: Optimize [] operation similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454691885.6.0.274089038593.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

I'm attaching output from a selection of the benchmarks, I'm counting non-builtins and slices, but for everything, not just lists and tuples.

Quick observation: math workloads seem list heavy, text workloads seem dict heavy, and tuples are usually somewhere in the middle.

----------
Added file: http://bugs.python.org/file41826/subscr_stats.txt

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

From report at bugs.python.org  Fri Feb  5 12:17:00 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 17:17:00 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454692620.46.0.253560988178.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks, Serhiy,

> But I don't quite understand why it adds any gain. 

Perhaps, and this is just a guess - the fast path does only couple of eq tests & one call for the actual op.  If it's long+long then long_add will be called directly.

PyNumber_Add has more overhead on:
- at least one extra call
- a few extra checks to guard against NotImplemented
- abstract.c/binary_op1 has a few more checks/slot lookups

So it look that there's just much less instructions to be executed.  If this guess is correct, then an LTO build without fast paths will still be somewhat slower.

> Is this just due to overhead of calling PyNumber_Add? Then we should test with other compilers and with the LTO option.

I actually tried to compile CPython with LTO -- but couldn't.  Almost all of C extension modules failed to link.  Do we compile official binaries with LTO?

----------

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

From report at bugs.python.org  Fri Feb  5 12:18:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 17:18:53 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1454692733.5.0.722759947614.issue24683@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can't reproduce your example paul.

$ ./python eip.py 
Traceback (most recent call last):
  File "eip.py", line 21, in <module>
    e = j.make_encoder(markers, None, enc, 4, "ks", "is", False, True, True)
TypeError: make_encoder() argument 1 must be dict or None, not array.array

----------

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

From report at bugs.python.org  Fri Feb  5 12:34:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 17:34:07 +0000
Subject: [issue26297] Move constant folding to AST level
Message-ID: <1454693647.41.0.887597709812.issue26297@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For using more efficient bytecode (either specialized 8-bit opcodes or 16-bit opcodes) we need to move some optimizations from bytecode level to AST level, since LOAD_CONST variants could have variable size. Now with the Constant node this should be easy.

----------
components: Interpreter Core
messages: 259680
nosy: abarnert, benjamin.peterson, brett.cannon, georg.brandl, haypo, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Move constant folding to AST level
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Feb  5 12:39:15 2016
From: report at bugs.python.org (paul)
Date: Fri, 05 Feb 2016 17:39:15 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1454693955.74.0.00516068502177.issue24683@psf.upfronthosting.co.za>


paul added the comment:

Can you try on 2.7 branch?

----------

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

From report at bugs.python.org  Fri Feb  5 12:43:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 17:43:14 +0000
Subject: [issue26298] Split ceval.c into small files
Message-ID: <1454694194.19.0.667828891375.issue26298@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch splits the huge "switch (opcode)" of ceval.c into smaller ceval_xxx.h files. New files:

   93 Python/ceval_stack.h
  142 Python/ceval_condjump.h
  155 Python/ceval_misc.h
  162 Python/ceval_fast.h
  180 Python/ceval_module.h
  238 Python/ceval_ctx.h
  249 Python/ceval_func.h
  262 Python/ceval_iter.h
  268 Python/ceval_build.h
  384 Python/ceval_number.h

Maybe we can put more files per .h file, maybe less. I don't really care.

It will allow to keep the code readable even with new optimizations like the issue #21955.

What do you think?

----------
files: split_ceval.patch
keywords: patch
messages: 259682
nosy: haypo, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Split ceval.c into small files
versions: Python 3.6
Added file: http://bugs.python.org/file41827/split_ceval.patch

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

From report at bugs.python.org  Fri Feb  5 12:56:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 17:56:58 +0000
Subject: [issue26298] Split ceval.c into small files
In-Reply-To: <1454694194.19.0.667828891375.issue26298@psf.upfronthosting.co.za>
Message-ID: <1454695018.28.0.66052123208.issue26298@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think this will make the code more readable. Rather less readable, since macros are defined in different file than used.

----------

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

From report at bugs.python.org  Fri Feb  5 12:58:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 17:58:46 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1454695125.99.0.200423386435.issue24683@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The same result on 2.7 branch:

$ ./python ../cpython/eip.py 
Traceback (most recent call last):
  File "../cpython/eip.py", line 21, in <module>
    e = j.make_encoder(markers, None, enc, 4, "ks", "is", False, True, True)
TypeError: make_encoder() argument 1 must be dict or None, not str

----------

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

From report at bugs.python.org  Fri Feb  5 13:40:05 2016
From: report at bugs.python.org (Samwyse)
Date: Fri, 05 Feb 2016 18:40:05 +0000
Subject: [issue26299] wsgiref.util FileWrapper raises ValueError: I/O
 operation on closed file.
Message-ID: <1454697605.85.0.988308856795.issue26299@psf.upfronthosting.co.za>


New submission from Samwyse:

While developing, I am using wsgiref.simple_server.  Using to serve static content isn't working.  The attached program demonstrates the issue.  Run it and connect to http://127.0.0.1:8000/.  You will see three buttons.  Clicking on 'wsgi.filewrapper' causes the FileWrapper class found in wsgiref.util to be used, while clicking on 'PEP 0333' uses code suggested in PEP 0333 (https://www.python.org/dev/peps/pep-0333/#id36).  Both of these fail.  Clicking on 'slurp' causes the entire file to loaded and returned in a list.  This works.

When an application returns an instance of environ['wsgi.file_wrapper'], or creates it's own iterator, an error is raised during the initial read of the file.  Reading the entire file and returning a single-element list (the 'slurp' technique) works, but is impractical for larger files.

I've tested this with both Python 2.7.9 and 3.4.3 under Windows 7 (my laptop) and 3.4.3 under Alpine Linux (a Docker instance).

----------
components: Library (Lib)
files: wsgitest.py
messages: 259685
nosy: samwyse
priority: normal
severity: normal
status: open
title: wsgiref.util FileWrapper raises ValueError: I/O operation on closed file.
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41828/wsgitest.py

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

From report at bugs.python.org  Fri Feb  5 14:12:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Feb 2016 19:12:12 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1454699532.97.0.0565558461493.issue22107@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: closed -> open

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

From report at bugs.python.org  Fri Feb  5 14:23:01 2016
From: report at bugs.python.org (Shashank Agarwal)
Date: Fri, 05 Feb 2016 19:23:01 +0000
Subject: [issue26296] colorys rgb_to_hls algorithm error
In-Reply-To: <1454680812.05.0.172060571572.issue26296@psf.upfronthosting.co.za>
Message-ID: <1454700181.67.0.637807725512.issue26296@psf.upfronthosting.co.za>


Shashank Agarwal added the comment:

I would like to work on this..

----------
nosy: +The_Knight

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

From report at bugs.python.org  Fri Feb  5 14:37:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Feb 2016 19:37:45 +0000
Subject: [issue26298] Split ceval.c into small files
In-Reply-To: <1454694194.19.0.667828891375.issue26298@psf.upfronthosting.co.za>
Message-ID: <1454701065.81.0.587311903806.issue26298@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I have a similar worry as Serhiy as I don't know where to find something like GET_AWAITABLE with that organization.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Fri Feb  5 14:41:50 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 05 Feb 2016 19:41:50 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1454701310.44.0.930705634943.issue22107@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Fri Feb  5 15:39:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 20:39:59 +0000
Subject: [issue26287] Core dump in f-string with formatting errors due to
 refcount bug
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <1454704799.41.0.634461880218.issue26287@psf.upfronthosting.co.za>


Martin Panter added the comment:

I have zero experience with with ceval.c but I have a theory after looking over revision 1ddeb2e175df. I suspect ?value? is a borrowed reference from TOP(), but at <https://hg.python.org/cpython/diff/1ddeb2e175df/Python/ceval.c#l1.35> and <https://hg.python.org/cpython/diff/1ddeb2e175df/Python/ceval.c#l1.54> you are calling DECREF on it without calling SET_TOP() if there is an error.

I suspected FORMAT_VALUE, because the crash doesn?t happen when you call format() directly.

----------

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

From report at bugs.python.org  Fri Feb  5 16:01:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Feb 2016 21:01:04 +0000
Subject: [issue26292] Raw I/O writelines() broken
In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>
Message-ID: <1454706064.11.0.135611218852.issue26292@psf.upfronthosting.co.za>


Martin Panter added the comment:

For BufferedIOBase, the documentation says write() will not return a short number of bytes, so I don?t see how writelines() is a problem there. For TextIOBase, the documentation is not so clear <https://docs.python.org/release/3.4.3/library/io.html#io.TextIOBase.write>, but I understand the standard library implementations do not do short writes.

----------

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

From report at bugs.python.org  Fri Feb  5 16:22:27 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 05 Feb 2016 21:22:27 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1454707347.73.0.705766042486.issue25228@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Fri Feb  5 16:25:03 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 05 Feb 2016 21:25:03 +0000
Subject: [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <1454707503.76.0.618066385065.issue26248@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks very much for all that added information!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 17:12:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 22:12:05 +0000
Subject: [issue26297] Move constant folding to AST level
In-Reply-To: <1454693647.41.0.887597709812.issue26297@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbMXDuCFnQjAyHR2u624Q5=1PmMjD8iA0fG8E2MmVda=A@mail.gmail.com>


STINNER Victor added the comment:

*If* the PEP 511 is accepted, it will be super easy to start with an
implementation in pure Python.

But I think that we should benchmark the overhead of the Python API of
PEP 511, because we need to convert all AST internal objects to Python
objects, run the AST optimizer, and then again convert Python objects
to internal AST objects.

For a long running process, the time to compile a .py file doesn't
matter. For a short script, it matters. At least, we need to compile
the script itself.

By the way, would it be insane to *not* optimize the script when
running "python script.py"?

> Now with the Constant node this should be easy.

ast.Constant is *not* emited by the compiler to not break backward
compatibility. I *know* that there is no stable API on AST, but I
noticed some issues when working on my AST project. For example, pip
doesn't work because an internal library uses AST and the code doesn't
handle ast.Constant (it's probably super easy to fix it).

I'm open to change the compiler to emit ast.Constant directly, but
maybe only in "optimized mode" (ex: python -O?). ast.Constant for
tuples and frozensets has a limitation: it doesn't store the location
of items (line number, column offset).

----------

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

From report at bugs.python.org  Fri Feb  5 17:17:44 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Fri, 05 Feb 2016 22:17:44 +0000
Subject: [issue26300] "unpacked" bytecode
Message-ID: <1454710664.23.0.316699327961.issue26300@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

Currently, the compiler starts with a list of arrays of instructions, packs them to 1/3/6-bytes-apiece bytecodes, fixes up all the jumps, and then calls PyCode_Optimize on the result. This makes the peephole optimizer much more complicated. Assuming PEP 511 is accepted, it will also make plug-in bytecode optimizers much more complicated (and probably wasteful--they'll each be repeating the same work to re-do the fixups).

The simplest alternative (as suggested by Serhiy on -ideas) is to expose an "unpacked" bytecode to the optimizer (in the code parameter and return value and lnotab_obj in-out parameter for PyCode_Optimize, and similarly for PEP 511) where each instruction takes a fixed 4 bytes. This is much easier to process. After the optimizer returns, the compiler packs opcodes into the usual 1/3/6-byte format, removing NOPs, retargeting jumps, and adjusting the lnotab as it goes. (Note that it already pretty much has code to do all of this except the NOP removal; it's just doing it before the optimizer instead of after.)

Negatives:

 * Arguments can now only go up to 2**23 instead of 2**31. I don't think that's a problem (has anyone ever created a code object with 4 million instructions?).

 * A bit more work for the compiler; we'd need to test to make sure there's no measurable performance impact.

We could also expose this functionality through C API PyCode_Pack/Unpack and Python dis.pack_code/unpack_code functions (and also make the dis module know how to parse unpacked code), which would allow import hooks, post-processing decorators, etc. to be simplified as well. This would remove some, but not all, of the need for things like byteplay. I think this may be worth doing, but I'm not sure until I see how complicated it is.

We could even allow code objects with unpacked bytecode to be executed, but I think that's unnecessary complexity. Nobody should want to do that intentionally, and if an optimizer lets such code escape by accident, a SystemError is fine.

MRAB implied an alternative: exposing some slightly-higher-level label-based format. That would be even nicer to work with. But it's also more complicated for the compiler and for the API, and I think it's already easy enough to handle jumps with fixed-width instructions.

----------
components: Interpreter Core
messages: 259693
nosy: abarnert, benjamin.peterson, georg.brandl, haypo, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: "unpacked" bytecode
type: enhancement

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

From report at bugs.python.org  Fri Feb  5 17:35:33 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 05 Feb 2016 22:35:33 +0000
Subject: [issue26297] Move constant folding to AST level
In-Reply-To: <1454693647.41.0.887597709812.issue26297@psf.upfronthosting.co.za>
Message-ID: <1454711733.57.0.861174210962.issue26297@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> ast.Constant is *not* emited by the compiler to not break backward
compatibility. I *know* that there is no stable API on AST, but I
noticed some issues when working on my AST project. For example, pip
doesn't work because an internal library uses AST and the code doesn't
handle ast.Constant (it's probably super easy to fix it).

Yeah, it's probably very easy to fix.  And if pip stops working on 3.6-alpha it will be fixed.  We don't give any guarantees on AST backwards compatibility.  In fact, we even tell that the AST might change in every release in the docs "The abstract syntax itself might change with each Python release".


> I'm open to change the compiler to emit ast.Constant directly, but
maybe only in "optimized mode" (ex: python -O?). 

I'm -1 on using -O flag since some people would prefer to have optimizations *and* have their assert statements.

In fact I'm -1 on using any kind of flag to trigger optimizations on or off.  Those flags will only drive confusion.  If the optimizations are any good, people will simply start using the flag all the time.

----------

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

From report at bugs.python.org  Fri Feb  5 17:37:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 22:37:27 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454711847.9.0.736666080255.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy Storchaka: "My patches were just samples. I'm glad that Yury incorporated the main idea and that this helps."

Oh, if even Serhiy prefers Yury's patches, I should read them again :-)

--

I read fastint5.patch one more time and I finally understood the following macros:

+#define NB_SLOT(slot) offsetof(PyNumberMethods, slot)
+#define NB_BINOP(nb_methods, slot) \
+    (*(binaryfunc*)(& ((char*)nb_methods)[NB_SLOT(slot)]))
+#define PY_LONG_CALL_BINOP(slot, left, right) \
+    (NB_BINOP(PyLong_Type.tp_as_number, slot))(left, right)
+#define PY_FLOAT_CALL_BINOP(slot, left, right) \
+    (NB_BINOP(PyFloat_Type.tp_as_number, slot))(left, right)

In short, a+b calls long_add(a, b) with that. At the first read, I understood that it casted objects to C long or C double (don't ask me why).


I see a difference between fastint5.patch and fastintfloat_alt.patch: fastint5.patch resolves the address of long_add() at runtime, whereas fastintfloat_alt.patch gets a direct pointer to _PyLong_Add() at the compilation. I expected a sublte speedup, but I'm unable to see it on benchmarks (again, both patches have the same speed).

The float path is simpler in fastint5.patch because it uses the same code if right is float or long, but it adds more checks for the slow-path. No patch looks to have a real impact on the slow-path. Is it worth to change the second if to PyFloat_CheckExact() and then check type of right in the if body to avoid other checks on the slow-path?

(C checks look very cheap, so I think that I already replied to my own question :-))

--

fastint5.patch optimizes a+b, a-b, a*b, a/b and a//b. Why not other operators? List of operators from my constant folding optimzation in fatoptimizer:

* int, float: a+b, a-b, a*b, a/b, +x, -x, ~x, a//b, a%b, a**b
* int only: a<<b, a>>b, a&b, a|b, a^b

If we optimize a//b, I suggest to also optimize a%b to be consistent. For integers, a**b, a<<b and a>>b would make sense too. Coming from the C language, I would prefer a<<b and a>>b than a*2**k or a//2**k, since I expect better performance.

For float, -x and +x may be common, but less a+b, a-b, a*b, a/b.

Well, what I'm trying to say: if choose fastintfloat_alt.patch design, we will have to expose like a lot of new C functions in headers, and duplicate a lot of code.

To support more than 4 operators, we need a macro.

If we use a macro, it's cheap (in term of code maintenance) to use it for most or even all operators.

--

> But I don't quite understand why it adds any gain. Is this just due to overhead of calling PyNumber_Add?

Hum, that's a good question.


> Then we should test with other compilers and with the LTO option.

There are projects (I don't recall the number number) but I would prefer to handle LTO separatly. Python supports platforms and compilers which don't implement LTO.


> fastint5.patch adds an overhead for type checks and increases the size of ceval loop. What is outweigh this overhead?

I stopped to guess the speedup just by reading the code or a patch. I only trust benchmarks :-)

Advice: don't trust yourself! only trust benchmarks.

----------

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

From report at bugs.python.org  Fri Feb  5 17:40:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 22:40:22 +0000
Subject: [issue26297] Move constant folding to AST level
In-Reply-To: <1454711733.57.0.861174210962.issue26297@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaxbASzwmRGAHLVtVu__vc3hDQnqw7g0M5a0bnpo8wn1g@mail.gmail.com>


STINNER Victor added the comment:

Yury Selivanov added the comment:
> In fact I'm -1 on using any kind of flag to trigger optimizations on or off.  Those flags will only drive confusion.  If the optimizations are any good, people will simply start using the flag all the time.

Yeah, Guido calls this a missed optimization opportunity.

My only concern is:

> ast.Constant for tuples and frozensets has a limitation: it doesn't store the location of items (line number, column offset).

Is it a problem in practice? I didn't have time to investigate this.

Since the PEP 511 is still under discussion, I prefer to focus on the
PEP itself than this specific implementation detail ;-)

----------

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

From report at bugs.python.org  Fri Feb  5 17:41:15 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 05 Feb 2016 22:41:15 +0000
Subject: [issue26287] Core dump in f-string with formatting errors due to
 refcount bug
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <1454712075.98.0.88484981632.issue26287@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Yes, that's my thinking as well. I'll have a patch soon-ish.

----------

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

From report at bugs.python.org  Fri Feb  5 17:55:04 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 05 Feb 2016 22:55:04 +0000
Subject: [issue26287] Core dump in f-string with formatting errors
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <1454712904.21.0.612929143697.issue26287@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Now I think it's not a refcount problem.

I'm going to switch to POP/PUSH instead of TOP/SET_TOP. I believe the problem is that I'm not adjusting the top of stack if there's an error.

----------
title: Core dump in f-string with formatting errors due to refcount bug -> Core dump in f-string with formatting errors

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

From report at bugs.python.org  Fri Feb  5 18:01:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Feb 2016 23:01:49 +0000
Subject: [issue26297] Move constant folding to AST level
In-Reply-To: <1454693647.41.0.887597709812.issue26297@psf.upfronthosting.co.za>
Message-ID: <1454713309.82.0.581776882782.issue26297@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> we need to move some optimizations from bytecode level to AST level

You may be aware that there is a long list of similar (old) issues proposing something similar:
https://www.python.org/dev/peps/pep-0511/#usage-1-ast-optimizer

My PEP 511 tries to propose a generic API to support all proposed optimizations.

--

I didn't try yet to do something like importlib to compile an AST optimizer written in Python into a frozen module and then use it in Python. It would allow to implement an AST optimizer in pure Python to ease its maintenance *and* have it builtin into CPython, rather than having to play with AST in C (less fun).

My plan for the PEP 511 is more to start to experiment multiple AST optimizers and bytecode optimizers outside CPython, wait until the code becomes more stable, and later discuss if one optimizer deserves to become part of Python stdlib.

"Writing an optimizer or a preprocessor is out of the scope of this PEP."

--

But maybe you would prefer to have a single and simple AST optimizer builtin Python without new additional API?

I don't want to block your effort on experimentation :-) I just see a nice opportunity to sell you the PEP 511 ;-)

----------

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

From report at bugs.python.org  Fri Feb  5 18:23:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Feb 2016 23:23:15 +0000
Subject: [issue26287] Core dump in f-string with formatting errors
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <20160205232312.40074.27471@psf.io>


Roundup Robot added the comment:

New changeset 9095a5787a82 by Eric V. Smith in branch 'default':
Fix issue 26287: While handling FORMAT_VALUE opcode, the top of stack was being corrupted if an error occurred in PyObject_Format().
https://hg.python.org/cpython/rev/9095a5787a82

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  5 18:24:01 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 05 Feb 2016 23:24:01 +0000
Subject: [issue26287] Core dump in f-string with formatting errors
In-Reply-To: <1454635285.76.0.309799685579.issue26287@psf.upfronthosting.co.za>
Message-ID: <1454714641.44.0.0944601139162.issue26287@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Thanks for the report and the debugging help.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 19:10:27 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 00:10:27 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454717427.82.0.669811047653.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attached is the new version of fastint5 patch.  I fixed most of the review comments.  I also optimized %, << and >> operators.  I didn't optimize other operators because they are less common.  I guess we have to draw a line somwhere...

Victor, thanks a lot for your suggestion to drop NB_SLOT etc macros!  Without them the code is even simpler.

----------
Added file: http://bugs.python.org/file41829/fastint5_2.patch

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

From report at bugs.python.org  Fri Feb  5 19:40:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Feb 2016 00:40:10 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <20160206004005.68410.92717@psf.io>


Roundup Robot added the comment:

New changeset 986184c355e8 by Yury Selivanov in branch 'default':
Issue #26288: Optimize PyLong_AsDouble.
https://hg.python.org/cpython/rev/986184c355e8

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  5 19:40:58 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 00:40:58 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454719258.95.0.709484739057.issue26288@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks a lot for the review, Serhiy!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> performance

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

From report at bugs.python.org  Fri Feb  5 19:45:07 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 00:45:07 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454719507.81.0.0566245638087.issue21955@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file41830/fastint5_3.patch

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

From report at bugs.python.org  Fri Feb  5 19:59:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 00:59:30 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1454720370.77.0.851052453687.issue10044@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Issue #21955 is a spin-off of this issue.

----------

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

From report at bugs.python.org  Fri Feb  5 20:29:55 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 01:29:55 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454722195.71.0.693994581552.issue21955@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file41831/fastint5_4.patch

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

From report at bugs.python.org  Fri Feb  5 20:31:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:31:57 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454722317.71.0.39458019109.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

inline-2.patch: more complete version of inline.patch.

Optimize the same instructions than Python 2: BINARY_ADD, INPLACE_ADD, BINARY_SUBSTRACT, INPLACE_SUBSTRACT.


Quick & *dirty* microbenchmark:

$ ./python -m timeit -s 'x=1' 'x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x'

* Original: 287 ns
* fastint5_2.patch: 261 ns (-9%)
* inline-2.patch: 212 ns (-26%)


$ ./python -m timeit -s 'x=1000; y=1' 'x-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y'

* Original: 517 ns
* fastint5_2.patch: 469 ns (-9%)
* inline-2.patch: 442 ns (-15%)


Ok. Now I'm lost. We have so many patches :-) Which one do you prefer?

In term of speedup, I expect that Python 2 design (inline-2.patch) cannot be beaten in term of performance by another another option since it doesn't need any C code and does everything in ceval.c.

----------
Added file: http://bugs.python.org/file41832/inline-2.patch

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

From report at bugs.python.org  Fri Feb  5 20:36:45 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 01:36:45 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454722605.08.0.400552138671.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Ok. Now I'm lost. We have so many patches :-) Which one do you prefer?

To no-ones surprise I prefer fastint5, because it optimizes almost all binary operators on both ints and floats.

inline-2.patch only optimizes just + and - for just ints.  If + and - performance of inline-2 is really important, I suggest to merge it in fastint5, but i'd keep it simple ;)

----------

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

From report at bugs.python.org  Fri Feb  5 20:40:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:40:39 +0000
Subject: [issue26301] ceval.c: reintroduce fast-path for list[index] in
 BINARY_SUBSCR
Message-ID: <1454722839.37.0.315889112887.issue26301@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Copy of msg222985 by Raymond Hettinger from issue #21955:

"There also used to be a fast path for binary subscriptions with integer indexes.  I would like to see that performance regression fixed if it can be done cleanly."

----------
messages: 259708
nosy: haypo, rhettinger, yselivanov
priority: normal
severity: normal
status: open
title: ceval.c: reintroduce fast-path for list[index] in BINARY_SUBSCR
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Fri Feb  5 20:43:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:43:55 +0000
Subject: [issue26301] ceval.c: reintroduce fast-path for list[index] in
 BINARY_SUBSCR
In-Reply-To: <1454722839.37.0.315889112887.issue26301@psf.upfronthosting.co.za>
Message-ID: <1454723035.28.0.901369312422.issue26301@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file41833/binary_subscr.patch

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

From report at bugs.python.org  Fri Feb  5 20:47:29 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 01:47:29 +0000
Subject: [issue26301] ceval.c: reintroduce fast-path for list[index] in
 BINARY_SUBSCR
In-Reply-To: <1454722839.37.0.315889112887.issue26301@psf.upfronthosting.co.za>
Message-ID: <1454723249.25.0.394945976363.issue26301@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I think this is a duplicate of http://bugs.python.org/issue26280...

----------

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

From report at bugs.python.org  Fri Feb  5 20:49:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:49:13 +0000
Subject: [issue26301] ceval.c: reintroduce fast-path for list[index] in
 BINARY_SUBSCR
In-Reply-To: <1454722839.37.0.315889112887.issue26301@psf.upfronthosting.co.za>
Message-ID: <1454723353.52.0.189269572626.issue26301@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Oops, I attached the wrong patch, fixed in patch v2.)

Quick & dirty micro-benchmark:

Original:

$ ./python -m timeit -s 'lst=list("hello")' 'lst[2]'
10000000 loops, best of 3: 0.0261 usec per loop

Patched:

$ ./python -m timeit -s 'lst=list("hello")' 'lst[2]'
10000000 loops, best of 3: 0.0186 usec per loop

----------
Added file: http://bugs.python.org/file41834/binary_subscr-2.patch

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

From report at bugs.python.org  Fri Feb  5 20:49:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:49:19 +0000
Subject: [issue26301] ceval.c: reintroduce fast-path for list[index] in
 BINARY_SUBSCR
In-Reply-To: <1454722839.37.0.315889112887.issue26301@psf.upfronthosting.co.za>
Message-ID: <1454723359.22.0.0860351617696.issue26301@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file41833/binary_subscr.patch

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

From report at bugs.python.org  Fri Feb  5 20:51:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:51:03 +0000
Subject: [issue26280] ceval: Optimize list[int] (subscript) operation
 similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454723463.45.0.298118561616.issue26280@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: ceval: Optimize [] operation similarly to CPython 2.7 -> ceval: Optimize list[int] (subscript) operation similarly to CPython 2.7

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

From report at bugs.python.org  Fri Feb  5 20:51:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:51:49 +0000
Subject: [issue26280] ceval: Optimize list[int] (subscript) operation
 similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1454723509.88.0.483787168328.issue26280@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I just created a duplicate with a patch for list[int]: issue #26301.

----------

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

From report at bugs.python.org  Fri Feb  5 20:52:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 01:52:51 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454723571.8.0.882114170319.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

msg222985: Raymond Hettinger
"There also used to be a fast path for binary subscriptions with integer indexes.  I would like to see that performance regression fixed if it can be done cleanly."

The issue #26280 was opened to track this optimization.

----------

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

From report at bugs.python.org  Fri Feb  5 21:12:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 02:12:02 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454724722.33.0.790032317481.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

msg223186, Serhiy Storchaka about inline.patch: "Confirmed speed up about 20%. Surprisingly it affects even integers outside of the of preallocated small integers (-5...255)."

The optimization applies to Python int with 0 or 1 digit so in range [-2^30+1; 2^30-1].

Small integers in [-5; 255] might be faster but for PyLong_FromLong().

----------

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

From report at bugs.python.org  Fri Feb  5 21:22:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 02:22:08 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454725328.45.0.846399253301.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

myself> Ok. Now I'm lost. We have so many patches :-) Which one do you prefer?

I read again fully this *old* issue, well, *almost* all messages.

Well, it's clear that no consensus was found yet :-) I see two main trends: optimize most cases (optimize most operators for int and float,  ex: fastint5_4.patch) versus optimize very few cases to limit changes and to limit effects on ceval.c (ex: inline-2.patch).

Marc-Andre and Antoine asked to not stick to micro-optimizations but think wider: run macro benchmarks, like perf.py, and suggest to use PyPy, Numba, Cython & cie for users who use best performances on numeric functions.

They also warned about subtle side-effects of any kind of change on ceval.c which may be counter-productive. It was shown in the long list of patches that some of them introduced performance *regressions*.

I don't expect that CPython can beat any compiler emiting machine code. CPython will always have to pay the price of boxing/unboxing and its loop evaluating bytecode. We can do *better*, the question is "how far?".

I think that we gone far enough on investigation *all* different options to optimize 1+2 ;-) Each option was micro-benchmarked very carefully.

Now I suggest to focus on *macro* benchmarks to help use to take a decision. I will run perf.py on fastint5_4.patch and inline-2.patch.

----------

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

From report at bugs.python.org  Fri Feb  5 21:24:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 02:24:52 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454725492.08.0.730272440248.issue26288@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Nice enhancement.

/* Fast path; single digit will always fit decimal.
   This improves performance of FP/long operations by at
   least 20%. This is even visible on macro-benchmarks.
*/

I'm not sure that "spectral_norm" can be qualified as macro-benchmark. It's more a microbenchmark on numerics, no? I'm just nitpicking, your patch is fine ;-)

----------

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

From report at bugs.python.org  Fri Feb  5 21:26:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 02:26:07 +0000
Subject: [issue26301] ceval.c: reintroduce fast-path for list[index] in
 BINARY_SUBSCR
In-Reply-To: <1454722839.37.0.315889112887.issue26301@psf.upfronthosting.co.za>
Message-ID: <1454725567.45.0.76992513323.issue26301@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I think this is a duplicate of http://bugs.python.org/issue26280...

Oh, I missed this one. I didn't understand "[]" in the title. I didn't understand the purpose of optimizing BUILD_LIST :-D

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> ceval: Optimize list[int] (subscript) operation similarly to CPython 2.7

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

From report at bugs.python.org  Fri Feb  5 22:13:56 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Feb 2016 03:13:56 +0000
Subject: [issue26240] Docstring of the subprocess module should be cleaned up
In-Reply-To: <1454131083.41.0.870668221205.issue26240@psf.upfronthosting.co.za>
Message-ID: <1454728436.23.0.489366758604.issue26240@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree. The module docstring should briefly describe the module and maybe list the contents, a line for each.  The itertools docstring does the latter; the math docstring does not, though I would not mind if it did.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Feb  6 00:09:22 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Feb 2016 05:09:22 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1454735362.57.0.0971755576823.issue21159@psf.upfronthosting.co.za>


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


----------
resolution: fixed -> 
stage: resolved -> needs patch

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

From report at bugs.python.org  Sat Feb  6 00:18:50 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Feb 2016 05:18:50 +0000
Subject: [issue26302] cookies module allows commas in keys
Message-ID: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Commas aren't legal characters in cookie keys, yet in Python 3.5, they're allowed:

>>> bool(http.cookies._is_legal_key(','))
True

The issue lies in the use of _LegalChars constructing a regular expression.

"Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems."

The issue arises in this line:

_is_legal_key = re.compile('[%s]+' % _LegalChars).fullmatch

Which was added in 88e1151e8e0242 referencing issue2211.

The problem is that in a regular expression, and in a character class in particular, the '-' character has a special meaning if not the first character in the class, which is "span all characters between the leading and following characters". As a result, the pattern has the unintended effect of including the comma in the pattern:

>>> http.cookies._is_legal_key.__self__
re.compile("[abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-.^_`|~:]+")
>>> pattern = _
>>> pattern.fullmatch(',')
<_sre.SRE_Match object; span=(0, 1), match=','>
>>> ord('+')
43
>>> ord('.')
46
>>> ''.join(map(chr, range(43,47)))
'+,-.'

That's how the comma creeped in.

This issue is the underlying cause of https://bitbucket.org/cherrypy/cherrypy/issues/1405/testcookies-fails-on-python-35 and possible other cookie-related bugs in Python.

While I jest about regular expressions, I like the implementation. It just needs to account for the extraneous comma, perhaps by escaping the dash:

_is_legal_key = re.compile('[%s]+' % _LegalChars.replace('-', '\\-')).fullmatch

Also, regression tests for keys containing invalid characters should be added as well.

----------
keywords: 3.5regression
messages: 259718
nosy: jason.coombs, serhiy.storchaka
priority: normal
severity: normal
status: open
title: cookies module allows commas in keys
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Feb  6 02:10:47 2016
From: report at bugs.python.org (paul)
Date: Sat, 06 Feb 2016 07:10:47 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1454742647.16.0.971559770287.issue24683@psf.upfronthosting.co.za>


paul added the comment:

Sorry, I wasn't clear enough. This POC is a proof that the original bug can be used for EIP control. I just checked and it works as advertised on 2.7 revision: https://hg.python.org/cpython/rev/2d39777f3477 - it's a parent of https://hg.python.org/cpython/rev/0a1266ef1b5d containing the patch for this issue. I added this file, because I submitted a bug on hackerone claiming EIP control.

----------

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

From report at bugs.python.org  Sat Feb  6 02:58:28 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Sat, 06 Feb 2016 07:58:28 +0000
Subject: [issue26300] "unpacked" bytecode
In-Reply-To: <1454710664.23.0.316699327961.issue26300@psf.upfronthosting.co.za>
Message-ID: <1454745508.51.0.972115666392.issue26300@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

Reading more about wpython (slide 23 of https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/wpython2/Cleanup%20and%20new%20optimizations%20in%20WPython%201.1.pdf), one of his optimizations was moving the peephole optimizer into the compiler, so it could just use the linked list of block objects of arrays of instruction objects, instead of raw bytecode.

Obviously that idea isn't compatible with PEP 511. But on the off chance that PEP 511 founders, that might be the simplest answer to this problem.

----------

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

From report at bugs.python.org  Sat Feb  6 03:35:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Feb 2016 08:35:47 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454747747.07.0.718390405318.issue26302@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, how can I missed this catch?

The simplest way is just move "-" to the start or the end of character list. The most error-proof way is to use re.escape().

----------
components: +Library (Lib)
keywords: +easy -3.5regression
nosy: +demian.brecht
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Sat Feb  6 03:36:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Feb 2016 08:36:07 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454747767.61.0.130278706814.issue26302@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +3.5regression

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

From report at bugs.python.org  Sat Feb  6 03:37:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Feb 2016 08:37:30 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454747850.83.0.335129209967.issue21955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I see two main trends: optimize most cases (optimize most operators for int and float,  ex: fastint5_4.patch) versus optimize very few cases to limit changes and to limit effects on ceval.c (ex: inline-2.patch).

I agree that may be optimizing very few cases is better. We need to collect the statistics of using different operations with different types in long run of tests or benchmarks. If say division is used 100 times less than addition, we shouldn't complicate ceval loop to optimize it.

----------

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

From report at bugs.python.org  Sat Feb  6 04:04:38 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 06 Feb 2016 09:04:38 +0000
Subject: [issue21573] Clean up turtle.py code formatting
In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za>
Message-ID: <1454749478.03.0.47312603928.issue21573@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Sat Feb  6 05:57:17 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Feb 2016 10:57:17 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454756237.54.0.964034798075.issue26288@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Actually, please fix the comment. We don't want someone wondering what those "macro-benchmarks" are.

----------
assignee:  -> yselivanov
status: closed -> open

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

From report at bugs.python.org  Sat Feb  6 06:23:54 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 06 Feb 2016 11:23:54 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454757834.07.0.966588734719.issue26288@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Additionally, "single digit will always fit a double"?

----------
nosy: +skrah

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

From report at bugs.python.org  Sat Feb  6 07:06:09 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Sat, 06 Feb 2016 12:06:09 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1454760369.07.0.2183061528.issue21042@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

Added a new patch, as Martin pointed out, I put back the ABI matching. The regex looks quite ugly, because it has to match \n\t. To be exact, it has to match something like this: "/lib/x86_64-linux-gnu/libc.so.6\n\tlibbz2.so.1.0 (libc6,x86-64)".

I updated the docs, although I don't know what should I write for the version, please someone help me with that.

For testing, there's a test function in this module, I updated that.

----------
Added file: http://bugs.python.org/file41835/find_lib_v1.patch

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

From report at bugs.python.org  Sat Feb  6 07:19:54 2016
From: report at bugs.python.org (Kunal Grover)
Date: Sat, 06 Feb 2016 12:19:54 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454761194.12.0.605956058996.issue26302@psf.upfronthosting.co.za>


Kunal Grover added the comment:

Hi, I am a newcomer here, I am interested to work on this issue.

----------
nosy: +Kunal Grover

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

From report at bugs.python.org  Sat Feb  6 07:51:30 2016
From: report at bugs.python.org (Lorenzo Ancora)
Date: Sat, 06 Feb 2016 12:51:30 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454763090.17.0.868466804463.issue26209@psf.upfronthosting.co.za>


Lorenzo Ancora added the comment:

(msg259475) Terry J. Reedy thank you for the correction, I've confused the versions affected with the versions actually supported.
Since this doesn't only affect the documentation, is it correct to assign the issue to docs at python?
The expert index indicates giampaolo.rodola as the module maintainer, so he should be moved from the nosy list to the field "Assigned To" and docs at python should be in the nosy list.

Also, there is a documentation on how to send a patch for a specific module in Python 3.5?
I'd like to help by creating a new source code patch. :-)

----------

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

From report at bugs.python.org  Sat Feb  6 09:21:38 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Sat, 06 Feb 2016 14:21:38 +0000
Subject: [issue20109] TestProgram is mentioned in the unittest docs but is not
 documented
In-Reply-To: <1388685707.72.0.688331916968.issue20109@psf.upfronthosting.co.za>
Message-ID: <1454768498.62.0.596272045299.issue20109@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

I think TestProgram should be anonymous, all the work is done in its constructor. I don't see why would anyone would call its functions. I can update the docs if it's needed.

----------
nosy: +beng94

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

From report at bugs.python.org  Sat Feb  6 10:47:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 15:47:45 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454773665.49.0.0248119096871.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Benchmark on inline-2.patch. No speedup, only slowdown.

I'm now running benchmark on fastint5_4.patch.

$ python3 -u perf.py --affinity=2-3,6-7 --rigorous ../default/python.orig ../default/python.inline-2

Report on Linux smithers 4.3.4-300.fc23.x86_64 #1 SMP Mon Jan 25 13:39:23 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### json_load ###
Min: 0.707290 -> 0.723411: 1.02x slower
Avg: 0.707845 -> 0.724238: 1.02x slower
Significant (t=-297.25)
Stddev: 0.00026 -> 0.00049: 1.8696x larger

### regex_v8 ###
Min: 0.066663 -> 0.070435: 1.06x slower
Avg: 0.066947 -> 0.071378: 1.07x slower
Significant (t=-17.98)
Stddev: 0.00172 -> 0.00177: 1.0313x larger

The following not significant results are hidden, use -v to show them:
2to3, chameleon_v2, django_v3, fastpickle, fastunpickle, json_dump_v2, nbody, tornado_http.

real    58m32.662s
user    57m43.058s
sys     0m47.428s

----------

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

From report at bugs.python.org  Sat Feb  6 10:49:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Feb 2016 15:49:02 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454773742.32.0.420419630582.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Benchmark on fastint5_4.patch.

python3 -u perf.py --affinity=2-3,6-7 --rigorous ../default/python.orig ../default/python_fastint5_4

Report on Linux smithers 4.3.4-300.fc23.x86_64 #1 SMP Mon Jan 25 13:39:23 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### django_v3 ###
Min: 0.563959 -> 0.578181: 1.03x slower
Avg: 0.565383 -> 0.579137: 1.02x slower
Significant (t=-152.48)
Stddev: 0.00075 -> 0.00050: 1.4900x smaller

### fastunpickle ###
Min: 0.551076 -> 0.563469: 1.02x slower
Avg: 0.555481 -> 0.567028: 1.02x slower
Significant (t=-27.05)
Stddev: 0.00278 -> 0.00324: 1.1687x larger

### json_dump_v2 ###
Min: 2.737429 -> 2.662615: 1.03x faster
Avg: 2.754239 -> 2.685404: 1.03x faster
Significant (t=55.63)
Stddev: 0.00610 -> 0.01077: 1.7662x larger

### nbody ###
Min: 0.228548 -> 0.212292: 1.08x faster
Avg: 0.230082 -> 0.213574: 1.08x faster
Significant (t=73.74)
Stddev: 0.00175 -> 0.00139: 1.2567x smaller

### regex_v8 ###
Min: 0.041323 -> 0.048099: 1.16x slower
Avg: 0.041624 -> 0.049318: 1.18x slower
Significant (t=-45.38)
Stddev: 0.00123 -> 0.00116: 1.0613x smaller

The following not significant results are hidden, use -v to show them:
2to3, chameleon_v2, fastpickle, json_load, tornado_http.

----------

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

From report at bugs.python.org  Sat Feb  6 10:54:22 2016
From: report at bugs.python.org (kernc)
Date: Sat, 06 Feb 2016 15:54:22 +0000
Subject: [issue26303] Shared execution context between doctests in a module
Message-ID: <1454774062.04.0.526927951264.issue26303@psf.upfronthosting.co.za>


New submission from kernc:

The doctest execution context documentation [0] says the tests get shallow *copies* of module's globals, so one test can't mingle with results of another. This makes it impossible to make literate modules such as:


    """
    This module is about reusable doctests context.

    Examples
    --------
    Let's prepare something the later examples can work with:

    >>> import foo
    >>> result = foo.Something()
    2
    
    """
    class Bar:
        """
        Class about something.

        >>> bar = Bar(foo)
        >>> bar.uses(foo)
        True
        
        """
        def baz(self):
            """
            Returns 3.

            >>> result + bar.baz()
            5
            
            """
            return 3


I.e. one has to instantiate everything in every single test. The documentation says one can pass their own globals as `glob=your_dict`, but it doesn't mention the dict is *cleared* after the test run.

Please acknowledge the use case of doctests in a module sharing their environment and results sometimes legitimately exists, and to make it future-compatible, please amend the final paragraph of the relevant part of documentation [0] like so:


    You can force use of your own dict as the execution context by 
    passing `globs=your_dict` to `testmod()` or `testfile()` instead, 
    e.g., to have all doctests in a module use the _same_ execution
    context (sharing variables), define a context like so:
    
        class Context(dict):
            def copy(self):
                return self
            def clear(self):
                pass
    
    and use it, optionally prepopulated with `M`'s globals:
    
        doctest.testmod(module,
                        glob=Context(module.__dict__.copy()))


Thank you!


[0]: https://docs.python.org/3/library/doctest.html#what-s-the-execution-context

----------
assignee: docs at python
components: Documentation
messages: 259731
nosy: docs at python, kernc
priority: normal
severity: normal
status: open
title: Shared execution context between doctests in a module
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Feb  6 11:16:50 2016
From: report at bugs.python.org (kernc)
Date: Sat, 06 Feb 2016 16:16:50 +0000
Subject: [issue26303] Shared execution context between doctests in a module
In-Reply-To: <1454774062.04.0.526927951264.issue26303@psf.upfronthosting.co.za>
Message-ID: <1454775410.48.0.717673977371.issue26303@psf.upfronthosting.co.za>


kernc added the comment:

The use case is not unpopular [1] and with unambiguous examples like

    >>> arr = np.arange(5)
    >>> my_sum(arr)
    10

(i.e., without importing numpy as np everywhere), it also makes a lot of sense.


[1]: http://stackoverflow.com/questions/13106118/object-reuse-in-python-doctest/35242443

----------

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

From report at bugs.python.org  Sat Feb  6 11:37:57 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 06 Feb 2016 16:37:57 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454776677.06.0.770141029819.issue26302@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

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

From report at bugs.python.org  Sat Feb  6 12:00:25 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 17:00:25 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454778025.4.0.471166899491.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> ### regex_v8 ###
> Min: 0.041323 -> 0.048099: 1.16x slower
> Avg: 0.041624 -> 0.049318: 1.18x slower

I think this is a random fluctuation, that benchmark (and re lib) doesn't use the operators too much.  It can't be THAT slower just because of optimizing a few binops.

----------

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

From report at bugs.python.org  Sat Feb  6 12:02:55 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 17:02:55 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454778175.35.0.0564774426356.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

You're also running a very small subset of all benchmarks available. Please try the '-b all' option.  I'll also run benchmarks on my machines.

----------

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

From report at bugs.python.org  Sat Feb  6 12:06:32 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 06 Feb 2016 17:06:32 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454778392.87.0.247673255176.issue26136@psf.upfronthosting.co.za>


Anish Shah added the comment:

@martin.panter Any reviews for the patch? Is it ready to merge?

----------

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

From report at bugs.python.org  Sat Feb  6 12:07:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 17:07:13 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454778433.13.0.0909404348152.issue26288@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Actually, please fix the comment. We don't want someone wondering what those "macro-benchmarks" are.

If spectral-norm and nbody aren't good benchmarks then let's remove them from our benchmarks suite.

I'll remove that comment anyways, as it doesn't make a lot of sense :)

> Additionally, "single digit will always fit a double"?

What's wrong about that phrase?  Would this be better: "It's safe to cast a single-digit long (31 bits) to double"?

----------

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

From report at bugs.python.org  Sat Feb  6 12:12:32 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 06 Feb 2016 17:12:32 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454778752.42.0.562408113848.issue26288@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sat Feb  6 12:18:07 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 06 Feb 2016 17:18:07 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454779087.75.0.82164587902.issue26288@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Sorry, I was a bit brief: The current comment says "decimal" instead of "double". It should be changed to "double".

----------

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

From report at bugs.python.org  Sat Feb  6 12:18:17 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Feb 2016 17:18:17 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454778433.13.0.0909404348152.issue26288@psf.upfronthosting.co.za>
Message-ID: <56B62AD6.8020707@free.fr>


Antoine Pitrou added the comment:

Le 06/02/2016 18:07, Yury Selivanov a ?crit :
> 
>> Actually, please fix the comment. We don't want someone wondering what those "macro-benchmarks" are.
> 
> If spectral-norm and nbody aren't good benchmarks then let's remove
> them from our benchmarks suite.

Probably, yes.

----------

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

From report at bugs.python.org  Sat Feb  6 12:19:26 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Feb 2016 17:19:26 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <56B62AD6.8020707@free.fr>
Message-ID: <56B62B1C.3020902@free.fr>


Antoine Pitrou added the comment:

Actually, let me refine that. nbody and spectral-norm don't make sense
for people running CPython. Perhaps people running PyPy might care about
their performance... (though PyPy is supposed to support a subset of
Numpy too)

----------

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

From report at bugs.python.org  Sat Feb  6 12:21:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Feb 2016 17:21:35 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <20160206172132.11215.4117@psf.io>


Roundup Robot added the comment:

New changeset cfb77ccdc23a by Yury Selivanov in branch 'default':
Issue #26288: Fix comment
https://hg.python.org/cpython/rev/cfb77ccdc23a

----------

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

From report at bugs.python.org  Sat Feb  6 12:23:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 17:23:13 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454779393.56.0.552385283617.issue26288@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Sorry, I was a bit brief: The current comment says "decimal" instead of "double". It should be changed to "double".

Oh, got it now, sorry.  I rephrased the comment a bit, hopefully it's better now.  Please check.  Thanks!

----------

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

From report at bugs.python.org  Sat Feb  6 12:33:15 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 06 Feb 2016 17:33:15 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454779995.95.0.654074425128.issue26302@psf.upfronthosting.co.za>


Anish Shah added the comment:

We just need to use '\-' instead of '-'.

```
>>> regex = re.compile("[a-z]")
>>> bool(regex.match('b'))
True
>>> regex = re.compile("[a\-z]")
>>> bool(regex.match('b'))
False
```

I have uploaded a patch.
Let me know if this needs some tests too?

----------
keywords: +patch
Added file: http://bugs.python.org/file41836/issue26302_20160206.patch

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

From report at bugs.python.org  Sat Feb  6 12:38:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 06 Feb 2016 17:38:21 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454780300.98.0.418760531877.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Alright, I ran a few benchmarks myself.  In rigorous mode regex_v8 has the same performance on my 2013 Macbook Pro and an 8-years old i7 CPU (Linux).

Here're results of "perf.py -b raytrace,spectral_norm,meteor_contest,nbody ../cpython/python.exe ../cpython-git/python.exe -r"


fastint5:

### nbody ###
Min: 0.227683 -> 0.197046: 1.16x faster
Avg: 0.229366 -> 0.198889: 1.15x faster
Significant (t=137.31)
Stddev: 0.00170 -> 0.00142: 1.1977x smaller

### spectral_norm ###
Min: 0.296840 -> 0.262279: 1.13x faster
Avg: 0.299616 -> 0.265387: 1.13x faster
Significant (t=74.52)
Stddev: 0.00331 -> 0.00319: 1.0382x smaller

The following not significant results are hidden, use -v to show them:
meteor_contest, raytrace.


======


inline-2:


### raytrace ###
Min: 1.188825 -> 1.213788: 1.02x slower
Avg: 1.199827 -> 1.227276: 1.02x slower
Significant (t=-18.12)
Stddev: 0.00559 -> 0.01408: 2.5184x larger

### spectral_norm ###
Min: 0.296535 -> 0.277025: 1.07x faster
Avg: 0.299044 -> 0.278071: 1.08x faster
Significant (t=87.40)
Stddev: 0.00220 -> 0.00097: 2.2684x smaller

The following not significant results are hidden, use -v to show them:
meteor_contest, nbody.

----------

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

From report at bugs.python.org  Sat Feb  6 12:45:52 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Feb 2016 17:45:52 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454780752.03.0.251759068487.issue26302@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

A test would be much appreciated. It's worthwhile capturing the rejection of at least one invalid character, if not several common ones.

----------

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

From report at bugs.python.org  Sat Feb  6 12:54:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Feb 2016 17:54:52 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454781292.13.0.362083865608.issue26302@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, _LegalChars shouldn't include "\".

----------

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

From report at bugs.python.org  Sat Feb  6 13:09:03 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 06 Feb 2016 18:09:03 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454782143.33.0.283174389992.issue26302@psf.upfronthosting.co.za>


Anish Shah added the comment:

@serhiy.storchaka OK, I have used re.escape instead of '\'. And I have added a test too.

Also, may I know why '\' can not be in _LegalChars, so that I can remember this for future purpose?

----------
Added file: http://bugs.python.org/file41837/issue26302_20160206-2.patch

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

From report at bugs.python.org  Sat Feb  6 13:41:49 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Feb 2016 18:41:49 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454784109.83.0.101627766824.issue26209@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Code patches should not be assigned to 'docs'.  But Berker, for the reason stated, thinks this should be doc only.  Giampaolo is not currently active, so should not be assigned the issue by anyone else.

After making a patch -- see the devguide -- use the File: Browse button to upload a file.  You can suggest a specific doc change in a message, without a .patch or .diff file.

----------

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

From report at bugs.python.org  Sat Feb  6 13:45:22 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Feb 2016 18:45:22 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454784322.06.0.587624850573.issue26209@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Note that the proposed code change would be a 3.6 only enhancement.  Adding the other versions was part of changing to a doc-only issue.  Note also that if the module is not deprecated, then a 3.6 code change could be considered.  But only a doc change for now.

----------
dependencies: +Deprecate smtpd (based on deprecated asyncore/asynchat): write a new smtp server with asyncio

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

From report at bugs.python.org  Sat Feb  6 14:04:53 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 06 Feb 2016 19:04:53 +0000
Subject: [issue26300] "unpacked" bytecode
In-Reply-To: <1454710664.23.0.316699327961.issue26300@psf.upfronthosting.co.za>
Message-ID: <1454785493.74.0.796591443611.issue26300@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sat Feb  6 14:12:02 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Feb 2016 19:12:02 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1454785922.59.0.495505721289.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On idle-dev, Beni Cherniavsky-Paskin suggested that easily installing into a virtualenv would be a useful option, especially in semi-locked down education setting.  I probably agree, as a follow-on feature, but am barely familiar with venvs.

----------

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

From report at bugs.python.org  Sat Feb  6 15:24:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Feb 2016 20:24:48 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454790288.64.0.0551095174746.issue26302@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

_LegalChars contained only characters which don't require quoting, as documented in the comment above. If _LegalChars was only used to create _is_legal_key, we would just wrote the regular expression. But it is used also in other places. In this particular case adding "\" to _LegalChars doesn't lead to visible bug (except inconsistency with the comment), but we can't be sure.

_is_legal_key() is implementation detail. It would be better to test public API.

----------

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

From report at bugs.python.org  Sat Feb  6 15:32:35 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 06 Feb 2016 20:32:35 +0000
Subject: [issue26250] no document for sqlite3.Cursor.connection
In-Reply-To: <1454262712.53.0.251399487214.issue26250@psf.upfronthosting.co.za>
Message-ID: <1454790755.47.0.346627252556.issue26250@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Added patch with my suggestion for sqlite3.Cursor.connection attribute documentation

----------
assignee:  -> docs at python
components: +Documentation, Extension Modules -Library (Lib)
keywords: +patch
nosy: +docs at python, ghaering, palaviv
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41838/sqlite3-cursor-connection-doc.patch

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

From report at bugs.python.org  Sat Feb  6 18:17:59 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Sat, 06 Feb 2016 23:17:59 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
In-Reply-To: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>
Message-ID: <1454800679.33.0.419233463389.issue23718@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

It looks interesting, let me try to solve this. At first it seems odd that _calc_julian_from_U_or_W returns -2, I guess something is wrong around there.

----------
nosy: +beng94

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

From report at bugs.python.org  Sat Feb  6 19:03:44 2016
From: report at bugs.python.org (Lorenzo Ancora)
Date: Sun, 07 Feb 2016 00:03:44 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454803424.76.0.210909666577.issue26209@psf.upfronthosting.co.za>


Lorenzo Ancora added the comment:

(msg259748) ok, then I propose to correct https://docs.python.org/dev/library/smtpd.html?highlight=q#smtpd.SMTPServer from:

.. class:: SMTPServer(localaddr, remoteaddr, data_size_limit=33554432,\
                      map=None, enable_SMTPUTF8=False, decode_data=True)

   Create a new :class:`SMTPServer` object, which binds to local address
   *localaddr*.  It will treat *remoteaddr* as an upstream SMTP relayer.  It
   inherits from :class:`asyncore.dispatcher`, and so will insert itself into
   :mod:`asyncore`'s event loop on instantiation.


To:


.. class:: SMTPServer(localaddr, remoteaddr, data_size_limit=33554432,\
                      map=None, enable_SMTPUTF8=False, decode_data=True)

   Creates a new :class:`SMTPServer` object, which binds to local address
   *localaddr* and uses *remoteaddr* as an upstream SMTP relayer.
   Both parameters should be a tuple in the form ``("host", portnumber)``, where *host* is a valid IP/FQDN.
   The object will insert itself into :mod:`asyncore`'s event loop on instantiation (inherits from :class:`asyncore.dispatcher`) and can be started with a call to :class:`asyncore.loop`.

---

These clarifications should be also inserted in the source code as heredocs (without the Sphynx syntax).
I really think that those changes will make the use of smtpd easier.

----------

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

From report at bugs.python.org  Sat Feb  6 20:20:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 01:20:20 +0000
Subject: [issue1927] Change input() to always prompt to stderr
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1454808020.4.0.62029626793.issue1927@psf.upfronthosting.co.za>


Martin Panter added the comment:

This proposal is starting to sound reasonable to me. Changing the title to reflect the new direction.

----------
stage: patch review -> needs patch
title: raw_input behavior incorrect if readline not enabled -> Change input() to always prompt to stderr
versions:  -Python 2.7, Python 3.5

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

From report at bugs.python.org  Sat Feb  6 21:40:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Feb 2016 02:40:41 +0000
Subject: [issue19729] [regression] str.format sublevel format parsing broken
 in Python 3.3.3
In-Reply-To: <1385173002.6.0.538237708826.issue19729@psf.upfronthosting.co.za>
Message-ID: <20160207024038.11217.32148@psf.io>


Roundup Robot added the comment:

New changeset f25d8cbd074a by Martin Panter in branch '3.5':
Issue #25179: Preparatory cleanup of existing docs on string formatting
https://hg.python.org/cpython/rev/f25d8cbd074a

New changeset fe692ee6d19a by Martin Panter in branch '2.7':
Issue #25179: Preparatory cleanup of existing docs on string formatting
https://hg.python.org/cpython/rev/fe692ee6d19a

----------

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

From report at bugs.python.org  Sat Feb  6 21:40:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Feb 2016 02:40:41 +0000
Subject: [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <20160207024038.11217.34998@psf.io>


Roundup Robot added the comment:

New changeset f25d8cbd074a by Martin Panter in branch '3.5':
Issue #25179: Preparatory cleanup of existing docs on string formatting
https://hg.python.org/cpython/rev/f25d8cbd074a

New changeset fe692ee6d19a by Martin Panter in branch '2.7':
Issue #25179: Preparatory cleanup of existing docs on string formatting
https://hg.python.org/cpython/rev/fe692ee6d19a

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Feb  6 22:06:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 03:06:41 +0000
Subject: [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1454814401.67.0.000471406931441.issue25179@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding doc strings, it seems that a constant f-string without any interpolations does become a doc string. But I would treat this as an implementation detail, not something to advertise.

Attached is my attempt at a patch. Please have a look and let me know if there are things I missed, if I added too much detail, wrong terminology, or whatever. I haven?t really written documentation like this before.

The combinations and permutations of all the Fr". . ." prefixes are getting borderline out of hand in the lexical_analysis.rst grammar. Any suggestions?

I put the bulk of the documentation in a new section ?Formatted string literals? of the Lexical Analysis chapter, the same place that describes escape sequences and raw strings. Let me know if there is a more appropriate place for it. It doesn?t feel quite right where it is because this chapter comes before Expressions, and f-strings use expressions inside them.

I also made minimal changes to existing parts of the documentation and tutorial, to point to the new documentation. Perhaps some code examples could be changed from str.format() to f". . .", but I think that would be the subject of a separate patch. There are even places that still use the outdated "{0}".format() numbering.

----------
keywords: +patch
nosy: +martin.panter
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41839/f-strings.patch

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

From report at bugs.python.org  Sat Feb  6 22:41:07 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 03:41:07 +0000
Subject: [issue16023] IDLE freezes on ^5 or ^6 (Un-)Tabify Region with OS X
 Cocoa Tk 8.5
In-Reply-To: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za>
Message-ID: <1454816467.64.0.00674509292111.issue16023@psf.upfronthosting.co.za>


Ned Deily added the comment:

I can no longer reproduce this either so I agree with Mark that it has most likely been fixed in later versions of Tk.  If the problem can be reproduced with current Tk releases, please re-open.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Feb  6 22:41:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 03:41:26 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454816486.35.0.891645539374.issue26136@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the updated patch. There are a couple minor problems with the What?s New entry, which you can fix if you want, or I could fix if I get around to merging it:

* Bullet point should probably be wrapped onto multiple lines
* According to the 3.5 What?s New, the DeprecationWarning is ?non-silent?, but I would just drop the ?silent? attribute (Once upon a time in Python 2, DeprecationWarning was apparently enabled by default, in constrast with PendingDeprecationWarning, which was silenced by default.)
* Change ?which will trigger a RuntimeError? ? ?and will trigger . . .?
* Missing full stop at the end

----------

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

From report at bugs.python.org  Sat Feb  6 23:02:48 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 04:02:48 +0000
Subject: [issue25992] test_gdb fails on OSX
In-Reply-To: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za>
Message-ID: <1454817768.28.0.44506050638.issue25992@psf.upfronthosting.co.za>


Ned Deily added the comment:

There is an open earlier issue about test_gdb failures on OS X with Homebrew.  Closing this issue in favor of that one.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_gdb failures on os x 10.9.2

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

From report at bugs.python.org  Sat Feb  6 23:06:03 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 04:06:03 +0000
Subject: [issue21263] test_gdb failures on os x 10.9.2
In-Reply-To: <1397674257.45.0.239061101467.issue21263@psf.upfronthosting.co.za>
Message-ID: <1454817963.23.0.692193932635.issue21263@psf.upfronthosting.co.za>


Ned Deily added the comment:

See also duplicate Issue25992.  Unless someone has a better idea, I suggest we just disable test_gdb on OS X or, somewhat more precisely, when Python has been compiled with LLVM clang.

----------
nosy: +Bryce Miller
stage:  -> needs patch
versions: +Python 2.7, Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sat Feb  6 23:07:05 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 04:07:05 +0000
Subject: [issue21263] test_gdb failures on os x 10.9.2
In-Reply-To: <1397674257.45.0.239061101467.issue21263@psf.upfronthosting.co.za>
Message-ID: <1454818025.55.0.857843468162.issue21263@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Sun Feb  7 00:12:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 05:12:57 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454821977.02.0.621526284535.issue26302@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another option might be to do away with the regular expression (personally I like to avoid REs and code generation where practical):

def _is_legal_key(key):
    return key and set(_LegalChars).issuperset(key)

----------
nosy: +martin.panter
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Feb  7 00:15:39 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 05:15:39 +0000
Subject: [issue25151] venv does not work with debian releases,
 if you want to install pip
In-Reply-To: <1442498140.39.0.803363525343.issue25151@psf.upfronthosting.co.za>
Message-ID: <1454822139.85.0.939309996328.issue25151@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip
resolution: third party -> 
stage: resolved -> 
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  7 00:36:42 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 05:36:42 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454823402.27.0.64832709836.issue25195@psf.upfronthosting.co.za>


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


----------
nosy: +michael.foord

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

From report at bugs.python.org  Sun Feb  7 00:46:45 2016
From: report at bugs.python.org (Anish Shah)
Date: Sun, 07 Feb 2016 05:46:45 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1454824005.01.0.0216895616797.issue26136@psf.upfronthosting.co.za>


Anish Shah added the comment:

@martin.panter I have fixed the What's New docs. I have updated the patch. Thanks!

----------
Added file: http://bugs.python.org/file41840/issue26136_20160207.patch

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

From report at bugs.python.org  Sun Feb  7 00:59:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 05:59:29 +0000
Subject: [issue25226] "suffix" attribute not documented in
 logging.TimedRotatingFileHandler
In-Reply-To: <1443087278.13.0.950277021973.issue25226@psf.upfronthosting.co.za>
Message-ID: <1454824769.54.0.647893076003.issue25226@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sun Feb  7 01:12:33 2016
From: report at bugs.python.org (koobs)
Date: Sun, 07 Feb 2016 06:12:33 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1454825553.78.0.381955504804.issue22847@psf.upfronthosting.co.za>


koobs added the comment:

It appears this change broke all FreeBSD builders (9: gcc, 10/11: clang) for the 2.7 branch with:

==== koobs-freebsd-current (clang 3.7.x)

cc -pthread -c -fno-strict-aliasing -OPT:Olimit=0 -g -O2 -g -O0 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Objects/typeobject.o Objects/typeobject.c
Objects/typeobject.c:2568:44: error: no member named 'hash' in 'PyStringObject'
        assert(((PyStringObject *)(name))->hash != -1);
               ~~~~~~~~~~~~~~~~~~~~~~~~~~  ^
/usr/include/assert.h:54:21: note: expanded from macro 'assert'
#define assert(e)       ((e) ? (void)0 : __assert(__func__, __FILE__, \
                          ^
1 error generated.
*** Error code 1

==== koobs-freebsd10 (clang 3.4.x)

cc -pthread -c -fno-strict-aliasing -OPT:Olimit=0 -g -O2 -g -O0 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c
--- Objects/typeobject.o ---
Objects/typeobject.c:2568:18: error: use of undeclared identifier 'PyASCIIObject'
        assert(((PyASCIIObject *)(name))->hash != -1);
                 ^
/usr/include/assert.h:54:21: note: expanded from macro 'assert'
#define assert(e)       ((e) ? (void)0 : __assert(__func__, __FILE__, \
                          ^
Objects/typeobject.c:2568:33: error: expected expression
        assert(((PyASCIIObject *)(name))->hash != -1);
                                ^
/usr/include/assert.h:54:21: note: expanded from macro 'assert'
#define assert(e)       ((e) ? (void)0 : __assert(__func__, __FILE__, \
                          ^
--- Objects/unicodectype.o ---
cc -pthread -c -fno-strict-aliasing -OPT:Olimit=0 -g -O2 -g -O0 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Objects/unicodectype.o Objects/unicodectype.c
--- Objects/typeobject.o ---
2 errors generated.
*** [Objects/typeobject.o] Error code 1


==== koobs-freebsd9 (gcc 4.2.1 + patches)

gcc -pthread -c -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c
Objects/unicodeobject.c: In function 'PyUnicode_DecodeUTF7Stateful':
Objects/unicodeobject.c:1694: warning: comparison is always true due to limited range of data type
gcc -pthread -c -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Objects/unicodectype.o Objects/unicodectype.c
Objects/typeobject.c: In function '_PyType_Lookup':
Objects/typeobject.c:2568: error: 'PyASCIIObject' undeclared (first use in this function)
Objects/typeobject.c:2568: error: (Each undeclared identifier is reported only once
Objects/typeobject.c:2568: error: for each function it appears in.)
Objects/typeobject.c:2568: error: expected expression before ')' token
*** [Objects/typeobject.o] Error code 1

----------
nosy: +koobs
status: closed -> open

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

From report at bugs.python.org  Sun Feb  7 01:27:19 2016
From: report at bugs.python.org (koobs)
Date: Sun, 07 Feb 2016 06:27:19 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1454826439.34.0.100334525032.issue22847@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


----------
resolution: fixed -> 

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

From report at bugs.python.org  Sun Feb  7 01:28:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 06:28:21 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454826501.65.0.192565008264.issue26302@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The regular expression is used for performance.

----------

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

From report at bugs.python.org  Sun Feb  7 01:36:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Feb 2016 06:36:14 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <20160207063611.11217.59975@psf.io>


Roundup Robot added the comment:

New changeset 04424651f76c by Benjamin Peterson in branch '2.7':
fix hash member name (closes #22847)
https://hg.python.org/cpython/rev/04424651f76c

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 01:56:09 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 06:56:09 +0000
Subject: [issue25351] pyvenv activate script failure with specific bash option
In-Reply-To: <1444375437.08.0.147131311455.issue25351@psf.upfronthosting.co.za>
Message-ID: <1454828169.29.0.991029945609.issue25351@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sun Feb  7 02:11:44 2016
From: report at bugs.python.org (Swati Jaiswal)
Date: Sun, 07 Feb 2016 07:11:44 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <1454829104.41.0.35031630699.issue25913@psf.upfronthosting.co.za>


Swati Jaiswal added the comment:

Is there any requirement for further modification or it can be accepted?

----------

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

From report at bugs.python.org  Sun Feb  7 02:16:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 07:16:14 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454829374.5.0.495712018059.issue26285@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe I am missing something, but I don?t see how you could load your module if it uses PyMem_RawMalloc. Perhaps PyMem_RawMalloc has been removed from some other executable (e.g. Parser/pgen), rather than the main Python executable?

----------
nosy: +martin.panter

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

From report at bugs.python.org  Sun Feb  7 02:17:21 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Feb 2016 07:17:21 +0000
Subject: [issue25459] EAGAIN errors in Python logging module
In-Reply-To: <1445522395.9.0.458727890682.issue25459@psf.upfronthosting.co.za>
Message-ID: <1454829441.78.0.758297038314.issue25459@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sun Feb  7 03:52:55 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 08:52:55 +0000
Subject: [issue26298] Split ceval.c into small files
In-Reply-To: <1454694194.19.0.667828891375.issue26298@psf.upfronthosting.co.za>
Message-ID: <1454835175.42.0.731065293308.issue26298@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm also -1 on the split for the reasons listed by Brett and Serhiy.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Feb  7 03:57:41 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 08:57:41 +0000
Subject: [issue26294] Queue().unfinished_tasks not in docs - deliberate?
In-Reply-To: <1454662858.22.0.0628824582163.issue26294@psf.upfronthosting.co.za>
Message-ID: <1454835461.05.0.84242027582.issue26294@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Sun Feb  7 04:04:20 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 09:04:20 +0000
Subject: [issue26294] Queue().unfinished_tasks not in docs - deliberate?
In-Reply-To: <1454662858.22.0.0628824582163.issue26294@psf.upfronthosting.co.za>
Message-ID: <1454835860.98.0.601758094813.issue26294@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Just as you thought, the 'unfinished_tasks' attribute not intended to be part of the public API for queues.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 04:06:11 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 09:06:11 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454835971.93.0.0658189400105.issue26194@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 04:19:05 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 09:19:05 +0000
Subject: [issue26264] keyword module missing async and await keywords
In-Reply-To: <1454378786.53.0.925531991818.issue26264@psf.upfronthosting.co.za>
Message-ID: <1454836745.54.0.235680124353.issue26264@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It shouldn't go into keywords.py until it is actually a keyword.  Keywords is used for many purposes including syntax highlighting and code analysis tools.

----------
assignee: rhettinger -> 
resolution:  -> not a bug

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

From report at bugs.python.org  Sun Feb  7 04:27:54 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 09:27:54 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1454837274.53.0.442381121256.issue26223@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm disinclined to make a new method and instead prefer to go the route of having a formatting option.  For the most part, we want the methods to be limited to those in the spec (the API is already huge).  The other reason is that output formatting options are what __format__() method was intended to address.

If you want to go further, it would be reasonable to bring https://bugs.python.org/issue8060 back to life.  The final entry in that tracker item recommended moving the discussion to python ideas or into a PEP (like was done for the thousands separator format option).  There are many viewpoints to consider before jumping to codify one particular approach into the standard library.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 04:31:29 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 09:31:29 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1454837489.18.0.864568266433.issue26282@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for this suggestion.  There are a number of places where we've been trapped between having no keyword arguments or having to use keywords for all arguments even when it doesn't make sense to have all arguments be keywords.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Feb  7 04:35:19 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 09:35:19 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1454837719.94.0.324172478199.issue26200@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

If you don't add an XSETREF variant, I think you should revert the instances where a Py_DECREF was downgraded to Py_XDECREF.

----------

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

From report at bugs.python.org  Sun Feb  7 04:36:29 2016
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 07 Feb 2016 09:36:29 +0000
Subject: [issue24421] Race condition compiling Modules/_math.c
In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za>
Message-ID: <1454837789.98.0.0228592561068.issue24421@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Feb  7 04:38:47 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 07 Feb 2016 09:38:47 +0000
Subject: [issue26204] compiler: ignore constants used as statements? (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1454837927.65.0.986247105991.issue26204@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Feb  7 04:42:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 09:42:55 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1454838175.48.0.237664455111.issue21042@psf.upfronthosting.co.za>


Martin Panter added the comment:

The ABI matching looks wrong to me. If I am looking for a 32-bit library, won?t it incorrectly catch the wrong path in the following ?ldconfig -p? output:

'\tlibm.so.6 (libc6,x86-64, OS ABI: Linux 2.6.32) => /usr/lib/libm.so.6\n'
'\tlibm.so.6 (libc6, OS ABI: Linux 2.6.32) => /usr/lib32/libm.so.6\n'

Perhaps the abi_type check needs to be moved in front of the path name extraction.

For the version, I would put 3.6. Since this changes documented behaviour and has the potential to break compatibilty, it is best not to change it in a bug fix release. (3.5 has already been released.)

The problem with the test() function in ctypes.util is that it is not run by the main Python regression test suite. The tests under ctypes/test/ are run by the test suite.

----------

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

From report at bugs.python.org  Sun Feb  7 05:16:20 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 07 Feb 2016 10:16:20 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454840180.1.0.519213985085.issue26288@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The comment looks good to me -- I'll stay out of the benchmarking issue, I didn't check any of that. :)

----------

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

From report at bugs.python.org  Sun Feb  7 05:36:05 2016
From: report at bugs.python.org (Anish Shah)
Date: Sun, 07 Feb 2016 10:36:05 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454841365.58.0.0687742856729.issue26302@psf.upfronthosting.co.za>


Anish Shah added the comment:

I ran regex and issuperset version on a random string. The regex one gives better performance. So, I have included the re.escape in the patch. 

>>> random_str = ''.join(random.choice(_LegalChars) for _ in range(10 ** 8))
>>> is_legal_key = re.compile('[%s]+' % re.escape(_LegalChars)).fullmatch
>>> Timer("is_legal_key(random_str)", setup="from __main__ import random_str, is_legal_key").timeit(1)
0.3168252399998437
>>> def is_legal_key(key):
...     return key and set(_LegalChars).issuperset(key)
... 
>>> Timer("is_legal_key(random_str)", setup="from __main__ import random_str, is_legal_key").timeit(1)
4.3335622880001665


Also, I have updated the patch. Can you please review it? :)

----------
Added file: http://bugs.python.org/file41841/issue26302_20160207.patch

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

From report at bugs.python.org  Sun Feb  7 05:38:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 10:38:11 +0000
Subject: [issue26264] keyword module missing async and await keywords
In-Reply-To: <1454378786.53.0.925531991818.issue26264@psf.upfronthosting.co.za>
Message-ID: <1454841491.69.0.74577395624.issue26264@psf.upfronthosting.co.za>


Martin Panter added the comment:

To answer my question, it looks like the keywords.py list is automatically generated (by running the script) from Python/graminit.c, in turn generated from Grammar/Grammar. ?Yield? and ?with? were always listed even when the __future__ statement was needed to enable them (2.2 and 2.5). But currently ASYNC and AWAIT are in Grammar as what I believe are special tokens, rather than normal keywords.

Depending on the purpose of the syntax highlighting or code analysis, it might be better for these to be listed as keywords now, rather than waiting until 3.7.

----------

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

From report at bugs.python.org  Sun Feb  7 06:00:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 11:00:12 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454842812.18.0.721147498739.issue26302@psf.upfronthosting.co.za>


Martin Panter added the comment:

The same bug is in the _CookiePattern regular expression. For illegal characters other than a comma, the CookieError does not actually seem to be raised.

----------

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

From report at bugs.python.org  Sun Feb  7 06:03:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Feb 2016 11:03:25 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454843005.27.0.637094817167.issue26302@psf.upfronthosting.co.za>


Martin Panter added the comment:

I take that back about _CookiePattern having the same bug; it uses a different input variable. But it is strange that _LegalKeyChars lists a comma, but _LegalChars omits it.

----------

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

From report at bugs.python.org  Sun Feb  7 06:20:48 2016
From: report at bugs.python.org (Anish Shah)
Date: Sun, 07 Feb 2016 11:20:48 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454843005.27.0.637094817167.issue26302@psf.upfronthosting.co.za>
Message-ID: <CAOqj4aUhhA5y__c9t359qwBXoi2baqG4zGWuKq7fkFRDOmxxAw@mail.gmail.com>


Anish Shah added the comment:

_LegalKeyChars contains "\-" whereas _LegalChars just contains "-".

On Sun, Feb 7, 2016 at 4:33 PM, Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter added the comment:
>
> I take that back about _CookiePattern having the same bug; it uses a
> different input variable. But it is strange that _LegalKeyChars lists a
> comma, but _LegalChars omits it.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26302>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Feb  7 06:21:48 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 07 Feb 2016 11:21:48 +0000
Subject: [issue26299] wsgiref.util FileWrapper raises ValueError: I/O
 operation on closed file.
In-Reply-To: <1454697605.85.0.988308856795.issue26299@psf.upfronthosting.co.za>
Message-ID: <1454844108.58.0.398235301677.issue26299@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +pje
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sun Feb  7 06:33:30 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 07 Feb 2016 11:33:30 +0000
Subject: [issue25226] "suffix" attribute not documented in
 logging.TimedRotatingFileHandler
In-Reply-To: <1443087278.13.0.950277021973.issue25226@psf.upfronthosting.co.za>
Message-ID: <1454844810.56.0.995387006374.issue25226@psf.upfronthosting.co.za>


SilentGhost added the comment:

It isn't documented because it's an internal attribute. If it did work for someone, it's by accident. Naturally, Vinay would have to make a final judgement regarding this, but I'd be inclined to close as not a bug.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Feb  7 06:35:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 11:35:48 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1454844948.19.0.535754766244.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On 28.02.14 15:58, Kristj?n Valur J?nsson wrote:
> Also, for the equivalence to hold there is no separate Py_XSETREF, the X
> behaviour is implied, which I favour.  Enough of this X-proliferation
> already!

On 16.12.15 16:53, Random832 wrote:
> I think "SET" names imply that it's safe if the original
> reference is NULL. This isn't an objection to the names, but if
> it is given one of those names I think it should use Py_XDECREF.

It was my initial intension. But then I had got a number of voices for single macros.

On 16.12.15 23:16, Victor Stinner wrote:
> I would prefer a single macro to avoid bugs, I don't think that such
> macro has a critical impact on performances. It's more designed for
> safety, no?

On 17.12.15 08:22, Nick Coghlan wrote:
>> 1. Py_SETREF
>
> +1 if it always uses Py_XDECREF on the previous value (as I'd expect
> this to work even if the previous value was NULL)

Some objections were repeated by their authors few times. And I had no one voice for separate macros (except my).

In the light of your objection we should reraise this issue on Python-Dev.

Now, after applying patches, it would be harder to split Py_SETREF on two macros. But I tried to not replace a Py_DECREF with a Py_SETREF in performance critical code (e.g. in PyDict_SetItem).

----------

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

From report at bugs.python.org  Sun Feb  7 06:56:22 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 07 Feb 2016 11:56:22 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454846182.27.0.557022009682.issue26288@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Well I *did* run the decimal/float milli-benchmark now and it shows at least 15% improvement for floats consistently.

Given that the official benchmark suite does not seem to be very stable either (#21955), I actually prefer small and well-understood benchmarks.

----------

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

From report at bugs.python.org  Sun Feb  7 07:34:21 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 07 Feb 2016 12:34:21 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1454848461.09.0.820720857583.issue24950@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch that addresses the issue in both tests. Felix, could you test it?

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file41842/issue24950.diff

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

From report at bugs.python.org  Sun Feb  7 08:06:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 13:06:43 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1454850403.64.0.473948728353.issue24950@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What if HOME is "//"?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Feb  7 08:18:39 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 07 Feb 2016 13:18:39 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1454851119.19.0.0467989169972.issue24950@psf.upfronthosting.co.za>


SilentGhost added the comment:

> What if HOME is "//"?

Is this possible? What would be the result of these tests? Would they fail? As far as I understand my patch is just fixing problem introduced by fixes from issue 17809.

----------

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

From report at bugs.python.org  Sun Feb  7 09:08:38 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 07 Feb 2016 14:08:38 +0000
Subject: [issue26284] FIx telco benchmark
In-Reply-To: <1454596081.41.0.621997504219.issue26284@psf.upfronthosting.co.za>
Message-ID: <1454854118.55.0.643197595193.issue26284@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Unfortunately, replacing io.BytesIO(data) with indexing does not make the benchmark faster or more stable on my machine.

BTW, string conversion of the result is actually a crucial part of
the benchmark, it was taken out in http://bugs.python.org/file41802/telco_haypo.py.

----------

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

From report at bugs.python.org  Sun Feb  7 09:10:43 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 07 Feb 2016 14:10:43 +0000
Subject: [issue26284] Fix telco benchmark
In-Reply-To: <1454596081.41.0.621997504219.issue26284@psf.upfronthosting.co.za>
Message-ID: <1454854243.22.0.79473382369.issue26284@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
title: FIx telco benchmark -> Fix telco benchmark

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

From report at bugs.python.org  Sun Feb  7 10:01:06 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 07 Feb 2016 15:01:06 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454857266.88.0.55103548822.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

>From what I can see there is no negative impact of the patch on stable macro benchmarks.

There is quite a detectable positive impact on most of integer and float operations from my patch.  13-16% on nbody and spectral_norm benchmarks is still impressive.  And you can see a huge improvement in various timeit micro-benchmarks.

fastint5 is a very compact patch, that only touches the ceval.c file.  It doesn't complicate the code, as the macro is very straightforward.  Since the patch passed the code review, thorough benchmarking and discussion stages, I'd like to commit it.

----------

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

From report at bugs.python.org  Sun Feb  7 10:08:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 15:08:44 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454857724.4.0.226010183929.issue21955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please don't commit it right now. Yes, due to using macros the patch looks simple, but macros expanded to complex code. We need more statistics.

----------

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

From report at bugs.python.org  Sun Feb  7 10:16:35 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 07 Feb 2016 15:16:35 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454858195.91.0.382567147284.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Please don't commit it right now. Yes, due to using macros the patch looks simple, but macros expanded to complex code. We need more statistics.

But what you will use to gather statistics data?  Test suite isn't representative, and we already know what will benchmarks suite show.  I can assist with writing some code for stats, but what's the plan?

----------

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

From report at bugs.python.org  Sun Feb  7 11:18:24 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 07 Feb 2016 16:18:24 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454861904.74.0.18136146111.issue21955@psf.upfronthosting.co.za>


Stefan Krah added the comment:

#26288 brought a great speedup for floats. With fastint5_4.patch *on top of #26288* I see no improvement for floats and a big slowdown for _decimal.

----------

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

From report at bugs.python.org  Sun Feb  7 11:38:17 2016
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 07 Feb 2016 16:38:17 +0000
Subject: [issue21536] extension built with a shared python cannot be loaded
 with a static python
In-Reply-To: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za>
Message-ID: <1454863097.71.0.390979630826.issue21536@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Sun Feb  7 12:24:13 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Sun, 07 Feb 2016 17:24:13 +0000
Subject: [issue8060] PEP 3101 string formatting missing engineering
 presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1454865853.97.0.811628553782.issue8060@psf.upfronthosting.co.za>


Serge Stroobandt added the comment:

As per https://bugs.python.org/issue26223#msg259772 , can we please reopen this?

I kind of hate it when *real* issues are kept closed for years (6!) until another lost soul comes by with the same itch...

----------
nosy: +serge.stroobandt
versions: +Python 3.6 -Python 3.2

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

From report at bugs.python.org  Sun Feb  7 13:10:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 18:10:55 +0000
Subject: [issue26297] Move constant folding to AST level
In-Reply-To: <1454693647.41.0.887597709812.issue26297@psf.upfronthosting.co.za>
Message-ID: <1454868655.51.0.818428148282.issue26297@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Issue1346238 has a patch.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> A constant folding optimization pass for the AST

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

From report at bugs.python.org  Sun Feb  7 13:20:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 18:20:32 +0000
Subject: [issue15731] Mechanism for inheriting docstrings and signatures
In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za>
Message-ID: <1454869232.5.0.708778174884.issue15731@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

After issue15582, is it still actual?

----------

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

From report at bugs.python.org  Sun Feb  7 13:25:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 18:25:18 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1454869518.06.0.197693241264.issue25295@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Seems this issue can be closed now.

----------

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

From report at bugs.python.org  Sun Feb  7 13:49:50 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Feb 2016 18:49:50 +0000
Subject: [issue25226] "suffix" attribute not documented in
 logging.TimedRotatingFileHandler
In-Reply-To: <1443087278.13.0.950277021973.issue25226@psf.upfronthosting.co.za>
Message-ID: <1454870990.36.0.417415208168.issue25226@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

It's not documented, and not intended to be changeable by the user, because it is not set to a fixed value - the value depends on the "when" (to rollover) and "interval" arguments to the handler initializer. If you really need to have functionality other than the default, the way to do this is by creating a subclass and changing its behaviour appropriately.

IMO the accepted SO answer you linked to doesn't give correct advice.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 13:57:17 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Feb 2016 18:57:17 +0000
Subject: [issue25459] EAGAIN errors in Python logging module
In-Reply-To: <1445522395.9.0.458727890682.issue25459@psf.upfronthosting.co.za>
Message-ID: <1454871437.87.0.477227769814.issue25459@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

The problem with your suggested fix is that if you keep getting EAGAIN, the handler will appear to hang. If you want to suggest that maybe we limit the number of tries, then what number of retries would you pick, and why? Also, a caller might want to know about EAGAIN, so I'm not sure you'd want to (effectively) swallow it in the handler.

Perhaps a different strategy (than just trying for ever) would be better. If you know the application is unusual in having a SIGPIPE handler and you think this is a contributory factor, why not just subclass the handler, add a more resilient emit() and use that in your application?

----------
status: open -> pending

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

From report at bugs.python.org  Sun Feb  7 14:13:37 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 07 Feb 2016 19:13:37 +0000
Subject: [issue25226] "suffix" attribute not documented in
 logging.TimedRotatingFileHandler
In-Reply-To: <1443087278.13.0.950277021973.issue25226@psf.upfronthosting.co.za>
Message-ID: <1454872417.75.0.65712362333.issue25226@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
stage:  -> resolved

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

From report at bugs.python.org  Sun Feb  7 14:30:03 2016
From: report at bugs.python.org (Case Van Horsen)
Date: Sun, 07 Feb 2016 19:30:03 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454873403.66.0.781330153747.issue21955@psf.upfronthosting.co.za>


Case Van Horsen added the comment:

Can I suggest the mpmath test suite as a good benchmark? I've used it to test the various optimizations in gmpy2 and it has always been a valuable real-world benchmark. And it is slower in Python 3 than Python 2....

----------

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

From report at bugs.python.org  Sun Feb  7 14:42:01 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Feb 2016 19:42:01 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454874121.1.0.935219840918.issue21955@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Be careful with test suites: first, they might exercise code that would never be a critical point for performance in a real-world application; second and most important, unittest seems to have gotten slower between 2.x and 3.x, so you would really be comparing apples to oranges.

----------

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

From report at bugs.python.org  Sun Feb  7 16:04:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 21:04:59 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <1454879098.98.0.335538887424.issue25913@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Martin, Antoine, what would you say about this?

----------

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

From report at bugs.python.org  Sun Feb  7 16:07:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 21:07:46 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1454879266.94.0.531524378445.issue26289@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

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

From report at bugs.python.org  Sun Feb  7 16:32:54 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 07 Feb 2016 21:32:54 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454880774.31.0.853307484585.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching another patch - fastint6.patch that only optimizes longs (no FP fast path).

> #26288 brought a great speedup for floats. With fastint5_4.patch *on top of #26288* I see no improvement for floats and a big slowdown for _decimal.

What benchmark did you use?  What were the numbers?  I'm asking because before you benchmarked different patches that are conceptually similar to fastint5, and the result was that decimal was 5% faster with fast paths for just longs, and 6% slower with fast paths for longs & floats.

Also, some quick timeit results (quite stable from run to run):


-m timeit -s "x=2" "x + 10 + x * 20  + x* 10 + 20 -x"
3.6: 0.150usec           3.6+fastint: 0.112usec


-m timeit -s "x=2" "x*2.2 + 2 + x*2.5 + 1.0 - x / 2.0 + (x+0.1)/(x-0.1)*2 + (x+10)*(x-30)"
3.6: 0.425usec           3.6+fastint: 0.302usec

----------
Added file: http://bugs.python.org/file41843/fastint6.patch

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

From report at bugs.python.org  Sun Feb  7 17:05:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Feb 2016 22:05:33 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <20160207220530.1535.93603@psf.io>


Roundup Robot added the comment:

New changeset 7fea2cebc604 by Serhiy Storchaka in branch 'default':
Issue #26039: Added zipfile.ZipInfo.from_file() and zipinfo.ZipInfo.is_dir().
https://hg.python.org/cpython/rev/7fea2cebc604

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Feb  7 17:14:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 22:14:13 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454883253.2.0.34604512705.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed zipinfo-from-file5.patch. Now I'm starting to review zipfile-open-w4.patch (I concurred with most Martin's comments for previous patches).

----------

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

From report at bugs.python.org  Sun Feb  7 17:23:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 22:23:43 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <1454883823.39.0.654198849609.issue25698@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Benjamin, could you please make a review?

----------

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

From report at bugs.python.org  Sun Feb  7 18:03:57 2016
From: report at bugs.python.org (desbma)
Date: Sun, 07 Feb 2016 23:03:57 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1454886237.8.0.747802643751.issue25156@psf.upfronthosting.co.za>


desbma added the comment:

If anyone is interested, I have created a package to monkey patch shutil.copyfile to benefit from sendfile, similarly to the last patch, but it also works on older Python versions down to 2.7.

PyPI link: https://pypi.python.org/pypi/pyfastcopy/

----------

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

From report at bugs.python.org  Sun Feb  7 18:23:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Feb 2016 23:23:16 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <20160207232313.2639.41186@psf.io>


Roundup Robot added the comment:

New changeset ab25ce400abd by Serhiy Storchaka in branch '2.7':
Issue #26198: Fixed error messages for some argument parsing errors.
https://hg.python.org/cpython/rev/ab25ce400abd

New changeset 9f998e24d8d8 by Serhiy Storchaka in branch '3.5':
Issue #26198: Fixed error messages for some argument parsing errors.
https://hg.python.org/cpython/rev/9f998e24d8d8

New changeset f8bdc0ea3bcf by Serhiy Storchaka in branch 'default':
Issue #26198: Fixed error messages for some argument parsing errors.
https://hg.python.org/cpython/rev/f8bdc0ea3bcf

New changeset 53d66a554beb by Serhiy Storchaka in branch 'default':
Issue #26198: ValueError is now raised instead of TypeError on buffer
https://hg.python.org/cpython/rev/53d66a554beb

----------

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

From report at bugs.python.org  Sun Feb  7 18:33:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 23:33:17 +0000
Subject: [issue17394] Add slicing support to collections.deque
In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>
Message-ID: <1454887997.88.0.827275025914.issue17394@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since the patch is so complex, I suggest to split it on parts, and review and commit them separately:

1) Refactoring. Extract common code to macros and utility functions. These macros can be used for more efficient implementing insert() and __del__.

2) Add slice getting.

3) Add slice assignment and deleting. I'm not sure that this is needed for deque.

----------

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

From report at bugs.python.org  Sun Feb  7 18:35:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Feb 2016 23:35:00 +0000
Subject: [issue25007] Add support of copy protocol to zlib compressors and
 decompressors
In-Reply-To: <1441449753.43.0.0389421030599.issue25007@psf.upfronthosting.co.za>
Message-ID: <1454888100.49.0.936131313329.issue25007@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch

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

From report at bugs.python.org  Sun Feb  7 19:02:58 2016
From: report at bugs.python.org (Andrew Plummer)
Date: Mon, 08 Feb 2016 00:02:58 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454889778.05.0.179778548425.issue25195@psf.upfronthosting.co.za>


Andrew Plummer added the comment:

I've had a look and I think this could be because the class _Call (also in unittest.mock) has lost its __ne__ method between 3.4 and 3.5.

Compare
https://hg.python.org/cpython/file/v3.4.4/Lib/unittest/mock.py#l2010
with
https://hg.python.org/cpython/file/v3.5.1/Lib/unittest/mock.py#l2028

This leads me to this changeset:
https://hg.python.org/cpython/rev/3603bae63c13


My failing test:

from unittest import mock

call1 = mock.call(mock.MagicMock())
call2 = mock.call(mock.ANY)

assert call1 == call2
assert not (call1 != call2)

This passes in 3.4 but fails in 3.5, but fails on the second assert, not the first. So they are equal, but they're not not-equal. I've added this as a test and reinstated __ne__ in my patch.

----------
keywords: +patch
nosy: +Andrew Plummer
Added file: http://bugs.python.org/file41844/fix_mock_call_ne.patch

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

From report at bugs.python.org  Sun Feb  7 20:23:14 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Feb 2016 01:23:14 +0000
Subject: [issue17394] Add slicing support to collections.deque
In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>
Message-ID: <1454894594.98.0.930783631017.issue17394@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm already underway for the review.   The "refactoring" part is making is more difficult.  We just need slicing support to be added.  Yes, I do want slice assignment and deletion.   The output should be a deque, not a list.

----------

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

From report at bugs.python.org  Sun Feb  7 23:10:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 08 Feb 2016 04:10:21 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454904621.6.0.0727928231513.issue25195@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Feb  7 23:28:11 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 08 Feb 2016 04:28:11 +0000
Subject: [issue15731] Mechanism for inheriting docstrings and signatures
In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za>
Message-ID: <1454905691.2.0.278548097359.issue15731@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Agreed, making it easy to follow the inheritance chains at docstring lookup time means it would be redundant to duplicate them at class definition time.

Code that interrogates __doc__ directly rather than using inspect.getdoc won't benefit from the new behaviour, but that's a quality of implementation question in the code handling the introspection.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 23:36:19 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 08 Feb 2016 04:36:19 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454906179.57.0.235830989889.issue25195@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks like _Call is a subclass of tuple. Checks in the test could be written as "self.assertIs(a == b, True)".

----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.6

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

From report at bugs.python.org  Sun Feb  7 23:36:40 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 08 Feb 2016 04:36:40 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1454906200.09.0.0262296206037.issue8810@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I agree it makes sense to merge this and #9305, and since the latter has seen more recent activity, I'll do the merge in that direction.

----------
resolution:  -> duplicate
stage: patch review -> 
status: open -> closed
superseder:  -> Don't use east/west of UTC in date/time documentation

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

From report at bugs.python.org  Sun Feb  7 23:43:36 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 08 Feb 2016 04:43:36 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
In-Reply-To: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>
Message-ID: <1454906616.46.0.969611096946.issue26096@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

If you really need an easy way to provide what the shell offers to end users, maybe you could submit a patch that adds an option similar to "GLOBIGNORE" in bash (but the default would be to return everything, which is more regular and more useful for Python programs). Though you might also consider how easy it would be to write a wrapper function around Path.glob() that implements this.

----------

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

From report at bugs.python.org  Mon Feb  8 00:15:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 05:15:12 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1454908512.0.0.379107426584.issue26302@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks okay to me.

The inconsistency between silently rejecting cookie ?morsels? and raising an exception from load() also exists in 2.7, so maybe it is not a big deal.

----------

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

From report at bugs.python.org  Mon Feb  8 00:40:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 05:40:37 +0000
Subject: [issue19869] BaseCookie does not complain if a non RFC compliant
 cookie header was given
In-Reply-To: <1386055381.8.0.960410220021.issue19869@psf.upfronthosting.co.za>
Message-ID: <1454910037.95.0.313330534976.issue19869@psf.upfronthosting.co.za>


Martin Panter added the comment:

Due to the change in Issue 22796, a key without a value (?httponly,? in the example) now causes the parsing operation to be silently aborted. Perhaps we can close this?

----------
nosy: +martin.panter

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

From report at bugs.python.org  Mon Feb  8 00:51:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 05:51:24 +0000
Subject: [issue22983] Cookie parsing should be more permissive
In-Reply-To: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za>
Message-ID: <1454910684.44.0.304661158186.issue22983@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch at Issue 25228 should partially do what Demian proposed. Anyway, I think Issue 17340 is basically about the same problem.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> Handle malformed cookie

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

From report at bugs.python.org  Mon Feb  8 00:55:56 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 08 Feb 2016 05:55:56 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454910956.33.0.108788674114.issue26198@psf.upfronthosting.co.za>


Berker Peksag added the comment:

test_datetime is broken on 3.5 and default:

======================================================================
FAIL: test_format (test.datetimetester.TestSubclassDateTime)
----------------------------------------------------------------------
TypeError: __format__() argument 1 must be str, not int

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/buildbot/slaves/profile-opt-bot/3.5.gps-debian-profile-opt/build/Lib/test/datetimetester.py", line 1578, in test_format
    dt.__format__(123)
AssertionError: "^must be str, not int$" does not match "__format__() argument 1 must be str, not int"

http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.5/builds/632/steps/test/logs/stdio

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/10486/steps/test/logs/stdio

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Mon Feb  8 01:34:34 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Feb 2016 06:34:34 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1454883823.39.0.654198849609.issue25698@psf.upfronthosting.co.za>
Message-ID: <1454913270.2435062.514779010.2C32643D@webmail.messagingengine.com>


Benjamin Peterson added the comment:

I don't think this patch is the best way. The correct way is to have and
use PyDict_GetWithError. I wouldn't be surprised if you could crash
Python under this patch by putting some function with an import in
__cmp__ in sys.modules.

On Sun, Feb 7, 2016, at 14:23, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Benjamin, could you please make a review?
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25698>
> _______________________________________

----------

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

From report at bugs.python.org  Mon Feb  8 01:54:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 06:54:02 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454914442.47.0.914458669759.issue25195@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It would be better to use just default implementation:

    __ne__ = object.__ne__

Interesting that while call1 == call2 is True, call2 == call1 is False. But this is different issue.

----------

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

From report at bugs.python.org  Mon Feb  8 02:11:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 07:11:05 +0000
Subject: [issue17340] http.cookies: Handle malformed cookie
In-Reply-To: <1362309033.05.0.860433762185.issue17340@psf.upfronthosting.co.za>
Message-ID: <1454915465.04.0.375648795221.issue17340@psf.upfronthosting.co.za>


Martin Panter added the comment:

The current Python 3.5 and default branches actually seem to parse the test case given:

>>> c = SimpleCookie()
>>> c.load(",BRIDGE_R=; a=b; user_id=1;")
>>> c
<SimpleCookie: ,BRIDGE_R='' a='b' user_id='1'>

But that is just a side effect of Issue 26302. When that is fixed, parsing the cookie string will raise CookieError and fail to set the invalid cookie ?morsel?, and the ones that come after it.

There seems to be a disconnect between _LegalChars (causes the CookieError if a comma is in a cookie key name) and _LegalKeyChars (allows a comma, but causes cookie string parsing to silently abort for other illegal characters).

There are other cases where the entire cookie string is rejected, specifically added by Issue 22796 (revision a065ab1c67a8).

On the other hand, Issue 25228 has a which has a patch to skip over some invalid cookie ?morsels? and continue on to valid ones.

----------
nosy: +martin.panter
title: Handle malformed cookie -> http.cookies: Handle malformed cookie

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

From report at bugs.python.org  Mon Feb  8 02:20:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 07:20:30 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1454916030.39.0.56750502566.issue25228@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looking at this a second time, I think I have figured out what the security report was about. Before the fix (before revision 270f61ec1157), an attacker could trick the parser into accepting a separate key=value cookie ?morsel?, when it was supposed to be part of some other cookie value. Suppose the ?c=d? text was meant to be associated with the ?message? key. Before the security fix, ?c=d? is separated:

>>> SimpleCookie('a=b; messages=[""]c=d;')
<SimpleCookie: a='b' c='d'>

With the fix applied, we now silently abort the parsing, and there is no spurious ?c? key:

>>> SimpleCookie('a=b; messages=[""]c=d;')
<SimpleCookie: a='b'>

This also seems to be described by Sergey Bobrov in Russian at <https://habrahabr.ru/post/272187/>.

Looking at the proposed patch again, I think the fix might be okay. Some specifications for cookies allow semicolons to be quoted or escaped, and I was a bit worried that this might be a problem. But all the scenarios I can imagine would be no worse with the patch compared to without it.

----------

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

From report at bugs.python.org  Mon Feb  8 02:27:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 07:27:50 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <20160208072746.1566.29238@psf.io>


Roundup Robot added the comment:

New changeset 22b0a63808f8 by Serhiy Storchaka in branch '3.5':
Issue #26198: Make datetime error tests more lenient.
https://hg.python.org/cpython/rev/22b0a63808f8

New changeset a9c9e4054f3f by Serhiy Storchaka in branch 'default':
Issue #26198: Make datetime error tests more lenient.
https://hg.python.org/cpython/rev/a9c9e4054f3f

----------

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

From report at bugs.python.org  Mon Feb  8 02:30:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 07:30:47 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454916647.68.0.430149077867.issue26198@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Berker.

----------

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

From report at bugs.python.org  Mon Feb  8 02:55:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 07:55:33 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzMDRdIEZpeCDigJxhbGxvd3MgdG8gPHZlcmI+4oCdIGluIGRv?=
 =?utf-8?q?cumentation?=
Message-ID: <1454918132.41.0.149238322531.issue26304@psf.upfronthosting.co.za>


New submission from Martin Panter:

This patch changes instances of ?. . . allows to <verb>? to ?. . . allows <verb>ing? or similar. I understand the original form is not correct English grammar, although the equivalent is apparently valid in some other languages. As a native English speaker it feels awkward to me, although the meaning is clear. This question & answer <https://english.stackexchange.com/questions/60271/grammatical-complements-for-allow> seem to back me up, but I thought I should get a quick review or second opinion before changing everything.

----------
assignee: docs at python
components: Documentation
files: allows-to.patch
keywords: patch
messages: 259827
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Fix ?allows to <verb>? in documentation
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41845/allows-to.patch

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

From report at bugs.python.org  Mon Feb  8 02:55:47 2016
From: report at bugs.python.org (Mahmoud Hashemi)
Date: Mon, 08 Feb 2016 07:55:47 +0000
Subject: [issue7359] mailbox cannot modify mailboxes in system mail spool
In-Reply-To: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>
Message-ID: <1454918147.67.0.951550766265.issue7359@psf.upfronthosting.co.za>


Mahmoud Hashemi added the comment:

Got bit by this, and since it's not a bug, here's "not" a fix: http://boltons.readthedocs.org/en/latest/mboxutils.html#boltons.mboxutils.mbox_readonlydir

Been in production for a while, working like a charm. Might there be interest in including this in the standard lib?

----------
nosy: +mahmoud

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

From report at bugs.python.org  Mon Feb  8 03:25:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 08:25:01 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzMDRdIEZpeCDigJxhbGxvd3MgdG8gPHZlcmI+4oCdIGluIGRv?=
 =?utf-8?q?cumentation?=
In-Reply-To: <1454918132.41.0.149238322531.issue26304@psf.upfronthosting.co.za>
Message-ID: <1454919901.64.0.116107763339.issue26304@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Feb  8 03:59:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 08:59:48 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzMDRdIEZpeCDigJxhbGxvd3MgdG8gPHZlcmI+4oCdIGluIGRv?=
 =?utf-8?q?cumentation?=
In-Reply-To: <1454918132.41.0.149238322531.issue26304@psf.upfronthosting.co.za>
Message-ID: <1454921987.99.0.81649436217.issue26304@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have read the patch, and it LGTM. At least it does exactly what is declared (and fixes some other minor errors). Thank you Martin.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Mon Feb  8 04:05:27 2016
From: report at bugs.python.org (Kunal Grover)
Date: Mon, 08 Feb 2016 09:05:27 +0000
Subject: [issue26296] colorys rgb_to_hls algorithm error
In-Reply-To: <1454680812.05.0.172060571572.issue26296@psf.upfronthosting.co.za>
Message-ID: <1454922327.08.0.076572419863.issue26296@psf.upfronthosting.co.za>


Kunal Grover added the comment:

This isn't needed. We are taking modulus with 1.0, which already fixes negative values of h.

----------
nosy: +Kunal Grover

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

From report at bugs.python.org  Mon Feb  8 04:37:54 2016
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Feb 2016 09:37:54 +0000
Subject: [issue20109] TestProgram is mentioned in the unittest docs but is not
 documented
In-Reply-To: <1388685707.72.0.688331916968.issue20109@psf.upfronthosting.co.za>
Message-ID: <1454924274.19.0.869072870326.issue20109@psf.upfronthosting.co.za>


Michael Foord added the comment:

TestProgram is an abomination, but it has been publicly exposed in unittest since forever.

----------

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

From report at bugs.python.org  Mon Feb  8 04:46:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 09:46:11 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454924771.34.0.0479393786717.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yury Selivanov:
> Alright, I ran a few benchmarks myself. (...)
> From what I can see there is no negative impact of the patch on stable macro benchmarks.

I'm disappointed by the results. In short, these patches have *no* impact on macro benchmarks, other than the two which are stressing the int and float types. Maybe we are just loosing our time on this issue...

I understand that the patches are only useful to get xx% speedup (where xx% is smaller than 25%) if your whole application is blocked by numeric computations. If it's the case, I would suggest to move to PyPy, Numba, Cython, etc. I expect something more interesting than xx% faster, but a much more impressive speedup.

http://speed.pypy.org/ : PyPy/CPython 2.7 for spectral_norm is 0.04: 25x faster. For nbody (nbody_modified), it's 0.09: 11x faster.

With patches of this issue, the *best* speedup is only 1.16x faster... We are *very* far from 11x or 25x faster. It's not even 2x faster...


Yury Selivanov:
> fastint5 is a very compact patch, that only touches the ceval.c file.  It doesn't complicate the code, as the macro is very straightforward.  Since the patch passed the code review, thorough benchmarking and discussion stages, I'd like to commit it.

According to my micro-benchmark msg259706, inline-2.patch is faster than fastint5_4.patch. I would suggest to "finish" the inline-2.patch to optimize other operations, and *maybe* add fast-path for float.

On macrobenchmark, inline-2.patch is slower than fastint5_4.patch, but it was easy to expect since I only added fast-path for int-int and only for a few operators.

The question is it is worth to get xx% speedup on one or two specific benchmarks where CPython really sucks compared to other languages and other implementations of Python...


Stefan Krah:
> With fastint5_4.patch *on top of #26288* I see no improvement for floats and a big slowdown for _decimal.

How do you run your benchmark?


Case Van Horsen:
> Can I suggest the mpmath test suite as a good benchmark?

Where can we find this benchmark?


Case Van Horsen:
> it has always been a valuable real-world benchmark

What do you mean by "real-world benchmark"? :-)

----------

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

From report at bugs.python.org  Mon Feb  8 04:55:29 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 08 Feb 2016 09:55:29 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454925329.9.0.438871708535.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks Serhiy! I'll keep an eye out for comments on the other patch.

----------

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

From report at bugs.python.org  Mon Feb  8 05:28:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 10:28:48 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <1454927328.34.0.276283624691.issue25698@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agreed. Here is a patch that makes PyImport_AddModule to use PyDict_GetWithError and fail earlier. I think it should be applied in 3.x too.

----------
Added file: http://bugs.python.org/file41846/issue25698_fix_add_module.patch

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

From report at bugs.python.org  Mon Feb  8 06:00:02 2016
From: report at bugs.python.org (Andrew Plummer)
Date: Mon, 08 Feb 2016 11:00:02 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454929202.95.0.31697112754.issue25195@psf.upfronthosting.co.za>


Andrew Plummer added the comment:

Have added a new diff to just use the default __ne__ implementation rather than tuple's.

Have also added a test that targets exactly the reported issue.

----------
Added file: http://bugs.python.org/file41847/test_assert_called_with_any.diff

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

From report at bugs.python.org  Mon Feb  8 06:01:06 2016
From: report at bugs.python.org (Andrew Plummer)
Date: Mon, 08 Feb 2016 11:01:06 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454929266.78.0.941534780876.issue25195@psf.upfronthosting.co.za>


Changes by Andrew Plummer <plummer574 at gmail.com>:


Removed file: http://bugs.python.org/file41847/test_assert_called_with_any.diff

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

From report at bugs.python.org  Mon Feb  8 06:01:19 2016
From: report at bugs.python.org (Andrew Plummer)
Date: Mon, 08 Feb 2016 11:01:19 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454929279.08.0.699883105903.issue25195@psf.upfronthosting.co.za>


Changes by Andrew Plummer <plummer574 at gmail.com>:


Added file: http://bugs.python.org/file41848/fix_mock_call_ne.patch

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

From report at bugs.python.org  Mon Feb  8 06:01:34 2016
From: report at bugs.python.org (Andrew Plummer)
Date: Mon, 08 Feb 2016 11:01:34 +0000
Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object
In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>
Message-ID: <1454929294.83.0.797340713041.issue25195@psf.upfronthosting.co.za>


Changes by Andrew Plummer <plummer574 at gmail.com>:


Removed file: http://bugs.python.org/file41844/fix_mock_call_ne.patch

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

From report at bugs.python.org  Mon Feb  8 06:08:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 11:08:32 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
Message-ID: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes Argument Clinic to generate C code with curly braces as strongly preferred by PEP 7.

----------
components: Demos and Tools
files: clinic_pep7_braces.patch
keywords: patch
messages: 259836
nosy: brett.cannon, larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Make Argument Clinic to generate PEP 7 conforming code
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41849/clinic_pep7_braces.patch

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

From report at bugs.python.org  Mon Feb  8 06:08:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 11:08:58 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>
Message-ID: <1454929738.74.0.584959591351.issue26305@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Argument Clinic

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

From report at bugs.python.org  Mon Feb  8 06:33:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 11:33:32 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>
Message-ID: <1454931212.63.0.624987269563.issue26305@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW I agree with this change. I left one review comment. I presume the important stuff is just in Tools/clinic/clinic.py and the other changes are all generated code.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Mon Feb  8 06:57:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 11:57:19 +0000
Subject: [issue26045] Improve error message for http.client when posting
 unicode string
In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za>
Message-ID: <20160208115716.19985.82172@psf.io>


Roundup Robot added the comment:

New changeset 966bd147ccb5 by Martin Panter in branch '3.5':
Issue #26045: Add UTF-8 suggestion to error in http.client
https://hg.python.org/cpython/rev/966bd147ccb5

New changeset 9896ead3cc1d by Martin Panter in branch 'default':
Issue #26045: Merge http.client error addition from 3.5
https://hg.python.org/cpython/rev/9896ead3cc1d

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 07:19:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Feb 2016 12:19:44 +0000
Subject: [issue26045] Improve error message for http.client when posting
 unicode string
In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za>
Message-ID: <1454933984.3.0.641254922281.issue26045@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 07:21:53 2016
From: report at bugs.python.org (Jack Hargreaves)
Date: Mon, 08 Feb 2016 12:21:53 +0000
Subject: [issue26306] Can't create abstract tuple
Message-ID: <1454934113.76.0.551150355835.issue26306@psf.upfronthosting.co.za>


New submission from Jack Hargreaves:

When creating an abstract class, subclassing tuple causes check for instantiation of an abstract class to be bypassed. See the associated stackoverflow question -- http://stackoverflow.com/questions/35267954/mix-in-of-abstract-class-and-namedtuple

    from abc import abstractmethod, ABCMeta

    class AbstactClass(tuple, metaclass=ABCMeta):

        @abstractmethod
        def some_method(self):
            pass

    # following should throw a TypeError, but doesn't
    AbstactClass()

----------
messages: 259839
nosy: Jack Hargreaves
priority: normal
severity: normal
status: open
title: Can't create abstract tuple
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb  8 07:42:03 2016
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vv?= =?utf-8?q?rgiou=29?=)
Date: Mon, 08 Feb 2016 12:42:03 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1454935323.89.0.0271777405117.issue24915@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) added the comment:

Perhaps I'm missing something obvious here, but?

    ?
    $(MAKE) build_all_merge_profile
    @echo "Rebuilding with profile guided optimizations:"
    $(MAKE) clean
    $(MAKE) build_all_use_profile
    ?

the `$(MAKE) clean` does an `rm -rf build`, so it also removes the .gcda for the builtin modules.

----------
nosy: +tzot

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

From report at bugs.python.org  Mon Feb  8 08:05:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 13:05:29 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454936729.19.0.958345135752.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch is written in the style of current code for tuples.

----------
Added file: http://bugs.python.org/file41850/pybuildvalue_leak3.patch

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

From report at bugs.python.org  Mon Feb  8 08:28:26 2016
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vv?= =?utf-8?q?rgiou=29?=)
Date: Mon, 08 Feb 2016 13:28:26 +0000
Subject: [issue26307] no PGO for built-in modules with `make profile-opt`
Message-ID: <1454938106.72.0.648611247693.issue26307@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou):

(related to issue #24915)
I discovered that `make profile-opt` does not use the profile information for the builtin-modules (e.g. arraymodule or _pickle) because in the `profile-opt` target there is the following sequence of actions:

    ?
    $(MAKE) build_all_merge_profile
    @echo "Rebuilding with profile guided optimizations:"
    $(MAKE) clean
    $(MAKE) build_all_use_profile
    ?

The action `$(MAKE) clean` performs an `rm -rf build`, destroying among other things all the *.gcda files generated for the built-in modules.
On my Linux system with gcc, a kludge to `Makefile.pre.in` that works is:

    ?
    @echo "Rebuilding with profile guided optimizations:"
    find build -name \*.gcda -print | cpio -o >_modules.gcda.cpio # XXX
    $(MAKE) clean
    cpio -id <_modules.gcda.cpio # XXX
    $(MAKE) build_all_use_profile
    ?

but, like I said, it's a kludge and it's POSIX-only (-print0 can be avoided since I believe it's guaranteed that there will be no whitespace-containing-filenames).

Now, if this road is to be taken, I believe the most cross-platform method available to save the profile-generated files is to use a custom python script (at this point, the local profile-generating python executable is functional) and make a tar file, which will be untared back. However, I don't like it much.

I'm willing to provide any necessary patches if someone gives me a "proper" roadmap as to how to handle this issue.

----------
components: Build
messages: 259842
nosy: tzot
priority: normal
severity: normal
status: open
title: no PGO for built-in modules with `make profile-opt`
type: performance
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Feb  8 08:47:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 13:47:18 +0000
Subject: [issue26167] Improve copy.copy speed for built-in types
 (list/set/dict)
In-Reply-To: <1453313258.69.0.822432262864.issue26167@psf.upfronthosting.co.za>
Message-ID: <1454939238.19.0.0792408119537.issue26167@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here are results of microbenchmarks (time in microseconds).

                                copy             deepcopy
                         unpatched patched unpatched   patched

()                           0.993    1.02      5.25      5.38
[]                            1.53    1.12      4.81      5.08
set()                         1.47    1.21      24.6      18.3
frozenset()                  0.991       1      23.4      16.7
{}                            1.59    1.19      5.24      5.45
bytearray()                   8.76    1.11      17.5      11.2
slice(1,10,2)                 7.94       1        23      18.7
NotImplemented                4.75       1      5.82      2.09

tuple(range(10))             0.975    1.01      26.1      26.6
list(range(10))               1.92    1.33      25.7      25.8
set(range(10))                2.17    1.94      47.6      40.6
frozenset(range(10))         0.973       1      47.3      40.3
dict.fromkeys(range(10))      2.19    1.87      43.1      44.8
bytearray(range(10))          10.5    1.17      21.8      17.4

tuple(range(1000))           0.967    1.01  1.97e+03  2.07e+03
list(range(1000))             5.74    5.53  2.02e+03  1.98e+03
set(range(1000))              20.5    20.9  2.15e+03  2.06e+03
frozenset(range(1000))       0.973   0.995  2.14e+03  2.06e+03
dict.fromkeys(range(1000))    49.6    49.3   3.8e+03  3.92e+03
bytearray(range(10))*100      11.5    1.47      23.5      18.9

----------

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

From report at bugs.python.org  Mon Feb  8 08:48:18 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 08 Feb 2016 13:48:18 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1454939298.76.0.390085078063.issue26285@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I attached the list for CPython3 (gc-removed-zones-cpython3.txt), but now split in two sections (core and parser), for more clarity as from what and where it is removed. As you can see, the reason why the module works is because the API that can be used by modules remains untouched.

What I was trying to say and prove before is that these GCC/LD flags are safe to use in CPython (and for any other software project) and will not break any compatibility with existing or future modules.

----------
Added file: http://bugs.python.org/file41851/gc-removed-zones-cpython3.txt

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

From report at bugs.python.org  Mon Feb  8 08:58:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 13:58:04 +0000
Subject: [issue26298] Split ceval.c into small files
In-Reply-To: <1454694194.19.0.667828891375.issue26298@psf.upfronthosting.co.za>
Message-ID: <1454939884.27.0.77096312925.issue26298@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok. At least I tried :-) With 3 strongs -1 votes, and no positive vote, I abandon my change.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 09:07:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 14:07:39 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1454940459.18.0.197371413384.issue25911@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Mon Feb  8 09:24:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 14:24:40 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <20160208142437.15927.95648@psf.io>


Roundup Robot added the comment:

New changeset 5310f94772f4 by Serhiy Storchaka in branch '3.5':
Issue #25911: Restored support of bytes paths in os.walk() on Windows.
https://hg.python.org/cpython/rev/5310f94772f4

New changeset b060af2a58b6 by Serhiy Storchaka in branch 'default':
Issue #25911: Restored support of bytes paths in os.walk() on Windows.
https://hg.python.org/cpython/rev/b060af2a58b6

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 09:32:09 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Mon, 08 Feb 2016 14:32:09 +0000
Subject: [issue26306] Can't create abstract tuple
In-Reply-To: <1454934113.76.0.551150355835.issue26306@psf.upfronthosting.co.za>
Message-ID: <1454941929.95.0.180519452334.issue26306@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

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

From report at bugs.python.org  Mon Feb  8 09:33:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 14:33:39 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1454942019.26.0.470607405213.issue25911@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 5310f94772f4 by Serhiy Storchaka in branch '3.5':
> Issue #25911: Restored support of bytes paths in os.walk() on Windows.
> https://hg.python.org/cpython/rev/5310f94772f4
> 
> New changeset b060af2a58b6 by Serhiy Storchaka in branch 'default':
> Issue #25911: Restored support of bytes paths in os.walk() on Windows.
> https://hg.python.org/cpython/rev/b060af2a58b6

While this change is ok for Python 3.5, I would prefer to *drop* support for bytes filenames on Windows. I started a thread on python-dev for that:
https://mail.python.org/pipermail/python-dev/2016-February/143150.html

----------

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

From report at bugs.python.org  Mon Feb  8 09:34:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 14:34:51 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1454942091.33.0.526477035287.issue25911@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Bastien:
> In py3.4 and below we used to be able to use bytes filenames with os.walk(), it?s now impossible under windows due to the limitation of os.scandir().
>
> This issue was reported to Blender tracker (https://developer.blender.org/T47018).

Again, why do you use bytes? Blender only supports Python 3. You must use Unicode on all platforms. On Windows, it gives you support of the full Unicode character set for free.

----------

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

From report at bugs.python.org  Mon Feb  8 09:39:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 14:39:36 +0000
Subject: [issue25949] Lazy creation of __dict__ in OrderedDict
In-Reply-To: <1451047688.41.0.0988158472157.issue25949@psf.upfronthosting.co.za>
Message-ID: <20160208143925.1556.20940@psf.io>


Roundup Robot added the comment:

New changeset caab6b356a9e by Serhiy Storchaka in branch 'default':
Issue #25949: __dict__ for an OrderedDict instance is now created only when
https://hg.python.org/cpython/rev/caab6b356a9e

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 09:40:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 14:40:06 +0000
Subject: [issue25949] Lazy creation of __dict__ in OrderedDict
In-Reply-To: <1451047688.41.0.0988158472157.issue25949@psf.upfronthosting.co.za>
Message-ID: <1454942406.11.0.429486504288.issue25949@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 09:41:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 14:41:36 +0000
Subject: [issue26117] Close directory descriptor in scandir iterator on error
In-Reply-To: <1452809422.76.0.117373240485.issue26117@psf.upfronthosting.co.za>
Message-ID: <1454942496.89.0.395122863539.issue26117@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review?

----------

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

From report at bugs.python.org  Mon Feb  8 09:48:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 14:48:20 +0000
Subject: [issue26117] Close directory descriptor in scandir iterator on error
In-Reply-To: <1452809422.76.0.117373240485.issue26117@psf.upfronthosting.co.za>
Message-ID: <1454942900.32.0.565337286255.issue26117@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Could anyone please make a review?

Done. Enjoy :-)

----------

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

From report at bugs.python.org  Mon Feb  8 10:07:00 2016
From: report at bugs.python.org (Georg Sauthoff)
Date: Mon, 08 Feb 2016 15:07:00 +0000
Subject: [issue26308] Solaris 10 build issues
Message-ID: <1454944020.19.0.240398292442.issue26308@psf.upfronthosting.co.za>


New submission from Georg Sauthoff:

When building on Solaris 10 I had to patch

Modules/_posixsubprocess.c -> dirfd issues
Modules/socketmodule.c -> sethostname declaration
setup.py -> ncurses detection

See the attached patch for details.

I built it like this:

CC=gcc CXX=g++ LDFLAGS="-m64 -L/opt/csw/lib/64 -R/opt/csw/lib/64" CPPFLAGS="-I/opt/csw/include -I/opt/csw/include/ncursesw" CFLAGS="-m64 -D_XOPEN_SOURCE=600 -std=gnu99" CXXFLAGS="-m64" ./configure --prefix=/usr/local/python-3.5.1

Note that /opt/csw/ is popular open source repository for Solaris 10; it is the first place to go to get relatively recent stuff like gcc 4.9 etc.

The first 2 hunks of the patch aren't very controversial, I guess. The Solaris-ncurses detection can be done in several ways, of course.

Also, one could change ncurses package build such that the global CFLAGS (especially -D_XOPEN_SOURCE=600) are picked up.

Another variation - the configure could try to detect if _XOPEN_SOURCE=600 is supported and - in case it is  - automatically set it.

----------
components: Build
files: python-3.5.1-solaris10.diff
keywords: patch
messages: 259852
nosy: gms
priority: normal
severity: normal
status: open
title: Solaris 10 build issues
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file41852/python-3.5.1-solaris10.diff

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

From report at bugs.python.org  Mon Feb  8 10:28:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 15:28:07 +0000
Subject: [issue25776] More compact pickle of iterators etc
In-Reply-To: <1449052155.68.0.447852149746.issue25776@psf.upfronthosting.co.za>
Message-ID: <1454945287.65.0.897615559306.issue25776@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file41207/iterators_pickle.diff

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

From report at bugs.python.org  Mon Feb  8 10:40:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 15:40:40 +0000
Subject: [issue25776] More compact pickle of iterators etc
In-Reply-To: <1449052155.68.0.447852149746.issue25776@psf.upfronthosting.co.za>
Message-ID: <1454946040.54.0.265961373711.issue25776@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch extends tests for pickling iterators of mutable sequences. Now tested iterators in different states: initial (no iterated yet), running (in the middle of iteration), empty (just the last item was emitted) and exhausted (tried to iterate past the end).

----------
Added file: http://bugs.python.org/file41853/iterators_pickle_tests.patch

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

From report at bugs.python.org  Mon Feb  8 10:44:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 15:44:24 +0000
Subject: [issue25776] More compact pickle of iterators etc
In-Reply-To: <1449052155.68.0.447852149746.issue25776@psf.upfronthosting.co.za>
Message-ID: <1454946264.99.0.119106386575.issue25776@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch conforms to new tests and to following rule: exhausted iterators of mutable sequences can be replaced with iter(()), non-exhausted iterators can't.

----------
Added file: http://bugs.python.org/file41854/iterators_pickle_2.patch

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

From report at bugs.python.org  Mon Feb  8 10:45:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 15:45:00 +0000
Subject: [issue25776] More compact pickle of iterators etc
In-Reply-To: <1449052155.68.0.447852149746.issue25776@psf.upfronthosting.co.za>
Message-ID: <1454946300.13.0.58868461974.issue25776@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file41853/iterators_pickle_tests.patch

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

From report at bugs.python.org  Mon Feb  8 10:47:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 15:47:10 +0000
Subject: [issue25776] More compact pickle of iterators etc
In-Reply-To: <1449052155.68.0.447852149746.issue25776@psf.upfronthosting.co.za>
Message-ID: <1454946430.69.0.474724077584.issue25776@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, I already proposed tests in separate issue.

Raymond, could you please look at patches? The touch the code maintained by you: itertools and deque.

----------

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

From report at bugs.python.org  Mon Feb  8 10:57:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 15:57:56 +0000
Subject: [issue26117] Close directory descriptor in scandir iterator on error
In-Reply-To: <1452809422.76.0.117373240485.issue26117@psf.upfronthosting.co.za>
Message-ID: <20160208155752.11221.14003@psf.io>


Roundup Robot added the comment:

New changeset 8ec721bb3027 by Serhiy Storchaka in branch '3.5':
Issue #26117: The os.scandir() iterator now closes file descriptor not only
https://hg.python.org/cpython/rev/8ec721bb3027

New changeset ec12fbf449a5 by Serhiy Storchaka in branch 'default':
Issue #26117: The os.scandir() iterator now closes file descriptor not only
https://hg.python.org/cpython/rev/ec12fbf449a5

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 10:59:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 15:59:36 +0000
Subject: [issue26117] Close directory descriptor in scandir iterator on error
In-Reply-To: <1452809422.76.0.117373240485.issue26117@psf.upfronthosting.co.za>
Message-ID: <1454947176.3.0.0787974132668.issue26117@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 10:59:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 15:59:59 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <1454947199.34.0.227682621116.issue25995@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Mon Feb  8 11:15:15 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 08 Feb 2016 16:15:15 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzMDRdIEZpeCDigJxhbGxvd3MgdG8gPHZlcmI+4oCdIGluIGRv?=
 =?utf-8?q?cumentation?=
In-Reply-To: <1454918132.41.0.149238322531.issue26304@psf.upfronthosting.co.za>
Message-ID: <1454948115.7.0.270886720588.issue26304@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I agree that the "to xxx" changes look good. And the handful of other corrections look good, too.

I left a review comment with one typo I found.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Mon Feb  8 11:26:44 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Feb 2016 16:26:44 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1454948804.95.0.953443331837.issue26200@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> And I had no one voice for separate macros (except my).

Sorry I wasn't in the conversation to back you up.

> I tried to not replace a Py_DECREF with a Py_SETREF 
> in performance critical code (e.g. in PyDict_SetItem).

If you don't mind, I would like to restore the Py_DECREF in deque_ass_item().

----------

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

From report at bugs.python.org  Mon Feb  8 11:30:16 2016
From: report at bugs.python.org (Case Van Horsen)
Date: Mon, 08 Feb 2016 16:30:16 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454949016.21.0.440488823106.issue21955@psf.upfronthosting.co.za>


Case Van Horsen added the comment:

mpmath is a library for arbitrary-precision floating-point arithmetic. It uses Python's native long type or gmpy2's mpz type for computations. It is available at https://pypi.python.org/pypi/mpmath.

The test suite can be run directly from the source tree. The test suite includes timing information for individual tests and for the the entire test. Sample invocation:

~/src/mpmath-0.19/mpmath/tests$ time py36 runtests.py -local

For example, I've tried to optimize gmpy2's handling of binary operations between its mpz type and short Python integers. I've found it to provide useful results: improvements that are significant on a micro-benchmark (say 20%) will usually cause a small but repeatable improvement. And some improvements that looked good on a micro-benchmark would slow down mpmath.

I ran the mpmath test suite with Python 3.6 and with the fastint6 patch. The overall increase when using Python long type was about 1%. When using gmpy2's mpz type, there was a slowdown of about 2%.

I will run more tests tonight.

----------

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

From report at bugs.python.org  Mon Feb  8 11:40:24 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 16:40:24 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1454949624.18.0.226012627795.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I ran the mpmath test suite with Python 3.6 and with the fastint6 patch. The overall increase when using Python long type was about 1%. When using gmpy2's mpz type, there was a slowdown of about 2%.

> I will run more tests tonight.

Please try to test fastint5 too (fast paths for long & floats, whereas fastint6 is only focused on longs).

----------

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

From report at bugs.python.org  Mon Feb  8 11:58:33 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Mon, 08 Feb 2016 16:58:33 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock() don't
 shutdwon request if verify_request is False
Message-ID: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

When socketserver.BaseServer.verify_request() return False then we do not call shutdown_request. If we will take the TCPServer as example we will call get_request thus calling socket.accept() and creating a new socket but we will not call shutdown_request to close the unused socket.

----------
components: Library (Lib)
files: socketserver-shutdown-if-verify-false.patch
keywords: patch
messages: 259861
nosy: palaviv
priority: normal
severity: normal
status: open
title: socketserver.BaseServer._handle_request_noblock() don't shutdwon request if verify_request is False
type: resource usage
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41855/socketserver-shutdown-if-verify-false.patch

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

From report at bugs.python.org  Mon Feb  8 12:12:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 17:12:07 +0000
Subject: [issue26204] compiler: ignore constants used as statements? (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <20160208171202.1558.35718@psf.io>


Roundup Robot added the comment:

New changeset a0d053899ff8 by Victor Stinner in branch 'default':
Simplify main() of test_ast
https://hg.python.org/cpython/rev/a0d053899ff8

New changeset bcf27fa55632 by Victor Stinner in branch 'default':
Replace noop constant statement with expression
https://hg.python.org/cpython/rev/bcf27fa55632

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 12:20:00 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Mon, 08 Feb 2016 17:20:00 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock() don't
 shutdwon request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1454952000.49.0.63987710823.issue26309@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Had a small mistake in the previous patch (did not notice process_request) call shutdown_request.

fixed the patch

----------
Added file: http://bugs.python.org/file41856/socketserver-shutdown-if-verify-false2.patch

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

From report at bugs.python.org  Mon Feb  8 12:23:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 17:23:07 +0000
Subject: [issue26204] compiler: ignore constants used as statements? (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1454952187.55.0.13224426086.issue26204@psf.upfronthosting.co.za>


STINNER Victor added the comment:

changeset:   100192:4bdb21380743
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Mon Feb 08 18:17:58 2016 +0100
files:       Lib/test/test_ast.py Lib/test/test_code.py Lib/test/test_grammar.py Misc/NEWS Python/compile.c
description:
compiler now ignores constant statements

The compile ignores constant statements and emit a SyntaxWarning warning.

Don't emit the warning for string statement because triple quoted string is a
common syntax for multiline comments.

Don't emit the warning on ellipis neither: 'def f(): ...' is a legit syntax for
abstract functions.

Changes:

* test_ast: ignore SyntaxWarning when compiling test statements. Modify
  test_load_const() to use assignment expressions rather than constant
  expression.
* test_code: add more kinds of constant statements, ignore SyntaxWarning when
  testing that the compiler removes constant statements.
* test_grammar: ignore SyntaxWarning on the statement "1"

----------

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

From report at bugs.python.org  Mon Feb  8 12:27:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 17:27:38 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1454952458.39.0.189676952496.issue26204@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I changed my patch to emit a SyntaxWarning. If too many users complain of the warning, maybe we can remove it. IMHO it's useful to detect bugs.

----------
resolution:  -> fixed
status: open -> closed
title: compiler: ignore constants used as statements? (don't emit LOAD_CONST+POP_TOP) -> compiler: ignore constants used as statements (don't emit LOAD_CONST+POP_TOP)

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

From report at bugs.python.org  Mon Feb  8 12:35:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 17:35:41 +0000
Subject: [issue26117] Close directory descriptor in scandir iterator on error
In-Reply-To: <1454947176.33.0.0646238517937.issue26117@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaXQipKz9oGQJcKSdmpH86hL0LNAWnhKu_xaCOmF0dwxw@mail.gmail.com>


STINNER Victor added the comment:

Thanks for the fix Serhiy ;-)

----------

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

From report at bugs.python.org  Mon Feb  8 12:41:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 17:41:33 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1454953293.35.0.837074969356.issue25994@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch adds the close() methon and the support of the context manager protocol for the os.scandir class.

----------
keywords: +patch
stage:  -> patch review
versions:  -Python 3.5
Added file: http://bugs.python.org/file41857/scandir_close.patch

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

From report at bugs.python.org  Mon Feb  8 12:52:50 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 08 Feb 2016 17:52:50 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1454953970.97.0.286270166759.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Hello and thank you for your feedback. For CPython this does not apply because due to the structure of the build system, inside the "build" directory there are no PGO profiles saved. You can run find . -name '*.gc??' to see.

----------

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

From report at bugs.python.org  Mon Feb  8 13:06:44 2016
From: report at bugs.python.org (Marien)
Date: Mon, 08 Feb 2016 18:06:44 +0000
Subject: =?utf-8?q?=5Bissue26310=5D_Fix_typo_=E2=80=9Cvariariables=E2=80=9D_in_soc?=
 =?utf-8?q?ketserver=2Epy?=
Message-ID: <1454954804.39.0.970337231827.issue26310@psf.upfronthosting.co.za>


New submission from Marien:

This patch fixes a typo in socketserver.py

----------
assignee: docs at python
components: Documentation
files: fix-typo-variariables.patch
keywords: patch
messages: 259869
nosy: docs at python, marienfr
priority: normal
severity: normal
status: open
title: Fix typo ?variariables? in socketserver.py
Added file: http://bugs.python.org/file41858/fix-typo-variariables.patch

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

From report at bugs.python.org  Mon Feb  8 13:10:08 2016
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vv?= =?utf-8?q?rgiou=29?=)
Date: Mon, 08 Feb 2016 18:10:08 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1454955008.95.0.100848407546.issue24915@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) added the comment:

There are. (Check issue #26307 that explains this cpio file. This is a x32 build of Python, because the memory savings are very welcome for the multiple worker processes of a project I work on.)

$ cpio -it <_modules.gcda.cpio
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_multiprocessing/semaphore.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_multiprocessing/multiprocessing.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_posixsubprocess.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_struct.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_heapqmodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_opcode.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/binascii.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_ssl.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/arraymodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_pickle.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_randommodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_hashopenssl.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_lzmamodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/grpmodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/socketmodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/selectmodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_math.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/mathmodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_datetimemodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/resource.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/zlibmodule.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/unicodedata.gcda
build/temp.linux-x86_64-3.5/opt/x32/src/Python-3.5.1/Modules/_testcapimodule.gcda

----------

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

From report at bugs.python.org  Mon Feb  8 13:28:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 18:28:48 +0000
Subject: [issue25983] Add tests for multi-argument type()
In-Reply-To: <1451575944.98.0.12158451128.issue25983@psf.upfronthosting.co.za>
Message-ID: <20160208182845.2657.85071@psf.io>


Roundup Robot added the comment:

New changeset f9bd6ddb6ba4 by Serhiy Storchaka in branch '2.7':
Issue #25983: Added tests for multi-argument type().
https://hg.python.org/cpython/rev/f9bd6ddb6ba4

New changeset 0e7aabe76159 by Serhiy Storchaka in branch '3.5':
Issue #25983: Added tests for multi-argument type().
https://hg.python.org/cpython/rev/0e7aabe76159

New changeset f494052eb476 by Serhiy Storchaka in branch 'default':
Issue #25983: Added tests for multi-argument type().
https://hg.python.org/cpython/rev/f494052eb476

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 13:30:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 18:30:38 +0000
Subject: [issue25983] Add tests for multi-argument type()
In-Reply-To: <1451575944.98.0.12158451128.issue25983@psf.upfronthosting.co.za>
Message-ID: <1454956238.75.0.129292602306.issue25983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks for your review Brett. I have landed tests in test_builtins.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 13:44:43 2016
From: report at bugs.python.org (=?utf-8?b?UmHDumwgTsO6w7FleiBkZSBBcmVuYXM=?=)
Date: Mon, 08 Feb 2016 18:44:43 +0000
Subject: [issue26311] Typo in documentation for xml.parsers.expat
Message-ID: <1454957083.56.0.365121544419.issue26311@psf.upfronthosting.co.za>


New submission from Ra?l N??ez de Arenas:

At https://docs.python.org/3.5/library/pyexpat.html#module-xml.parsers.expat.model the docs say "Content modules are described using nested tuples.

It should say "Content models are described using nested tuples."

I've checked docs for version 3.6.0a and the typo is there, too.

----------
components: XML
messages: 259873
nosy: Ra?l N??ez de Arenas
priority: normal
severity: normal
status: open
title: Typo in documentation for xml.parsers.expat
versions: Python 3.5

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

From report at bugs.python.org  Mon Feb  8 13:46:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 18:46:29 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1454957189.74.0.865342825012.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry, I didn't considered the deque as essential class. Please do. Py_SETREF here only saved 3 lines of code.

----------

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

From report at bugs.python.org  Mon Feb  8 13:52:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 18:52:02 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1454957522.84.0.0879888459148.issue25911@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 13:53:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 18:53:30 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454957610.89.0.229953565375.issue26198@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 14:08:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 19:08:06 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1454958486.88.0.425629115599.issue25985@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review? We should solve this issue before releasing 3.10.

----------

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

From report at bugs.python.org  Mon Feb  8 14:14:47 2016
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Feb 2016 19:14:47 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1454958887.9.0.657937454882.issue26204@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Shouldn't the message be "constant statement ignored"?  The current wording reads strange to me.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Mon Feb  8 14:24:49 2016
From: report at bugs.python.org (John Mark Vandenberg)
Date: Mon, 08 Feb 2016 19:24:49 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1454959489.27.0.459796721222.issue26204@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +jayvdb

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

From report at bugs.python.org  Mon Feb  8 14:39:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 19:39:33 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
Message-ID: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now programmical errors with the use of PyArg_ParseTuple() cause raising SystemError. But some programmical errors with the use of PyArg_ParseTupleAndKeywords() cause raising RuntimeError. I think that SystemError is the correct exception type.

Proposed patch replaces RuntimeError with SystemError in PyArg_ParseTupleAndKeywords(). This change shouldn't break any code (except CPython tests for PyArg_ParseTupleAndKeywords()), because this exception never raised if PyArg_Parse*() functions are used correctly.

----------
components: Interpreter Core
files: pyarg_parse_error.patch
keywords: patch
messages: 259877
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Raise SystemError on programmical errors in PyArg_Parse*()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41859/pyarg_parse_error.patch

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

From report at bugs.python.org  Mon Feb  8 14:45:13 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 08 Feb 2016 19:45:13 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1454960713.2.0.938980636669.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

That's interesting. Even on CPython3, I still don't see any gcda's inside the build directory, nor the tree structure you are seeing there. Can you please give me a couple of details regarding your environment (os, distribution, gcc version, 32/64 bit, cross compilation, etc)? 

If this is a general issue, I can add another patch to fix it.

----------

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

From report at bugs.python.org  Mon Feb  8 15:03:16 2016
From: report at bugs.python.org (Andrew Plummer)
Date: Mon, 08 Feb 2016 20:03:16 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1454961796.12.0.364266870441.issue25985@psf.upfronthosting.co.za>


Andrew Plummer added the comment:

On a related note, I think that https://hg.python.org/cpython/file/tip/Makefile.pre.in#l571 should get the same treatment.

----------
nosy: +aplummer

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

From report at bugs.python.org  Mon Feb  8 15:09:48 2016
From: report at bugs.python.org (Jonathan Kamens)
Date: Mon, 08 Feb 2016 20:09:48 +0000
Subject: [issue26313] ssl.py _load_windows_store_certs fails if windows cert
 store is empty
Message-ID: <1454962188.81.0.985392423363.issue26313@psf.upfronthosting.co.za>


New submission from Jonathan Kamens:

In ssl.py:

    def _load_windows_store_certs(self, storename, purpose):
        certs = bytearray()
        for cert, encoding, trust in enum_certificates(storename):
            # CA certs are never PKCS#7 encoded                                 
            if encoding == "x509_asn":
                if trust is True or purpose.oid in trust:
                    certs.extend(cert)
        self.load_verify_locations(cadata=certs)
        return certs

The line right before the return statement will raise an exception if certs is empty.

It should be protected with "if certs:" as it is elsewhere in this file.

----------
components: Windows
messages: 259880
nosy: Jonathan Kamens, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ssl.py _load_windows_store_certs fails if windows cert store is empty
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  8 15:16:32 2016
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vv?= =?utf-8?q?rgiou=29?=)
Date: Mon, 08 Feb 2016 20:16:32 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1454962592.94.0.934467452612.issue24915@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) added the comment:

First, let's make sure we're on the same page.

- These files are created during the `$(MAKE) run_profile_task` stage.
- They get removed during the `$(MAKE) clean` stage, along with the build directory.
- The build directory gets recreated during the `$(MAKE) build_all_use_profile` stage, without any .gcda files this time.

So you won't see these files after a successful build *if* you haven't taken measures to ensure they are saved during the build process. I save these files to a cpio file *before* `make clean` runs and restore them right afterwards.
I suggest you modify `Makefile.pre.in` to include similar commands to the ones I mention in issue #23607 to verify whether your system creates these files or not.

Now, for the info you required:

It's a system running Ubuntu 14.04 64-bit with gcc 4.8.4. It's a build of Python with the `-mx32` flag, along with all required libraries for the needs of a specific project. (I think that the `-mx32` flag is not important to our discussion here though.) It isn't a cross-compilation.

----------

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

From report at bugs.python.org  Mon Feb  8 15:18:10 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 08 Feb 2016 20:18:10 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1454962690.52.0.688327367066.issue25985@psf.upfronthosting.co.za>


SilentGhost added the comment:

> On a related note, I think that https://hg.python.org/cpython/file/tip/Makefile.pre.in#l571 should get the same treatment.

Agree, that should be included in the patch.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Mon Feb  8 15:29:43 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 08 Feb 2016 20:29:43 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1454963383.82.0.637338895726.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

For my responses, I modified locally the Makefile so that it will not remove the build directory and any of the gcda files. I will make some more tests tomorrow, but i think that this problem will solve simpler if the removal of the build directory is deleted and all the profile info is kept.

----------

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

From report at bugs.python.org  Mon Feb  8 15:30:24 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 08 Feb 2016 20:30:24 +0000
Subject: [issue26307] no PGO for built-in modules with `make profile-opt`
In-Reply-To: <1454938106.72.0.648611247693.issue26307@psf.upfronthosting.co.za>
Message-ID: <1454963424.69.0.129071809338.issue26307@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
nosy: +alecsandru.patrascu

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

From report at bugs.python.org  Mon Feb  8 15:35:47 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 08 Feb 2016 20:35:47 +0000
Subject: [issue26307] no PGO for built-in modules with `make profile-opt`
In-Reply-To: <1454938106.72.0.648611247693.issue26307@psf.upfronthosting.co.za>
Message-ID: <1454963747.73.0.558455196406.issue26307@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Thank you for noticing and signaling this issue. Since I proposed the PGO patches, I will fix it in another patch, as I don't want it to break any builds.

----------

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

From report at bugs.python.org  Mon Feb  8 15:42:46 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Feb 2016 20:42:46 +0000
Subject: [issue26314] interned strings are stored in a dict,
 a set would use less memory
Message-ID: <1454964166.73.0.652183434251.issue26314@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The implementation of string interning uses a dict [1].  It would consume less memory and be a bit simpler if it used a set.

Identifier strings in a program are interned.  If you have a large program with a lot of code, this makes for a large dictionary.

Experimenting with changing this to use a set on 2.7 found ~22k savings on an interactive interpreter startup.  Measuring it on a huge application showed a few hundred k saved.

[1]: https://hg.python.org/cpython/file/3.5/Objects/unicodeobject.c#l1579

----------
messages: 259885
nosy: gregory.p.smith, nnorwitz
priority: low
severity: normal
stage: needs patch
status: open
title: interned strings are stored in a dict, a set would use less memory
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Feb  8 15:49:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Feb 2016 20:49:52 +0000
Subject: [issue26314] interned strings are stored in a dict,
 a set would use less memory
In-Reply-To: <1454964166.73.0.652183434251.issue26314@psf.upfronthosting.co.za>
Message-ID: <1454964592.53.0.319946330108.issue26314@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger

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

From report at bugs.python.org  Mon Feb  8 16:13:53 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 21:13:53 +0000
Subject: [issue26288] Optimize PyLong_AsDouble for single-digit longs
In-Reply-To: <1454637300.25.0.0795862049025.issue26288@psf.upfronthosting.co.za>
Message-ID: <1454966033.12.0.405404967512.issue26288@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I'm not sure why this issue is open... Closing it.

----------
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 16:17:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 21:17:21 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454966241.29.0.111032212883.issue26182@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Assigning the issue to myself to make sure it won't be forgotten before it's too late.  Anish or Marco, feel free to propose a patch.

----------
assignee:  -> yselivanov
stage:  -> needs patch
versions:  -Python 3.5

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

From report at bugs.python.org  Mon Feb  8 16:23:04 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Mon, 08 Feb 2016 21:23:04 +0000
Subject: [issue26314] interned strings are stored in a dict,
 a set would use less memory
In-Reply-To: <1454964166.73.0.652183434251.issue26314@psf.upfronthosting.co.za>
Message-ID: <1454966584.56.0.762135994585.issue26314@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

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

From report at bugs.python.org  Mon Feb  8 16:26:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 21:26:51 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1454966241.29.0.111032212883.issue26182@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY4PP7V9qX=4zPSh0Wif5Uu4Onw+QUi3d6zg4Fs_hHKcw@mail.gmail.com>


STINNER Victor added the comment:

Can you please mention the python version in the title?

----------

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

From report at bugs.python.org  Mon Feb  8 16:29:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Feb 2016 21:29:04 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454966944.22.0.142762786921.issue26182@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
title: Deprecation warnings for the future async and await keywords -> Deprecation warnings for the future async and await keywords in Python 3.6

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

From report at bugs.python.org  Mon Feb  8 16:33:29 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 21:33:29 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1454967209.16.0.170705634625.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Serhiy, Victor, thanks for the review. Attaching an updated version of the patch.

----------
Added file: http://bugs.python.org/file41860/floor_div_2.patch

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

From report at bugs.python.org  Mon Feb  8 16:47:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Feb 2016 21:47:54 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <20160208214748.6669.59270@psf.io>


Roundup Robot added the comment:

New changeset 15531b10976c by Victor Stinner in branch 'default':
compiler: don't emit SyntaxWarning on const stmt
https://hg.python.org/cpython/rev/15531b10976c

----------

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

From report at bugs.python.org  Mon Feb  8 17:01:09 2016
From: report at bugs.python.org (Leonardo Santagada)
Date: Mon, 08 Feb 2016 22:01:09 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1454968869.43.0.856361591802.issue26110@psf.upfronthosting.co.za>


Changes by Leonardo Santagada <santagada at gmail.com>:


----------
nosy: +santagada

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

From report at bugs.python.org  Mon Feb  8 17:07:54 2016
From: report at bugs.python.org (Aaron Meurer)
Date: Mon, 08 Feb 2016 22:07:54 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1454969274.72.0.205110182131.issue26204@psf.upfronthosting.co.za>


Changes by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +Aaron.Meurer

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

From report at bugs.python.org  Mon Feb  8 17:14:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 22:14:22 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1454969662.37.0.459765772989.issue25994@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Context manager protocol, close() method: it looks more and more like a file. In this case, I suggest to emit a ResourceWarning in the destructor if it's not closed explicitly. It mean that the scandir() must always be used with "with" or at least that close() is always closed.

We probably need to update the code to be more explicitly on that.

----------

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

From report at bugs.python.org  Mon Feb  8 17:16:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 22:16:20 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1454969780.96.0.268607391837.issue26182@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh thank. I didn't understand if you wanted to change Python 3.6 or 3.7.

----------

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

From report at bugs.python.org  Mon Feb  8 17:18:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 22:18:52 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1454969932.32.0.614647136771.issue26289@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This change looks related to the issue #21955. IMHO we should take the same decision. I mean, maybe it's better to implement the fast-path only in ceval.c? Or maybe in ceval.c and longobject.c?

----------

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

From report at bugs.python.org  Mon Feb  8 17:20:08 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Feb 2016 22:20:08 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1454970008.06.0.197422413695.issue25300@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For the record, the llvm-dev is currently having a discussion thread about MPX. Some of the feedback is a bit critical:
http://lists.llvm.org/pipermail/llvm-dev/2016-February/094828.html

Also this quite comprehensive report:
https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions

----------

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

From report at bugs.python.org  Mon Feb  8 17:20:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 22:20:42 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1454970042.92.0.00959742706627.issue26204@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Shouldn't the message be "constant statement ignored"?  The current wording reads strange to me.

I removed the warning ;)

----------

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

From report at bugs.python.org  Mon Feb  8 17:23:09 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 22:23:09 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1454970189.02.0.381417112258.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

There is no drastic difference on where you implement the fast path.  I'd implement all specializations/optimizations in longobject.c and optimize ceval to call slots directly.  That way, the implact on ceval performance would be minimal.

----------

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

From report at bugs.python.org  Mon Feb  8 17:31:15 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 22:31:15 +0000
Subject: [issue26315] Optimize mod division for ints
Message-ID: <1454970675.84.0.301967594836.issue26315@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The attached patch implements fast path for modulo division of single digit longs.

Some timeit micro-benchmarks: 

-m timeit -s "x=22331" "x%2;x%3;x%4;x%5;x%6;x%7;x%8;x%99;x%100;"
with patch: 0.213 usec
without patch: 0.602 usec

----------
assignee: yselivanov
components: Interpreter Core
files: mod_div.patch
keywords: patch
messages: 259897
nosy: haypo, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize mod division for ints
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41861/mod_div.patch

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

From report at bugs.python.org  Mon Feb  8 17:35:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Feb 2016 22:35:45 +0000
Subject: [issue26315] Optimize mod division for ints
In-Reply-To: <1454970675.84.0.301967594836.issue26315@psf.upfronthosting.co.za>
Message-ID: <1454970945.63.0.595733916859.issue26315@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #21955.

----------

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

From report at bugs.python.org  Mon Feb  8 17:36:50 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 22:36:50 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1454971010.38.0.31914429333.issue26289@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file41862/floor_div_3.patch

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

From report at bugs.python.org  Mon Feb  8 17:40:39 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 08 Feb 2016 22:40:39 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1454971239.95.0.266131078725.issue26289@psf.upfronthosting.co.za>


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


----------
assignee:  -> yselivanov

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

From report at bugs.python.org  Mon Feb  8 18:39:31 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 08 Feb 2016 23:39:31 +0000
Subject: [issue26314] interned strings are stored in a dict,
 a set would use less memory
In-Reply-To: <1454964166.73.0.652183434251.issue26314@psf.upfronthosting.co.za>
Message-ID: <1454974771.34.0.333308118487.issue26314@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Presumably it would involve using private set APIs to make this work, right? Since normally you can't look up the actual value in a set, just check for existence?

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Feb  8 18:52:01 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Feb 2016 23:52:01 +0000
Subject: [issue26314] interned strings are stored in a dict,
 a set would use less memory
In-Reply-To: <1454964166.73.0.652183434251.issue26314@psf.upfronthosting.co.za>
Message-ID: <1454975521.39.0.047123467856.issue26314@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Here's an example patch against 2.7 by nnorwitz that we're currently testing.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file41863/interned_set_27.diff

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

From report at bugs.python.org  Mon Feb  8 19:01:11 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 09 Feb 2016 00:01:11 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1454976071.51.0.84629967499.issue25994@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Adding a ResourceWarning even if the generator is run to completion? That seems... dev hostile. I mean, yes, probably best to document it as best practice to use with with statement, but something simple like `files = sorted(os.scandir('.'), key=lambda x: x.stat().st_mtime)` to get files ordered by modification time (which cleanly runs the generator to exhaustion immediately) should not be raising ResourceWarning in 3.6 when it didn't do so in 3.5, and has minimal risk of leaking in any event.

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Feb  8 19:54:52 2016
From: report at bugs.python.org (John Mark Vandenberg)
Date: Tue, 09 Feb 2016 00:54:52 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1454979292.02.0.838071728957.issue24294@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +jayvdb

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

From report at bugs.python.org  Mon Feb  8 20:38:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Feb 2016 01:38:43 +0000
Subject: [issue26311] Typo in documentation for xml.parsers.expat
In-Reply-To: <1454957083.56.0.365121544419.issue26311@psf.upfronthosting.co.za>
Message-ID: <20160209013838.1543.70465@psf.io>


Roundup Robot added the comment:

New changeset 1383a260b66d by Martin Panter in branch '3.5':
Issues #26310, #26311: Fix typos in the documentation and code comments
https://hg.python.org/cpython/rev/1383a260b66d

New changeset 8c7a8c7a02b9 by Martin Panter in branch '2.7':
Issues #26310, #26311: Fix typos in the documentation
https://hg.python.org/cpython/rev/8c7a8c7a02b9

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 20:38:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Feb 2016 01:38:43 +0000
Subject: =?utf-8?q?=5Bissue26310=5D_Fix_typo_=E2=80=9Cvariariables=E2=80=9D_in_soc?=
 =?utf-8?q?ketserver=2Epy?=
In-Reply-To: <1454954804.39.0.970337231827.issue26310@psf.upfronthosting.co.za>
Message-ID: <20160209013838.1543.80149@psf.io>


Roundup Robot added the comment:

New changeset 1383a260b66d by Martin Panter in branch '3.5':
Issues #26310, #26311: Fix typos in the documentation and code comments
https://hg.python.org/cpython/rev/1383a260b66d

New changeset e2d3c93d8763 by Martin Panter in branch 'default':
Issues #26310, 26311: Merge typo fixes from 3.5
https://hg.python.org/cpython/rev/e2d3c93d8763

New changeset 8c7a8c7a02b9 by Martin Panter in branch '2.7':
Issues #26310, #26311: Fix typos in the documentation
https://hg.python.org/cpython/rev/8c7a8c7a02b9

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 20:45:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 01:45:36 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1454982336.6.0.297979152673.issue25994@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would be in favour of adding a ResourceWarning in 3.6 if the iterator is garbage collected without being exhausted. But as Josh says, it might be overkill emitting a warning when we already know the iterator has been finished and cleaned up.

----------

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

From report at bugs.python.org  Mon Feb  8 20:58:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 01:58:39 +0000
Subject: =?utf-8?q?=5Bissue26310=5D_Fix_typo_=E2=80=9Cvariariables=E2=80=9D_in_soc?=
 =?utf-8?q?ketserver=2Epy?=
In-Reply-To: <1454954804.39.0.970337231827.issue26310@psf.upfronthosting.co.za>
Message-ID: <1454983119.13.0.710962003239.issue26310@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thankyou for the report. I also took the opportunity to switch the words ?arbitrary other . . .? around to ?other arbitrary . . .?.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Mon Feb  8 20:58:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 01:58:51 +0000
Subject: =?utf-8?q?=5Bissue26310=5D_Fix_typo_=E2=80=9Cvariariables=E2=80=9D_in_soc?=
 =?utf-8?q?ketserver=2Epy?=
In-Reply-To: <1454954804.39.0.970337231827.issue26310@psf.upfronthosting.co.za>
Message-ID: <1454983131.92.0.961379576695.issue26310@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Feb  8 20:59:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 01:59:10 +0000
Subject: [issue26311] Typo in documentation for xml.parsers.expat
In-Reply-To: <1454957083.56.0.365121544419.issue26311@psf.upfronthosting.co.za>
Message-ID: <1454983150.66.0.124817794894.issue26311@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report :)

----------
nosy: +martin.panter
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6

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

From report at bugs.python.org  Mon Feb  8 21:17:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 02:17:18 +0000
Subject: [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1454984238.52.0.692566844915.issue25179@psf.upfronthosting.co.za>


Martin Panter added the comment:

Updated with Eric?s suggestions

----------
Added file: http://bugs.python.org/file41864/f-strings.v2.patch

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

From report at bugs.python.org  Mon Feb  8 21:32:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 02:32:33 +0000
Subject: =?utf-8?q?=5Bissue26316=5D_Probable_typo_in_Arg_Clinic=E2=80=99s_linear?=
 =?utf-8?b?X2Zvcm1hdCgp?=
Message-ID: <1454985153.85.0.932055658559.issue26316@psf.upfronthosting.co.za>


New submission from Martin Panter:

The curly bracket separator is assigned to ?curl?, but then the previous ?curly? variable is tested:

https://hg.python.org/cpython/annotate/3.5/Tools/clinic/clinic.py#l202

name, curl, trailing = trailing.partition('}')
if not curly or name not in kwargs:
    ...

I presume the fix is to assign to ?curly?, but I haven?t had a chance to figure out how to test it yet.

----------
components: Argument Clinic
messages: 259908
nosy: larry, martin.panter
priority: normal
severity: normal
stage: needs patch
status: open
title: Probable typo in Arg Clinic?s linear_format()
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Feb  8 21:35:36 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 09 Feb 2016 02:35:36 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1454985336.76.0.317535362532.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Also, every other operation for longs (except %, for which I created issue #26315) is optimized for single digit longs.  This optimization is also important for users of operator.floordiv etc.  Even if we decide to provide a fast path in ceval, it's going to be another matter.

----------

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

From report at bugs.python.org  Mon Feb  8 21:49:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 02:49:29 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1454986169.77.0.49796405194.issue25985@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 24916 about more related fixes in Lib/sysconfig.py

----------
nosy: +martin.panter

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

From report at bugs.python.org  Mon Feb  8 21:49:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 02:49:40 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
In-Reply-To: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>
Message-ID: <1454986180.56.0.577021535652.issue24916@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 25985 also touches the _PY_VERSION_SHORT parts of this.

----------
dependencies: +Use sys.version_info instead of sys.version
nosy: +martin.panter
stage:  -> patch review

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

From report at bugs.python.org  Mon Feb  8 23:12:41 2016
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 09 Feb 2016 04:12:41 +0000
Subject: =?utf-8?q?=5Bissue26316=5D_Probable_typo_in_Arg_Clinic=E2=80=99s_linear?=
 =?utf-8?b?X2Zvcm1hdCgp?=
In-Reply-To: <1454985153.85.0.932055658559.issue26316@psf.upfronthosting.co.za>
Message-ID: <1454991161.43.0.576858422924.issue26316@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yeah, change "curl" to "curly".  If you commit the fix without a test case I'd forgive you.  Or I can do it if that makes you nervous.

----------

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

From report at bugs.python.org  Mon Feb  8 23:35:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Feb 2016 04:35:05 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <20160209043501.61966.20288@psf.io>


Roundup Robot added the comment:

New changeset 3084914245d2 by Raymond Hettinger in branch 'default':
Issue #26200:  The SETREF macro adds unnecessary work in some cases.
https://hg.python.org/cpython/rev/3084914245d2

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  8 23:36:28 2016
From: report at bugs.python.org (Robert P Fischer)
Date: Tue, 09 Feb 2016 04:36:28 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
Message-ID: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>


New submission from Robert P Fischer:

Changes to OS X 10.11 render GCC's Objective-C compiler useless.  However, I want to compile the main part of Python in GCC (because my C++ / Fortran Cython modules use GCC).

I tried to build Python (via MacPorts) using Clang for Objective-C and GCC for C/C++.  The environment upon running ./configure included:

  CC='/Users/rpfische/macports/mpgompi-4.9.3/bin/gcc-mp-4.9'
  CXX='/Users/rpfische/macports/mpgompi-4.9.3/bin/gcc-mp-4.9'
  OBJC='/usr/bin/clang'
  OBJCXX='/usr/bin/clang++'

HOWEVER... the build still tried to use GCC to compile Objective-C, and failed miserably:



:info:destroot /Users/rpfische/macports/mpgompi-4.9.3/bin/gcc-mp-4.9 -pipe -Os -arch x86_64 -Wno-unused-result -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -o FileSettings.o -c ./FileSettings.m
:info:destroot /usr/include/objc/NSObject.h:22:4: error: unknown type name 'instancetype'
:info:destroot  - (instancetype)self;
:info:destroot     ^
...



Log file attached.

----------
components: Build
files: log
messages: 259914
nosy: Robert P Fischer
priority: normal
severity: normal
status: open
title: Build Problem with GCC + Macintosh OS X 10.11 El Capitain
versions: Python 3.4
Added file: http://bugs.python.org/file41865/log

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

From report at bugs.python.org  Tue Feb  9 01:30:24 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 09 Feb 2016 06:30:24 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
Message-ID: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>


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

`io.open(fd, ...).name` returns numeric fd instead of None. This lead to some nasty bugs.

In order to bring consistency and make that predictable, please make `.name` for that case to return None. (and document it)

----------
components: IO, Library (Lib)
messages: 259915
nosy: mmarkk
priority: normal
severity: normal
status: open
title: `io.open(fd, ...).name` returns numeric fd instead of None
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Feb  9 01:46:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 06:46:58 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
In-Reply-To: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>
Message-ID: <1455000418.64.0.735586939455.issue26312@psf.upfronthosting.co.za>


Martin Panter added the comment:

Seems like a reasonable change and patch to me.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Tue Feb  9 02:10:10 2016
From: report at bugs.python.org (=?utf-8?b?UmHDumwgTsO6w7FleiBkZSBBcmVuYXM=?=)
Date: Tue, 09 Feb 2016 07:10:10 +0000
Subject: [issue26311] Typo in documentation for xml.parsers.expat
In-Reply-To: <1454957083.56.0.365121544419.issue26311@psf.upfronthosting.co.za>
Message-ID: <1455001810.58.0.0981245059288.issue26311@psf.upfronthosting.co.za>


Ra?l N??ez de Arenas added the comment:

My pleasure :)

----------

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

From report at bugs.python.org  Tue Feb  9 03:25:42 2016
From: report at bugs.python.org (Case Van Horsen)
Date: Tue, 09 Feb 2016 08:25:42 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1455006342.13.0.432655345108.issue21955@psf.upfronthosting.co.za>


Case Van Horsen added the comment:

I ran the mpmath test suite with the fastint6 and fastint5_4 patches.

fastint6 results

without gmpy: 0.25% faster
with gmpy: 3% slower

fastint5_4 results

without gmpy: 1.5% slower
with gmpy: 5.5% slower

----------

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

From report at bugs.python.org  Tue Feb  9 04:15:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Feb 2016 09:15:55 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1455006342.13.0.432655345108.issue21955@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZpCQy8MZJd-JFn3hm4n2rTBAgKc9oSA_ihFerOMATbNQ@mail.gmail.com>


STINNER Victor added the comment:

Case Van Horsen added the comment:
> I ran the mpmath test suite with the fastint6 and fastint5_4 patches.
>
> fastint6 results
> without gmpy: 0.25% faster
> with gmpy: 3% slower
>
> fastint5_4 results
> without gmpy: 1.5% slower
> with gmpy: 5.5% slower

I'm more and more disappointed by this issue... If even a test
stressing int & float is *slower* (or less than 1% faster) with a
patch supposed to optimized them, what's the point? I'm also concerned
by the slow-down for other types (gmpy types).

Maybe we should just close the issue?

----------

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

From report at bugs.python.org  Tue Feb  9 04:18:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Feb 2016 09:18:36 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1454976071.51.0.84629967499.issue25994@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa_4-JnvvCNBd-3o9zkzqpR6H0N9a2fzQZkEM4fbs0qCw@mail.gmail.com>


STINNER Victor added the comment:

Josh Rosenberg added the comment:
> Adding a ResourceWarning even if the generator is run to completion?

I'm ok to only emit the warning is the generator is not exhausted.

The warning would be emited in the destructor if the generator is not
closed. In practice, the generator is *already* closed on the last
file, so the warning would not be emited if the generator is
exhausted.

----------

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

From report at bugs.python.org  Tue Feb  9 05:17:20 2016
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 09 Feb 2016 10:17:20 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1455013040.96.0.0847123598203.issue2528@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Tue Feb  9 05:24:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Feb 2016 10:24:19 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <20160209102416.20001.98348@psf.io>


Roundup Robot added the comment:

New changeset 592db8704d38 by Martin Panter in branch 'default':
Issue #26243: zlib.compress() keyword argument support by Aviv Palivoda
https://hg.python.org/cpython/rev/592db8704d38

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  9 05:31:42 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 09 Feb 2016 10:31:42 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1455013902.82.0.263936983649.issue2528@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Tue Feb  9 05:34:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 10:34:59 +0000
Subject: [issue25901] make test crash in test_httpservers
In-Reply-To: <1450431596.39.0.127057535.issue25901@psf.upfronthosting.co.za>
Message-ID: <1455014099.99.0.0887256566225.issue25901@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
title: make test crash -> make test crash in test_httpservers

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

From report at bugs.python.org  Tue Feb  9 05:37:56 2016
From: report at bugs.python.org (j w)
Date: Tue, 09 Feb 2016 10:37:56 +0000
Subject: [issue26319] Check recData size before unpack in zipfile
Message-ID: <1455014276.42.0.95606517598.issue26319@psf.upfronthosting.co.za>


New submission from j w:

Encountered on version: 2.7.3
Exception message: "error: unpack requires a string argument of length 22"

Stack trace:
  ...
  elif zipfile.is_zipfile(_file):>
File "/usr/lib/python2.7/zipfile.py", line 152, in is_zipfile>
  result = _check_zipfile(fp)>
File "/usr/lib/python2.7/zipfile.py", line 135, in _check_zipfile>
  if _EndRecData(fp):>
File "/usr/lib/python2.7/zipfile.py", line 238, in _EndRecData>
  endrec = list(struct.unpack(structEndArchive, recData))>

Check the size of recData before unpacking.
 ...
 237: recData = data[start:start+sizeEndCentDir]
 238: endrec = list(struct.unpack(structEndArchive, recData))

----------
components: Extension Modules
messages: 259922
nosy: j w
priority: normal
severity: normal
status: open
title: Check recData size before unpack in zipfile
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb  9 05:41:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 10:41:51 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock() don't
 shutdwon request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455014511.86.0.276405742029.issue26309@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks good to me. Are you interested in writing a unit test for it? Having said that, it might be a tricky test to write.

----------
nosy: +martin.panter
stage:  -> patch review

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

From report at bugs.python.org  Tue Feb  9 05:43:46 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Tue, 09 Feb 2016 10:43:46 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1455014626.57.0.155360722377.issue21042@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

I fixed the ABI matching, it was a stupid mistake, thanks for pointing it out :) I think now it works as expected.

I really don't find a place for testing. Maybe a new test file could be added, but I think the testing code for find_library wouldn't be more than 10 lines. Do you have any suggestions?

Thanks Martin for all your patience :)

----------
Added file: http://bugs.python.org/file41866/find_lib_v2.patch

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

From report at bugs.python.org  Tue Feb  9 05:46:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Feb 2016 10:46:17 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <20160209104614.11231.40888@psf.io>


Roundup Robot added the comment:

New changeset dc758f51b8f5 by Martin Panter in branch 'default':
Issue 26243: Forgot to update zlib doc strings in Argument Clinic
https://hg.python.org/cpython/rev/dc758f51b8f5

----------

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

From report at bugs.python.org  Tue Feb  9 05:46:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 10:46:52 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <1455014812.27.0.477824463059.issue26243@psf.upfronthosting.co.za>


Martin Panter added the comment:

I did add a What?s New entry (I hope nobody minds), and updated the doc strings in the zlib module. Thanks for the work on this Aviv.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 06:39:38 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Feb 2016 11:39:38 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1455017978.13.0.929431058423.issue26317@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The build fails while building the "Python Launcher" application. This is an Objective-C project. 

If GCC doesn't support the system headers on OSX 10.11 there's nothing the Python project can do about that.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Tue Feb  9 06:55:30 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 09 Feb 2016 11:55:30 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455018930.16.0.696559246189.issue26318@psf.upfronthosting.co.za>


???? ????????? added the comment:

In particular, `io.open(fd, ...)` can not be used with tarfile, since it use it's "name" property, and think that it is real file name, and not expecte it to be int.

----------

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

From report at bugs.python.org  Tue Feb  9 07:26:51 2016
From: report at bugs.python.org (Robert P Fischer)
Date: Tue, 09 Feb 2016 12:26:51 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1455017978.13.0.929431058423.issue26317@psf.upfronthosting.co.za>
Message-ID: <CAC_jL3yMOQOp5q385T_YvSmq5KT_13LvsW6t8MQ-2Dx1mW0CDQ@mail.gmail.com>


Robert P Fischer added the comment:

I'm trying to compile the Objective-C portions of Python (the Python
Launcher app) with clang, not GCC.  Why does Python insist on using GCC,
even when I set the OBJC env variable to clang?  That seems to be a problem
that the Python project CAN fix.

On Tue, Feb 9, 2016 at 6:39 AM, Ronald Oussoren <report at bugs.python.org>
wrote:

>
> Ronald Oussoren added the comment:
>
> The build fails while building the "Python Launcher" application. This is
> an Objective-C project.
>
> If GCC doesn't support the system headers on OSX 10.11 there's nothing the
> Python project can do about that.
>
> ----------
> nosy: +ronaldoussoren
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26317>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Feb  9 08:16:36 2016
From: report at bugs.python.org (Rory McCann)
Date: Tue, 09 Feb 2016 13:16:36 +0000
Subject: [issue26320] Web documentation for 2.7 has unreadable highlights in
 Table of Contents
Message-ID: <1455023796.48.0.712407093962.issue26320@psf.upfronthosting.co.za>


New submission from Rory McCann:

Using Firefox 41.0.2 on Ubuntu 14.04, most table of contents in the online docs have unreadable highlighted sections, where modules/methods are named.

See https://docs.python.org/2/library/datetime.html for a good example, or the attached screenshot.

I think this highlighting has appeared recently.
The 3.x versions are fine, as is 2.6.

----------
assignee: docs at python
components: Documentation
files: Screenshot from 2016-02-09 13:15:43.png
messages: 259930
nosy: Rory McCann, docs at python
priority: normal
severity: normal
status: open
title: Web documentation for 2.7 has unreadable highlights in Table of Contents
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41867/Screenshot from 2016-02-09 13:15:43.png

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

From report at bugs.python.org  Tue Feb  9 08:30:20 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Feb 2016 13:30:20 +0000
Subject: [issue26320] Web documentation for 2.7 has unreadable highlights in
 Table of Contents
In-Reply-To: <1455023796.48.0.712407093962.issue26320@psf.upfronthosting.co.za>
Message-ID: <1455024620.51.0.767702660323.issue26320@psf.upfronthosting.co.za>


Georg Brandl added the comment:

In addition, the object description headers (function names...) are not styled as they should be.

Has the doc style been changed recently?

----------
nosy: +benjamin.peterson, ezio.melotti, georg.brandl

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

From report at bugs.python.org  Tue Feb  9 08:30:41 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Feb 2016 13:30:41 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455024641.31.0.726926931659.issue26289@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Feb  9 08:41:09 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Feb 2016 13:41:09 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455025269.31.0.272518786441.issue26289@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

A slightly neater way to compute the result in the case that the signs differ is 

  div = ~((left - 1) / right)

That saves the extra multiplication and equality check.

----------

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

From report at bugs.python.org  Tue Feb  9 09:01:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Feb 2016 14:01:35 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1455026495.0.0.0700226144935.issue26282@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch adds support for positional-only parameters in PyArg_ParseTupleAndKeywords(). It is simple, the most complex part is generating detailed error message for the case of calling with insufficient number of positional arguments.

----------
keywords: +patch
Added file: http://bugs.python.org/file41868/pyarg_parse_positional_only_and_keywords.patch

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

From report at bugs.python.org  Tue Feb  9 09:05:59 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Feb 2016 14:05:59 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455026759.97.0.99247008021.issue26289@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

... though on second thoughts, it's probably better to spell that

    div = -1 - (left - 1) / right

to avoid compiler warnings about bit operations on signed types. A good compiler should be able to optimise `-1 - x` to `~x` anyway.

----------

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

From report at bugs.python.org  Tue Feb  9 09:08:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Feb 2016 14:08:46 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455026926.17.0.333912446726.issue26289@psf.upfronthosting.co.za>


STINNER Victor added the comment:

STINNER Victor:
>> This change looks related to the issue #21955. IMHO we should take the same decision. I mean, maybe it's better to implement the fast-path only in ceval.c? Or maybe in ceval.c and longobject.c?

Yury Selivanov:
> There is no drastic difference on where you implement the fast path.  I'd implement all specializations/optimizations in longobject.c and optimize ceval to call slots directly.  That way, the implact on ceval performance would be minimal.

Oh wait, I was confused by my own patch for #21955 inlining int operations in ceval.c.

Since recent benchmarks showed slow-down when ceval.c is modified, I think that it's ok to modify longobject.c rather than ceval.c (and maybe only longobject.c, but let's discuss that in issue #21955).

----------

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

From report at bugs.python.org  Tue Feb  9 10:08:56 2016
From: report at bugs.python.org (Andrew Page)
Date: Tue, 09 Feb 2016 15:08:56 +0000
Subject: [issue26321] datetime.strptime fails to parse AM/PM correctly
Message-ID: <1455030536.64.0.408673098232.issue26321@psf.upfronthosting.co.za>


New submission from Andrew Page:

##
##  It appears that strptime is ignoring the AM/PM field
##
from datetime import datetime
d1 = datetime.strptime("1:00 PM", "%H:%M %p")
d2 = datetime.strptime("1:00 AM", "%H:%M %p")
d1.hour, d2.hour
(1, 1) # d1 should be 13
d1 == d2
True # and these should not be equal

----------
components: Library (Lib)
messages: 259936
nosy: aepage
priority: normal
severity: normal
status: open
title: datetime.strptime fails to parse AM/PM correctly
versions: Python 3.5

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

From report at bugs.python.org  Tue Feb  9 10:14:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Feb 2016 15:14:03 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455030843.68.0.119135740605.issue25994@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch adds a resource warning, tests, improves the documentation, and addresses other comments.

----------
Added file: http://bugs.python.org/file41869/scandir_close_2.patch

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

From report at bugs.python.org  Tue Feb  9 10:20:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Feb 2016 15:20:58 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455031258.37.0.674087955972.issue26289@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since the patch is changed (and may be changed further if accept Mark's suggestion), benchmarks results should be updated.

Is it worth to move the optimization inside l_divmod? Will this speed up or slow down other operations that use l_divmod?

----------

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

From report at bugs.python.org  Tue Feb  9 10:50:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Feb 2016 15:50:47 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455033047.14.0.573666084701.issue25994@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Updated patch adds a resource warning, tests, improves the documentation, and addresses other comments.

Review sent.

----------

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

From report at bugs.python.org  Tue Feb  9 10:59:22 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 09 Feb 2016 15:59:22 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455033562.53.0.564394329579.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching a new patch -- big thanks to Mark and Serhiy.

> div = ~((left - 1) / right)

The updated code works slightly faster - ~0.285 usec vs ~0.3 usec.

----------
Added file: http://bugs.python.org/file41870/floor_div_4.patch

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

From report at bugs.python.org  Tue Feb  9 10:59:54 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 09 Feb 2016 15:59:54 +0000
Subject: [issue26321] datetime.strptime fails to parse AM/PM correctly
In-Reply-To: <1455030536.64.0.408673098232.issue26321@psf.upfronthosting.co.za>
Message-ID: <1455033594.23.0.103909007745.issue26321@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This is a documented peculiarity of the %p format code, see the '%p' entry in the table at [1], note 3 in particular.

>>> from datetime import datetime
>>> datetime.strptime('1:00 PM', '%H:%M %p').hour
1
>>> datetime.strptime('1:00 PM', '%I:%M %p').hour
13


[1] https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 11:03:38 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 09 Feb 2016 16:03:38 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455033818.34.0.977265262501.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Is it worth to move the optimization inside l_divmod? Will this speed up or slow down other operations that use l_divmod?

Attaching a new patch -- fast_divmod.patch

It combines patches for this issue and issue #26315.

Individual timeit benchmarks work as fast, but ** op becomes faster:

-m timeit -s "x=223" "x**2;x**-2;x**2;x**-3;x**3;x**-3;x**4.5;x**-4.5"
with patch: 1.2usec
without: 1.5usec

----------
Added file: http://bugs.python.org/file41871/fast_divmod.patch

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

From report at bugs.python.org  Tue Feb  9 11:32:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Feb 2016 16:32:54 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1455035574.0.0.452141024556.issue25985@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Update patch uses less cryptic formatting expressions (thanks SilentGhost for suggestion), fixes Makefile.pre.in (thanks Andrew), and fixes yet few files.

----------
Added file: http://bugs.python.org/file41872/use_version_info_2.patch

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

From report at bugs.python.org  Tue Feb  9 11:35:40 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Feb 2016 16:35:40 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455035740.37.0.122502784336.issue26289@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Just for the record, there's a less-branchy analog of the floor division code I suggested for modulo. In Python-land, it looks like this:

def propermod(a, b):
    # mimic the C setup
    assert a != 0 and b != 0
    left = abs(a)
    size_a = -1 if a < 0 else 1
    right = abs(b)
    size_b = -1 if b < 0 else 1

    # Compute mod: only one branch needed.
    mod = left % right if size_a == size_b else right - 1 - (left - 1) % right
    return mod * size_b

# Verify that we get the same results as the regular mod.
for n in range(-100, 100):
    if n == 0:
        continue
    for d in range(-100, 100):
        if d == 0:
            continue
        assert propermod(n, d) == n % d

It may well not have any significant effect here, though.

----------

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

From report at bugs.python.org  Tue Feb  9 11:43:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Feb 2016 16:43:34 +0000
Subject: [issue25848] Tkinter tests failed on Windows buildbots
In-Reply-To: <1449939672.03.0.965226031522.issue25848@psf.upfronthosting.co.za>
Message-ID: <20160209164246.40056.46150@psf.io>


Roundup Robot added the comment:

New changeset 5430f4fd4ca7 by Zachary Ware in branch 'default':
Issue #25848: Add section on running a build on all custom builders
https://hg.python.org/devguide/rev/5430f4fd4ca7

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  9 11:44:08 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 09 Feb 2016 16:44:08 +0000
Subject: [issue25848] Tkinter tests failed on Windows buildbots
In-Reply-To: <1449939672.03.0.965226031522.issue25848@psf.upfronthosting.co.za>
Message-ID: <1455036248.61.0.0264804169172.issue25848@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I added the note to the devguide instead of pep101, and will be removing the 3.4 builders shortly.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 13:07:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Feb 2016 18:07:17 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455041237.54.0.700709230029.issue25994@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses new Victor's comments.

----------
Added file: http://bugs.python.org/file41873/scandir_close_3.patch

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

From report at bugs.python.org  Tue Feb  9 13:24:01 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 09 Feb 2016 18:24:01 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1455042241.25.0.14748696361.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Maybe we should just close the issue?

I'll take a closer look at gmpy later. Please don't close.

----------

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

From report at bugs.python.org  Tue Feb  9 13:51:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Feb 2016 18:51:45 +0000
Subject: [issue21152] Idle: timed autosave for shell (and maybe editor) window
In-Reply-To: <1396599186.38.0.494576293163.issue21152@psf.upfronthosting.co.za>
Message-ID: <1455043905.56.0.530168289761.issue21152@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On idledev, Jeff Silverman requested autosave, I presume for editor windows.  If one is doing closely interactive development, hitting F5 to save and run every few minutes, this would not be necessary.  But if not, ... I know that autosaves in other programs (editors and games) have saved me lots of trouble more than once.

Saving every n minutes should be trivial using .after.  With slightly more work, it could be every n minute the window is active (has the focus).  Any untimed save should reset the timer.  Since IDLE looks at every keystroke (I believe), counting keystrokes and saving every n keystrokes might be possible.

----------

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

From report at bugs.python.org  Tue Feb  9 14:36:32 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Feb 2016 19:36:32 +0000
Subject: [issue1326830] python scratchpad (IDLE)
Message-ID: <1455046592.41.0.500270400357.issue1326830@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have a tem.py 'scratch' file which I use often enough that it is nearly always in the recent files list.

On the other hand, many beginners do not think to do that, and Guido has said recently to design for beginners.  In #19042, I propose that there should be an option to autosave Untitled to .idlerc/untitled.py, without associating the name with the Window.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Tue Feb  9 15:13:42 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Feb 2016 20:13:42 +0000
Subject: [issue26315] Optimize mod division for ints
In-Reply-To: <1454970675.84.0.301967594836.issue26315@psf.upfronthosting.co.za>
Message-ID: <1455048822.86.0.824793240862.issue26315@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Feb  9 15:16:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Feb 2016 20:16:30 +0000
Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window
In-Reply-To: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za>
Message-ID: <1455048990.77.0.926747487702.issue19042@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#1326830 ('python scratchpad', rejected) was about same issue, though less specific about the implementation.

A different solution to the multiline statement problem would be to separate Shell into the read-only history (with prompts in a sidebar, so normal 4 space indents would work) and an active mini-editor entry box that would continue to submit without saving.

----------

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

From report at bugs.python.org  Tue Feb  9 15:20:02 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Feb 2016 20:20:02 +0000
Subject: [issue21152] Idle: timed autosave for shell (and maybe editor) window
In-Reply-To: <1396599186.38.0.494576293163.issue21152@psf.upfronthosting.co.za>
Message-ID: <1455049202.09.0.682697430651.issue21152@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I list below other IDLE issues containing 'autosave', so I don't have to look at each issue for relevance to this one again.

#21140  22 Idle: saving an OutputWindow should default to .txt (patch)
           (Has comment prompting this issue.  Otherwise not relevant.)
#23666  10 Add shell session logging option to IDLE
           (Related to this issue, partial duplicate)
#21937   6 IDLE interactive window doesn't display unsaved indicator
           (Actually, *...* indicates non-empty undo buffer.)
#19042   9 Idle: add option to autosave 'Untitled' edit window
           (On F5, same as for titled edit window. See 1326830.)
#4765   20 IDLE fails to "Delete Custom Key Set" properly (patch)
           ('autosave' in quoted .idlerc/config-main.cfg)
<closed>
#1175686 79 add "reload" function to IDLE
            (Closed as dup, 'autosave' is about F5.  Not relevant.)
#1326830 125 python scratchpad (IDLE)
             (Rejected.  19042 is a re-opening of this.)

----------
versions: +Python 3.6 -Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Feb  9 15:38:50 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Tue, 09 Feb 2016 20:38:50 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock() don't
 shutdwon request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455050330.38.0.785605845291.issue26309@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I added a test to check the specific bug.

There seems to be no testing at all on the verify_request feature so I will create some in different issue in the future.

----------
Added file: http://bugs.python.org/file41874/socketserver-shutdown-if-verify-false3.patch

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

From report at bugs.python.org  Tue Feb  9 15:48:20 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 09 Feb 2016 20:48:20 +0000
Subject: [issue26322] Missing docs for typing.Set
Message-ID: <1455050900.92.0.506743123977.issue26322@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The typing docs don't seem to mention Set (which is a bit of an anomaly, since it corresponds to builtins.set, not to collections.abc.Set -- the latter is typing.AbstractSet). Also, AbstractSet is mentioned twice. (And the second occurrence somehow doesn't have a "paragraph" link.)

All this should be easy to fix.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 259954
nosy: docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: Missing docs for typing.Set
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Feb  9 16:12:15 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Feb 2016 21:12:15 +0000
Subject: [issue26322] Missing docs for typing.Set
In-Reply-To: <1455050900.92.0.506743123977.issue26322@psf.upfronthosting.co.za>
Message-ID: <1455052335.76.0.0819282122845.issue26322@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Tue Feb  9 16:57:49 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 09 Feb 2016 21:57:49 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455055069.37.0.805945112098.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> mod = left % right if size_a == size_b else right - 1 - (left - 1) % right

This works, Mark!  Again, the difference in performance is very subtle, but the code is more compact.


-m timeit -s "x=22331" "x//2;x//-3;x//4;x//5;x//-6;x//7;x//8;x//-99;x//100;"
with patch: 0.321          without patch: 0.633

-m timeit -s "x=22331" "x%2;x%3;x%-4;x%5;x%6;x%-7;x%8;x%99;x%-100;"
with patch: 0.224          without patch: 0.66

-m timeit "divmod(100,20);divmod(7,3);divmod(121,99);divmod(123121,123);divmod(-1000,7);divmod(23423,-111)"
with patch: 0.839          without patch: 1.07


I'm in favour of fast_divmod_2.patch for solving both this issue and issue #26315.  Serhiy, what do you think?

----------
Added file: http://bugs.python.org/file41875/fast_divmod_2.patch

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

From report at bugs.python.org  Tue Feb  9 17:07:20 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 09 Feb 2016 22:07:20 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455055640.66.0.911513453403.issue26289@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file41876/fast_divmod_3.patch

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

From report at bugs.python.org  Tue Feb  9 17:14:14 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Tue, 09 Feb 2016 22:14:14 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
In-Reply-To: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>
Message-ID: <1455056054.4.0.767770111745.issue23718@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

I made a patch, that solves this issue.

The problem was that there wasn't any Sunday (%w = 0) on the 0th week in 2015. 2015 started on Thursday, therefore the first Sunday was on 2014.12.28.

julian variable is used to set the tm_yday, which was a minus value, as the given date was not in the same year.

----------
keywords: +patch
Added file: http://bugs.python.org/file41877/julian_date.patch

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

From report at bugs.python.org  Tue Feb  9 17:19:16 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Tue, 09 Feb 2016 22:19:16 +0000
Subject: [issue26279] time.strptime does not properly convert out-of-bounds
 values
In-Reply-To: <1454515371.52.0.00863631935711.issue26279@psf.upfronthosting.co.za>
Message-ID: <1455056356.75.0.118324620363.issue26279@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

This is connected to http://bugs.python.org/issue23718

I submitted a patch that hopefully solves this problem.

----------
nosy: +beng94

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

From report at bugs.python.org  Tue Feb  9 17:20:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 22:20:34 +0000
Subject: [issue1767511] SocketServer.DatagramRequestHandler with empty response
Message-ID: <1455056434.57.0.71957045127.issue1767511@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry that nobody has responded to your patch in almost a decade. :( Unfortunately in the meantime the test file seems to have been completely rewritten.

For the original problem, I think it would be better if we just documented that this is the way it works. Sending an empty response message seems like a plausible way to acknowledge handling of a request. This parallels the stream handler only shutting down the connection when the request handler has finished. Changing this could break compatibility.

Ben: if you?re still interested, can you explain what the problem is on Windows? My experiments with Wine on Linux suggest that it can send empty UDP responses fine. Is Windows able to send and receive zero-length UDP messages with plain sockets? Perhaps this should be a separate bug.

----------
nosy: +martin.panter
stage:  -> patch review
title: SocketServer.DatagramRequestHandler -> SocketServer.DatagramRequestHandler with empty response

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

From report at bugs.python.org  Tue Feb  9 17:38:05 2016
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 09 Feb 2016 22:38:05 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1455057485.89.0.139242332521.issue26204@psf.upfronthosting.co.za>


Jim Jewett added the comment:

I think the warning was helpful; it just had confusing wording.

Instead of: """
>>> def f():
...  False
...
<stdin>:2: SyntaxWarning: ignore constant statement
"""

perhaps: """
>>> def f():
...  False
...
<stdin>:2: SyntaxWarning: ignoring constant statement
"""

or even: """
>>> def f():
...  False
...
<stdin>:2: SyntaxWarning: ignoring unused constant 'False'
"""

----------
nosy: +Jim.Jewett

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

From report at bugs.python.org  Tue Feb  9 18:04:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 23:04:35 +0000
Subject: [issue21996] gettarinfo method does not handle files without text
 string names
In-Reply-To: <1405583528.37.0.553699872308.issue21996@psf.upfronthosting.co.za>
Message-ID: <1455059075.88.0.0173481643062.issue21996@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies: +Tarfile using fstat on GZip file object

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

From report at bugs.python.org  Tue Feb  9 18:07:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 09 Feb 2016 23:07:22 +0000
Subject: [issue23453] Opening a stream with tarfile.open() triggers a
 TypeError: can't concat bytes to str error
In-Reply-To: <1423739998.49.0.706967373594.issue23453@psf.upfronthosting.co.za>
Message-ID: <1455059242.6.0.611860938994.issue23453@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> needs patch
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 19:00:45 2016
From: report at bugs.python.org (Amit Saha)
Date: Wed, 10 Feb 2016 00:00:45 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
Message-ID: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>


New submission from Amit Saha:

Would a patch for adding a assert_called() method to mocked objects be welcome for inclusion? We do have a assert_not_called() method, so I think this may be a good idea. Please let me know and I will work on it.

----------
components: Library (Lib)
messages: 259960
nosy: Amit.Saha
priority: normal
severity: normal
status: open
title: Add a assert_called() method for mock objects

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

From report at bugs.python.org  Tue Feb  9 19:04:48 2016
From: report at bugs.python.org (Amit Saha)
Date: Wed, 10 Feb 2016 00:04:48 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455062688.85.0.870306357978.issue26323@psf.upfronthosting.co.za>


Changes by Amit Saha <amitsaha.in at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Tue Feb  9 19:08:02 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Feb 2016 00:08:02 +0000
Subject: [issue26324] sum() incorrect on negative zeros
Message-ID: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> sum([-0.0,-0.0])
0.0

----------
components: Interpreter Core
messages: 259961
nosy: eric.smith, lemburg, mark.dickinson, pitrou, stutzbach
priority: low
severity: normal
status: open
title: sum() incorrect on negative zeros
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Feb  9 19:13:31 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 10 Feb 2016 00:13:31 +0000
Subject: [issue26324] sum() incorrect on negative zeros
In-Reply-To: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>
Message-ID: <1455063211.11.0.856934133024.issue26324@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

This is consistent with the advertised equivalence of sum():

>>> -0.0 + -0.0 + 0
0.0

This works as you'd expect:

>>> sum([-0.0, -0.0], -0.0)
-0.0

It has a start value of 0, and I don't think we should special-case this.

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26324>
_______________________________________

From report at bugs.python.org  Tue Feb  9 19:15:50 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Feb 2016 00:15:50 +0000
Subject: [issue26324] sum() incorrect on negative zeros
In-Reply-To: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>
Message-ID: <1455063350.34.0.412024533621.issue26324@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

"Expect" is a strong word here ;-) The problem is the start value is implicit and is supposed to be a "good default". Of course, solving this consistently may not be trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26324>
_______________________________________

From report at bugs.python.org  Tue Feb  9 19:22:21 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 10 Feb 2016 00:22:21 +0000
Subject: [issue26324] sum() incorrect on negative zeros
In-Reply-To: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>
Message-ID: <1455063741.62.0.983593260896.issue26324@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

"Not trivial" might be an understatement. You need the start value to begin summing the items, but you may face with a non-repeatable generator with side-effects. Sure, you could special-case some builtins, but I'm not too keen on adding special cases for such an uncommon case. Feel free to prove me wrong, though!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26324>
_______________________________________

From report at bugs.python.org  Tue Feb  9 20:02:25 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 10 Feb 2016 01:02:25 +0000
Subject: [issue26324] sum() incorrect on negative zeros
In-Reply-To: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>
Message-ID: <1455066145.45.0.669692970676.issue26324@psf.upfronthosting.co.za>


Ethan Furman added the comment:

If one is using sum on floats, and a list of -0.0's is a possibility, and the sign matters... well, I would hope that one is using -0.0 as the start value.

I don't think this is worth "fixing".

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26324>
_______________________________________

From report at bugs.python.org  Tue Feb  9 20:52:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 01:52:06 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455069126.04.0.680249372248.issue26318@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree that the business with ?name? is a mess. I don?t know what the best solution is. FileIO.name is already documented as being a file descriptor in some cases.

Perhaps we should document that the Buffered and Text wrappers inherit the wrapped name, but if the underlying object has no ?name? attribute then neither does the wrapper object. E.g.: TextIOWrapper(BufferedReader(BytesIO())).name. Also document that a string name is more a rough description and may not be technically accurate, e.g. sys.stdin.buffer.raw.name is always "<stdin>".

I?m not sure that changing the name to None would be much of an improvement over having it an integer file descriptor. It would probably hurt debugging and error messages. IMO it is the APIs like tarfile that are broken when they assume ?name? is a technically valid file name string.

In the tarfile module, there are two uses a file?s ?name? attribute that I know of:

TarFile constructor: Since the main change for Issue 21044 was made, the TarFile constructor only uses the underlying name attribute if it is str or bytes.

TarFile.gettarinfo(): See Issue 21996 and my. I proposed some documentation in Issue 22468 to clarify the behaviour. In one use case, I had to override the ?name? attribute with a dummy ?arcname? argument, and then set the real name later on.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26318>
_______________________________________

From report at bugs.python.org  Tue Feb  9 21:45:54 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Wed, 10 Feb 2016 02:45:54 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1455072354.77.0.543593381481.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Martin, here's a third patch, "try 3", which does a runtime version check instead of compile-time. It's a bit complex, compared to "try 2", which did a compile-time check instead.

I do NOT think this extra complexity is worth it to support Pythons that are built on 10.5+ and running on Mac OS 10.4 and older. 10.4 is long obsolete.

I propose merging "try 2" with the compile-time check. If that patch is accepted, I'll submit a patch for Python 2.7 also.

Thank you!

----------
Added file: http://bugs.python.org/file41878/25924-getaddrinfo-is-thread-safe-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25924>
_______________________________________

From report at bugs.python.org  Tue Feb  9 21:46:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 02:46:25 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455072385.65.0.0444801076986.issue25994@psf.upfronthosting.co.za>


Martin Panter added the comment:

About testing that list(iterator) is empty after the iterator is closed, IMO this is an implementation detail. It would be equally (or more) sensible to raise an exception, like proposed for ?async def? coroutines in Issue 25887. I suppose the main purpose of those tests is to ensure there is no leakage or warning, so maybe add some more filterwarnings() checks in those tests instead?

I left some other review comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25994>
_______________________________________

From report at bugs.python.org  Tue Feb  9 21:53:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 02:53:51 +0000
Subject: [issue5824] SocketServer.DatagramRequestHandler Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1455072831.02.0.964279741191.issue5824@psf.upfronthosting.co.za>


Martin Panter added the comment:

It is not that wfile.getvalue() returns None, it is that self.client_address is None. If the client explicitly binds to a name, then the server gets that name in the client_address, and then everything seems to work properly for me on Linux.

On Linux, using strace and an unbound anonymous client, I see that recvfrom() outputs a zero-length sending address structure, which Python?s makesockaddr() function converts to None with the comment /* No address -- may be recvfrom() from known socket */. The man page <http://man7.org/linux/man-pages/man7/unix.7.html> actually says the address length should be sizeof(sa_family_t) in this case, so maybe that is a minor bug for Linux or the man page.

How does this work on non-Linux platforms? I?m not really familiar with Unix domain sockets, especially datagram ones, but it seems to me that the main confusion is whether DatagramRequestHandler supports anonymous Unix domain clients or not.

As in Issue 1767511, I think DatagramRequestHandler is designed to always send a response back to the sender of the request. If you don?t want to send a response, why are you using this class?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________

From report at bugs.python.org  Tue Feb  9 22:25:35 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 10 Feb 2016 03:25:35 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1455074735.69.0.394933024834.issue25924@psf.upfronthosting.co.za>


Ned Deily added the comment:

I agree that the approach in "try 2" is fine and the runtime check in "try 3" is overkill.  While it is possible to do so, we've never really supported building on an OS X release n for release m, where m < n, without using the m SDK on n (and in particular for m=10.4) in which case the "try 2" test should work correctly.  Ronald, what do you think?

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25924>
_______________________________________

From report at bugs.python.org  Tue Feb  9 22:52:46 2016
From: report at bugs.python.org (Alexander Mohr)
Date: Wed, 10 Feb 2016 03:52:46 +0000
Subject: [issue25593] _sock_connect_cb can be called twice resulting in
 InvalidStateError
In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za>
Message-ID: <1455076366.01.0.43470583953.issue25593@psf.upfronthosting.co.za>


Alexander Mohr added the comment:

I'm not sure if you guys are still listening on this closed bug but I think I've found another issue ;)  I'm using python 3.5.1 + asyncio 3.4.3 with the latest aiobotocore (which uses aiohttp 0.21.0) and had two sessions (two TCPConnectors), one doing a multitude of GetObjects via HTTP1.1, and the other doing PutObject, and the PutObject session returns error 61 (connection refused) from the same _sock_connect_cb.  It feels like a similar issue to the original.  I'll see if I can get small testcase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25593>
_______________________________________

From report at bugs.python.org  Tue Feb  9 23:04:36 2016
From: report at bugs.python.org (Alexander Mohr)
Date: Wed, 10 Feb 2016 04:04:36 +0000
Subject: [issue25593] _sock_connect_cb can be called twice resulting in
 InvalidStateError
In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za>
Message-ID: <1455077076.25.0.701740929086.issue25593@psf.upfronthosting.co.za>


Alexander Mohr added the comment:

update: its unrelated to the number of sessions or SSL, but instead to the number of concurrent aiohttp requests.  When set to 500, I get the error, when set to 100 I do not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25593>
_______________________________________

From report at bugs.python.org  Tue Feb  9 23:07:55 2016
From: report at bugs.python.org (Mandar Gokhale)
Date: Wed, 10 Feb 2016 04:07:55 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1455077275.44.0.932753544301.issue8013@psf.upfronthosting.co.za>


Mandar Gokhale added the comment:

[Strictly speaking, this is actually issue #10563, but that was marked superseded by the changes for this issue, hence the comment here.]

The 5-digit year still displays an extra newline in Python 2.7.11 (there's extra whitespace on OSX as well, but that seems to due to the fact that ctime() returns 30 bytes on OSX instead of the documented 26):

{~}$ /usr/local/bin/python
Python 2.7.11 (default, Jan 22 2016, 08:29:18)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.ctime(253402300799)
'Fri Dec 31 23:59:59 9999'
>>> time.ctime(253402300800)
'Sat Jan  1 00:00:00     10000\n'

...and, as far as I can see, the patch hasn't been applied to py2.7 yet (https://hg.python.org/cpython/file/2.7/Modules/timemodule.c#l579)


Please let me know if I am missing something obvious (I'm pretty new to the bugtracker), or if this issue is planned not to be fixed for versions < 3.0. 

If not, should this issue be reopened, or the py27-specific problem be migrated to a new issue?

----------
nosy: +Mandar Gokhale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8013>
_______________________________________

From report at bugs.python.org  Tue Feb  9 23:11:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 04:11:21 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1455077481.53.0.242000701506.issue25924@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am happy to defer to Ned who probably knows a lot more than me about the OS X situation.

FTR it was the code added in 2006 by r45660 (Issue 1471925) that motivated my concern. Since that was added by Ronald, it would be good to hear his opinion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25924>
_______________________________________

From report at bugs.python.org  Tue Feb  9 23:48:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 04:48:13 +0000
Subject: [issue14307] Make subclassing SocketServer simpler for non-blocking
 frameworks
In-Reply-To: <1331767378.71.0.470789063251.issue14307@psf.upfronthosting.co.za>
Message-ID: <1455079693.67.0.0643366597256.issue14307@psf.upfronthosting.co.za>


Martin Panter added the comment:

FTR the python-dev discussion looks like it is <https://marc.info/?l=python-dev&m=133169928819705&w=2>. The argument for this change seems to be to support users monkey-patching the socket module, but not monkey-patching the select module. But this seems unreasonable to me.

I also agree the would make it harder to fix the wakeup polling problem. I suggest to reject this change.

Also, if you want a method to be overridable in subclasses, I don?t think it should have an underscore prefix.

----------
components: +Library (Lib)
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14307>
_______________________________________

From report at bugs.python.org  Wed Feb 10 00:09:32 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Feb 2016 05:09:32 +0000
Subject: [issue26320] Web documentation for 2.7 has unreadable highlights in
 Table of Contents
In-Reply-To: <1455024620.51.0.767702660323.issue26320@psf.upfronthosting.co.za>
Message-ID: <1455080968.4094924.516963610.631D87EB@webmail.messagingengine.com>


Benjamin Peterson added the comment:

I upgraded Sphinx a month or so ago. Could that do it?

On Tue, Feb 9, 2016, at 05:30, Georg Brandl wrote:
> 
> Georg Brandl added the comment:
> 
> In addition, the object description headers (function names...) are not
> styled as they should be.
> 
> Has the doc style been changed recently?
> 
> ----------
> nosy: +benjamin.peterson, ezio.melotti, georg.brandl
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26320>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26320>
_______________________________________

From report at bugs.python.org  Wed Feb 10 00:22:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Feb 2016 05:22:32 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <20160210052228.1545.55854@psf.io>


Roundup Robot added the comment:

New changeset 73f89182bb4d by Martin Panter in branch 'default':
Issue #26136: Upgrade the generator_stop warning to DeprecationWarning
https://hg.python.org/cpython/rev/73f89182bb4d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26136>
_______________________________________

From report at bugs.python.org  Wed Feb 10 00:28:23 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 10 Feb 2016 05:28:23 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455082103.68.0.104644087665.issue26318@psf.upfronthosting.co.za>


???? ????????? added the comment:

in any case, passing INTEGER as name is wrong thing, since (due to duck typing), name should be a string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26318>
_______________________________________

From report at bugs.python.org  Wed Feb 10 00:35:42 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Feb 2016 05:35:42 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <1455082542.97.0.854153050014.issue25698@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

That seems fine except you might as well just put the GetWithError prototype in the header file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25698>
_______________________________________

From report at bugs.python.org  Wed Feb 10 00:47:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Feb 2016 05:47:07 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzMDRdIEZpeCDigJxhbGxvd3MgdG8gPHZlcmI+4oCdIGluIGRv?=
 =?utf-8?q?cumentation?=
In-Reply-To: <1454918132.41.0.149238322531.issue26304@psf.upfronthosting.co.za>
Message-ID: <20160210054700.40084.89736@psf.io>


Roundup Robot added the comment:

New changeset 818e91105418 by Martin Panter in branch '3.5':
Issue #26304: Change "allows to <verb>" to "allows <verb>ing" or similar
https://hg.python.org/cpython/rev/818e91105418

New changeset d01abc2d5197 by Martin Panter in branch 'default':
Issue #26304: Merge doc wording from 3.5
https://hg.python.org/cpython/rev/d01abc2d5197

New changeset 37f6f965023d by Martin Panter in branch 'default':
Issue #26304: Additional ?allows to? fix specific to 3.6
https://hg.python.org/cpython/rev/37f6f965023d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26304>
_______________________________________

From report at bugs.python.org  Wed Feb 10 00:50:45 2016
From: report at bugs.python.org (Florian Bruhin)
Date: Wed, 10 Feb 2016 05:50:45 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455083445.0.0.586311727619.issue26323@psf.upfronthosting.co.za>


Florian Bruhin added the comment:

I agree this would be useful. "assert themock.called" (or self.assertTrue) works, but always trips me up.

----------
nosy: +The Compiler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Wed Feb 10 00:51:32 2016
From: report at bugs.python.org (Florian Bruhin)
Date: Wed, 10 Feb 2016 05:51:32 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455083492.88.0.0851112565795.issue26323@psf.upfronthosting.co.za>


Changes by Florian Bruhin <python.org at the-compiler.org>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Wed Feb 10 01:31:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Feb 2016 06:31:30 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzMDRdIEZpeCDigJxhbGxvd3MgdG8gPHZlcmI+4oCdIGluIGRv?=
 =?utf-8?q?cumentation?=
In-Reply-To: <1454918132.41.0.149238322531.issue26304@psf.upfronthosting.co.za>
Message-ID: <20160210063122.61960.78424@psf.io>


Roundup Robot added the comment:

New changeset 4cfc19f667aa by Martin Panter in branch '2.7':
Issue #26304: Change "allows to <verb>" to "allows <verb>ing" or similar
https://hg.python.org/cpython/rev/4cfc19f667aa

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26304>
_______________________________________

From report at bugs.python.org  Wed Feb 10 01:37:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 06:37:30 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzMDRdIEZpeCDigJxhbGxvd3MgdG8gPHZlcmI+4oCdIGluIGRv?=
 =?utf-8?q?cumentation?=
In-Reply-To: <1454918132.41.0.149238322531.issue26304@psf.upfronthosting.co.za>
Message-ID: <1455086250.42.0.718086359733.issue26304@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the reviews, and spotting my typo. I also sneaked in eight more changes (?allowing to?), to asyncio-eventloop.rst, ctypes.rst, whatsnew/3.3.rst, howto/pyporting.rst, Misc/NEWS, and Misc/HISTORY.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26304>
_______________________________________

From report at bugs.python.org  Wed Feb 10 01:42:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 06:42:13 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1455086533.88.0.719334568799.issue26136@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for your work Anish

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26136>
_______________________________________

From report at bugs.python.org  Wed Feb 10 01:50:31 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Feb 2016 06:50:31 +0000
Subject: [issue26324] sum() incorrect on negative zeros
In-Reply-To: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>
Message-ID: <1455087031.93.0.639840192039.issue26324@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

For what it's worth, NumPy has exactly the same behaviour:

>>> np.array([-0.0, -0.0]).sum()
0.0

... which is a bit surprising, given that this is a much easier problem to fix when you know the type of everything in the array in advance.

The Decimal type has similar issues here, resulting from that implicit addition of 0:

>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 5
>>> x = Decimal('3.1415926535893')
>>> sum([x])
Decimal('3.1416')

Fixing this would involve major changes to the way that sum works, or some horrible DWIM special-casing; I think it's best left as it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26324>
_______________________________________

From report at bugs.python.org  Wed Feb 10 01:51:57 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Feb 2016 06:51:57 +0000
Subject: [issue26324] sum() incorrect on negative zeros
In-Reply-To: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>
Message-ID: <1455087117.65.0.296678345574.issue26324@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I think it's best left as it is

I concur.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26324>
_______________________________________

From report at bugs.python.org  Wed Feb 10 01:52:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 06:52:33 +0000
Subject: [issue26253] tarfile in stream mode always set zlib compression level
 to 9
In-Reply-To: <1454288123.43.0.462874591937.issue26253@psf.upfronthosting.co.za>
Message-ID: <1455087153.04.0.690957429244.issue26253@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually it?s not really obvious from the signatures, but in the middle of the tarfile.open() documentation it says ?. . . tarfile.open() accepts the keyword argument _compresslevel_?, so it should already be possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26253>
_______________________________________

From report at bugs.python.org  Wed Feb 10 01:56:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 06:56:03 +0000
Subject: [issue25496] tarfile: Default value for compresslevel is not
 documented
In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>
Message-ID: <1455087363.89.0.0794284278902.issue25496@psf.upfronthosting.co.za>


Martin Panter added the comment:

For gzip compression, there is also a proposal to change the default: Issue 26253.

Anyway, the patch looks good for now.

----------
nosy: +martin.panter
stage: needs patch -> patch review
versions: +Python 2.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25496>
_______________________________________

From report at bugs.python.org  Wed Feb 10 02:11:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 07:11:26 +0000
Subject: [issue26204] compiler: ignore constants used as statements (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1455057485.89.0.139242332521.issue26204@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZnx7hDckCKA+Wsmf+KWScDDTuBs0k5Bb4cJLuYfG_urA@mail.gmail.com>


STINNER Victor added the comment:

Sorry you are late :-) I started a thread on python-dev and it was decided
to let linters handle this warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26204>
_______________________________________

From report at bugs.python.org  Wed Feb 10 02:54:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 07:54:20 +0000
Subject: [issue25937] DIfference between utf8 and utf-8 when i define python
 source code encoding.
In-Reply-To: <1450928989.2.0.861306801503.issue25937@psf.upfronthosting.co.za>
Message-ID: <1455090860.85.0.413917453173.issue25937@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think the correct way is not add "utf8" to special case, but removes "utf-8". Here is a patch.

----------
components: +Interpreter Core
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file41879/bad_utf8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25937>
_______________________________________

From report at bugs.python.org  Wed Feb 10 03:33:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Feb 2016 08:33:33 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <20160210083330.11245.58784@psf.io>


Roundup Robot added the comment:

New changeset 81dba6e392c3 by Serhiy Storchaka in branch '2.7':
Issue #25698: Importing module if the stack is too deep no longer replaces
https://hg.python.org/cpython/rev/81dba6e392c3

New changeset 1c2de3b0a474 by Serhiy Storchaka in branch '3.5':
Issue #25698: Prevent possible replacing imported module with the empty one
https://hg.python.org/cpython/rev/1c2de3b0a474

New changeset c711c36cf988 by Serhiy Storchaka in branch 'default':
Issue #25698: Prevent possible replacing imported module with the empty one
https://hg.python.org/cpython/rev/c711c36cf988

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25698>
_______________________________________

From report at bugs.python.org  Wed Feb 10 03:36:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 08:36:16 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <1455093376.73.0.451871363281.issue25698@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> That seems fine except you might as well just put the GetWithError prototype in the header file.

Yes, of course. It was temporary placed here to avoid rebuilding all sources.

Thank you Barry and Benjamin for investigating this issue.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25698>
_______________________________________

From report at bugs.python.org  Wed Feb 10 03:43:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 08:43:12 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1455093792.52.0.264680500905.issue25985@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses SilentGhosts comments.

----------
Added file: http://bugs.python.org/file41880/use_version_info_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25985>
_______________________________________

From report at bugs.python.org  Wed Feb 10 03:52:06 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Feb 2016 08:52:06 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455094325.99.0.629434017775.issue26289@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

A couple more observations:

1. I think you're missing the final multiplication by Py_SIZE(b) in the fast_mod code. Which is odd, because your tests should catch that. So either you didn't run the tests, or that code path isn't being used somehow.

2. Talking of tests, it would be good to have tests (for both // and %) for the case where the dividend is an exact multiple of the divisor.

3. Negative divisors almost never come up in real life, so you might also consider restricting the optimisations to the case Py_SIZE(b) == 1 (rather than ABS(Py_SIZE(b)) == 1). If that makes any speed difference at all for the case of positive divisors, then it's probably worth it. If not, then don't worry about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26289>
_______________________________________

From report at bugs.python.org  Wed Feb 10 03:52:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 10 Feb 2016 08:52:07 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1455094327.47.0.827585859845.issue25985@psf.upfronthosting.co.za>


SilentGhost added the comment:

No further comments from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25985>
_______________________________________

From report at bugs.python.org  Wed Feb 10 04:03:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 09:03:30 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455095010.07.0.48899075798.issue25994@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Martins comments.

----------
Added file: http://bugs.python.org/file41881/scandir_close_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25994>
_______________________________________

From report at bugs.python.org  Wed Feb 10 04:06:52 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Feb 2016 09:06:52 +0000
Subject: [issue26320] Web documentation for 2.7 has unreadable highlights in
 Table of Contents
In-Reply-To: <1455023796.48.0.712407093962.issue26320@psf.upfronthosting.co.za>
Message-ID: <1455095212.95.0.988742244946.issue26320@psf.upfronthosting.co.za>


Georg Brandl added the comment:

That's possible. I'll have a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26320>
_______________________________________

From report at bugs.python.org  Wed Feb 10 04:25:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 09:25:30 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455096330.38.0.381300605507.issue25994@psf.upfronthosting.co.za>


STINNER Victor added the comment:

scandir_close_4.patch LGTM, I just added a comment on test_os.py, you may factorize the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25994>
_______________________________________

From report at bugs.python.org  Wed Feb 10 05:02:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 10:02:15 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1455098535.34.0.464930020923.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The test suite can be run directly from the source tree. The test suite includes timing information for individual tests and for the the entire test. Sample invocation:

I extracted the slowest test (test_polyroots_legendre) and put it in a loop of 5 iterations: see attached mpmath_bench.py. I ran this benchmark on Linux with 4 isolated CPU (/sys/devices/system/cpu/isolated=2-3,6-7).
http://haypo-notes.readthedocs.org/misc.html#reliable-micro-benchmarks

On such setup, the benchmark looks stable. Example:

Run #1/5: 12.28 sec
Run #2/5: 12.27 sec
Run #3/5: 12.29 sec
Run #4/5: 12.28 sec
Run #5/5: 12.30 sec

test_polyroots_legendre (min of 5 runs):

* Original: 12.51 sec
* fastint5_4.patch: (min of 5 runs): 12.27 sec (-1.9%)
* fastint6.patch: 12.21 sec (-2.4%)

I ran tests without GMP, to stress the Python int type.

I guess that the benchmark is dominated by CPU time spent on computing operations on large Python int, not by the time spent in ceval.c. So the speedup is low (2%). Such use case doesn't seem to benefit of micro optimization discussed in this issue.

mpmath is an arbitrary-precision floating-point arithmetic using Python int (or GMP if available).

----------
Added file: http://bugs.python.org/file41882/mpmath_bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21955>
_______________________________________

From report at bugs.python.org  Wed Feb 10 05:14:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 10:14:02 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
Message-ID: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Victor proposed in issue25994 to use special context manager to check that no ResourceWarning is emitted. I think that this helper can be useful in other tests. It saves 3 lines for every use. Proposed patch adds it in test.support.

----------
components: Tests
files: test_support_check_no_resource_warning.patch
keywords: patch
messages: 260000
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add helper to check that no ResourceWarning is emitted
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41883/test_support_check_no_resource_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Wed Feb 10 05:15:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 10:15:17 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
In-Reply-To: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>
Message-ID: <1455099317.63.0.508981516212.issue26325@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Wed Feb 10 05:26:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 10:26:22 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
In-Reply-To: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>
Message-ID: <1455099982.0.0.769801783386.issue26325@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I didn't expect that so many existing test already use the same pattern to check for ResourceWarning. Nice patch!

I added a comment: we must be careful in the documentation of the helper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Wed Feb 10 05:37:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 10:37:00 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
In-Reply-To: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>
Message-ID: <1455100620.59.0.835737134081.issue26325@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was about to suggest adding this to test.support as well. Patch looks good to me.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Wed Feb 10 05:40:19 2016
From: report at bugs.python.org (=?utf-8?q?Andreas_R=C3=B6hler?=)
Date: Wed, 10 Feb 2016 10:40:19 +0000
Subject: [issue26326] Named entity "vertical line" missed in 2.7
 htmlentitydefs.py
Message-ID: <56BB13AF.2030906@online.de>


New submission from Andreas R?hler:

Shouldn't a named entity  "vbar"  or "vline" be part of dict in 
htmlentitydefs.py?

Thanks,

Andreas

----------
messages: 260003
nosy: andreas.roehler
priority: normal
severity: normal
status: open
title: Named entity "vertical line" missed in 2.7 htmlentitydefs.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26326>
_______________________________________

From report at bugs.python.org  Wed Feb 10 06:01:20 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Wed, 10 Feb 2016 11:01:20 +0000
Subject: [issue24015] timeit should start with 1 loop, not 10
In-Reply-To: <1429536484.03.0.469371276206.issue24015@psf.upfronthosting.co.za>
Message-ID: <1455102080.25.0.630762251443.issue24015@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

I don't know what happened to this issue, but it looks good to me. So here is a patch for it as Joachim suggested.

$ time ./python -m timeit "import time; time.sleep(1.0)"
1 loops, best of 3: 1 sec per loop

real	0m4.134s
user	0m0.116s
sys	0m0.004s

----------
keywords: +patch
nosy: +beng94
Added file: http://bugs.python.org/file41884/timeit_num.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24015>
_______________________________________

From report at bugs.python.org  Wed Feb 10 06:13:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 11:13:40 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
In-Reply-To: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>
Message-ID: <1455102820.52.0.911970755376.issue26325@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Addressed Victor's comments.

This pattern is not widely used. Usually only raising ResourceWarning is tested, but not non-raising.

----------
Added file: http://bugs.python.org/file41885/test_support_check_no_resource_warning_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Wed Feb 10 07:45:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Feb 2016 12:45:07 +0000
Subject: [issue26320] Web documentation for 2.7 has unreadable highlights in
 Table of Contents
In-Reply-To: <1455023796.48.0.712407093962.issue26320@psf.upfronthosting.co.za>
Message-ID: <20160210124502.6675.86535@psf.io>


Roundup Robot added the comment:

New changeset 5715a6d9ff12 by Georg Brandl in branch '2.7':
Closes #26320: fix stylesheet after Sphinx update.
https://hg.python.org/cpython/rev/5715a6d9ff12

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26320>
_______________________________________

From report at bugs.python.org  Wed Feb 10 07:45:38 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Feb 2016 12:45:38 +0000
Subject: [issue26320] Web documentation for 2.7 has unreadable highlights in
 Table of Contents
In-Reply-To: <1455023796.48.0.712407093962.issue26320@psf.upfronthosting.co.za>
Message-ID: <1455108338.93.0.791702244051.issue26320@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Should be fixed now (a rebuild of the online docs will be done within a few hours). Thanks for the report!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26320>
_______________________________________

From report at bugs.python.org  Wed Feb 10 07:59:50 2016
From: report at bugs.python.org (Sebastian Bank)
Date: Wed, 10 Feb 2016 12:59:50 +0000
Subject: [issue26327] File > Save in IDLE shell window not working
Message-ID: <1455109189.98.0.269293952823.issue26327@psf.upfronthosting.co.za>


New submission from Sebastian Bank:

Under Python 2.7.11 (Win 7), saving of the IDLE shell output produces no file if the output contains non-ASCII characters, e.g. after doing (before this, it does work):

>>> print u'sp\xe4m'
sp?m
>>> 

When saving (generally), the cursor also moves to the next line.

Maybe the default file type for the shell save dialog(s) can be changed from 'Python Files (*.py, *.pyw)' to the other entry 'Text files (*.txt)' as the resulting file will normally not be a valid Python file (e.g. due to '>>>' prompts).

----------
components: IDLE
messages: 260008
nosy: xflr6
priority: normal
severity: normal
status: open
title: File > Save in IDLE shell window not working
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26327>
_______________________________________

From report at bugs.python.org  Wed Feb 10 08:03:44 2016
From: report at bugs.python.org (Laurent Bigonville)
Date: Wed, 10 Feb 2016 13:03:44 +0000
Subject: [issue26328] shutil._copyxattr() function shouldn't fail if setting
 security.selinux xattr fails
Message-ID: <1455109424.72.0.659631056233.issue26328@psf.upfronthosting.co.za>


New submission from Laurent Bigonville:

Hi,

In the _copyxattr() function from the shutil module, the function throw an exception as soon as the copy of an attribute is failing.

But setting the "security.selinux" xattr will likely fail if selinux is enforcing more.

If this function is supposed to behave like cp -a, failing to set the security.selinux xattr shouldn't be fatal


See: https://bugs.python.org/issue14082 and https://bugs.python.org/msg157903

----------
components: Library (Lib)
messages: 260009
nosy: bigon
priority: normal
severity: normal
status: open
title: shutil._copyxattr() function shouldn't fail if setting security.selinux xattr fails
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26328>
_______________________________________

From report at bugs.python.org  Wed Feb 10 08:14:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 13:14:45 +0000
Subject: [issue24015] timeit should start with 1 loop, not 10
In-Reply-To: <1429536484.03.0.469371276206.issue24015@psf.upfronthosting.co.za>
Message-ID: <1455110085.63.0.986968380955.issue24015@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that only one loop is not enough to get reliable result. The first loop often has an overhead.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24015>
_______________________________________

From report at bugs.python.org  Wed Feb 10 09:00:59 2016
From: report at bugs.python.org (Kevin Dwyer)
Date: Wed, 10 Feb 2016 14:00:59 +0000
Subject: [issue26326] Named entity "vertical line" missed in 2.7
 htmlentitydefs.py
In-Reply-To: <56BB13AF.2030906@online.de>
Message-ID: <1455112859.38.0.0758571554493.issue26326@psf.upfronthosting.co.za>


Kevin Dwyer added the comment:

The docs describe the entitydefs mapping as "A dictionary mapping XHTML 1.0 entity definitions to their replacement text in ISO Latin-1".

Neither 'vbar' nor 'vline' seem to be part of the xhtml entity definitions (https://www.w3.org/TR/xhtml1/dtds.html).

The entitydefs mapping does include 'brvbar' (broken vertical bar), and in Python 3.3+ html.entities.html5 provides 'vert;'

----------
nosy: +kdwyer
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26326>
_______________________________________

From report at bugs.python.org  Wed Feb 10 09:06:01 2016
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Wed, 10 Feb 2016 14:06:01 +0000
Subject: [issue17956] add ScheduledExecutor
In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za>
Message-ID: <1455113161.8.0.00868067143499.issue17956@psf.upfronthosting.co.za>


Tin Tvrtkovi? added the comment:

It's a shame this has been stuck in review for 2.5 years, I could really use something like this right now.

neologix, why don't you put this up on PyPI for a while, at least?

----------
nosy: +tinchester

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17956>
_______________________________________

From report at bugs.python.org  Wed Feb 10 09:37:39 2016
From: report at bugs.python.org (Laurent Bigonville)
Date: Wed, 10 Feb 2016 14:37:39 +0000
Subject: [issue26328] shutil._copyxattr() function shouldn't fail if setting
 security.selinux xattr fails
In-Reply-To: <1455109424.72.0.659631056233.issue26328@psf.upfronthosting.co.za>
Message-ID: <1455115059.25.0.00206202226078.issue26328@psf.upfronthosting.co.za>


Laurent Bigonville added the comment:

SELinux would block setting the "security.selinux" attribute with EACCES not EPERM, so another solution could be to add errono.EACCES to the list

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26328>
_______________________________________

From report at bugs.python.org  Wed Feb 10 09:39:42 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Wed, 10 Feb 2016 14:39:42 +0000
Subject: [issue24015] timeit should start with 1 loop, not 10
In-Reply-To: <1429536484.03.0.469371276206.issue24015@psf.upfronthosting.co.za>
Message-ID: <1455115182.88.0.430100659417.issue24015@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

Then maybe the docs should be clarified. 

"If -n is not given, a suitable number of loops is calculated by trying successive powers of 10 (starting from 10) until the total time is at least 0.2 seconds."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24015>
_______________________________________

From report at bugs.python.org  Wed Feb 10 09:48:02 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Feb 2016 14:48:02 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1455093376.73.0.451871363281.issue25698@psf.upfronthosting.co.za>
Message-ID: <20160210094758.74d84ed7@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

Thanks for digging deeply and fixing this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25698>
_______________________________________

From report at bugs.python.org  Wed Feb 10 09:58:05 2016
From: report at bugs.python.org (Fred Rolland)
Date: Wed, 10 Feb 2016 14:58:05 +0000
Subject: [issue26329] os.path.normpath("//") returns //
Message-ID: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za>


New submission from Fred Rolland:

Hi,

os.path.normpath("//") returns '//'

I would expect to be '/'

>>> os.path.normpath("//")
'//'
>>> os.path.normpath("///")
'/'
>>> os.path.normpath("////")
'/'

----------
components: Library (Lib)
messages: 260016
nosy: Fred Rolland
priority: normal
severity: normal
status: open
title: os.path.normpath("//") returns //
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26329>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:11:17 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 10 Feb 2016 15:11:17 +0000
Subject: [issue26330] shutil.disk_usage() on Windows can't properly handle
 unicode
Message-ID: <1455117077.45.0.531847730839.issue26330@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

On Python 3.4, Windows 7:

>>> import shutil, os
>>> path = 'psuugxik1s0?'
>>> os.stat(path)
os.stat_result(st_mode=33206, st_ino=6755399441249628, st_dev=3158553679, st_nlink=1, st_uid=0, st_gid=0, st_size=27136, st_atime=1455
116789, st_mtime=1455116789, st_ctime=1455116789)
>>>
>>> shutil.disk_usage(path)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python34\lib\shutil.py", line 989, in disk_usage
    total, free = nt._getdiskusage(path)
NotADirectoryError: [WinError 267] The directory name is invalid
>>>

----------
messages: 260017
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: shutil.disk_usage() on Windows can't properly handle unicode
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:15:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 15:15:54 +0000
Subject: [issue26330] shutil.disk_usage() on Windows can't properly handle
 unicode
In-Reply-To: <1455117077.45.0.531847730839.issue26330@psf.upfronthosting.co.za>
Message-ID: <1455117354.04.0.837074784344.issue26330@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>    total, free = nt._getdiskusage(path)
> NotADirectoryError: [WinError 267] The directory name is invalid

The underlying C function is GetDiskFreeSpaceEx():
https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa364937%28v=vs.85%29.aspx

It takes a lpDirectoryName parameter: "A directory on the disk."

Is psuugxik1s0? a directory?

It looks more like a shutil.disk_usage() documentation issue than an Unicode issue.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:16:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 15:16:03 +0000
Subject: [issue26330] shutil.disk_usage() on Windows can't properly handle
 unicode
In-Reply-To: <1455117077.45.0.531847730839.issue26330@psf.upfronthosting.co.za>
Message-ID: <1455117363.53.0.454481868721.issue26330@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation, Windows
nosy: +docs at python, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:17:48 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 10 Feb 2016 15:17:48 +0000
Subject: [issue26329] os.path.normpath("//") returns //
In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za>
Message-ID: <1455117468.51.0.192700980509.issue26329@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
assignee:  -> serhiy.storchaka
nosy: +ebarry, serhiy.storchaka
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26329>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:32:27 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 10 Feb 2016 15:32:27 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455118347.3.0.638544963494.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching an updated patch.

> 1. I think you're missing the final multiplication by Py_SIZE(b) in the fast_mod code. Which is odd, because your tests should catch that. So either you didn't run the tests, or that code path isn't being used somehow.

Thanks.  Not sure how this happened :(

> 2. Talking of tests, it would be good to have tests (for both // and %) for the case where the dividend is an exact multiple of the divisor.

Done.

> 3. Negative divisors almost never come up in real life, so you might also consider restricting the optimisations to the case Py_SIZE(b) == 1 (rather than ABS(Py_SIZE(b)) == 1). If that makes any speed difference at all for the case of positive divisors, then it's probably worth it. If not, then don't worry about it.

Tried it, the difference is very small.  For modulo division it's ~0.225 usec vs ~0.23 usec for [-m timeit -s "x=22331" "x%2;x%3;x%4;x%5;x%6;x%7;x%8;x%99;x%100;"]

----------
Added file: http://bugs.python.org/file41886/fast_divmod_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26289>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:35:42 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 10 Feb 2016 15:35:42 +0000
Subject: [issue26330] shutil.disk_usage() on Windows can't properly handle
 unicode
In-Reply-To: <1455117077.45.0.531847730839.issue26330@psf.upfronthosting.co.za>
Message-ID: <1455118542.05.0.804595216056.issue26330@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

You are right, my bad. I'll fix doc mentioning that on Windows "path" can only be a directory (on UNIX it can also be a file).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:36:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 15:36:47 +0000
Subject: [issue26330] shutil.disk_usage() on Windows can't properly handle
 unicode
In-Reply-To: <1455117077.45.0.531847730839.issue26330@psf.upfronthosting.co.za>
Message-ID: <1455118607.23.0.689989668057.issue26330@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> You are right, my bad.

No problem. I read the doc before replying, and it is not said that the path must exist or must be a directory:
https://docs.python.org/dev/library/shutil.html#shutil.disk_usage

> I'll fix doc mentioning that on Windows "path" can only be a directory (on UNIX it can also be a file).

Great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:41:48 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 10 Feb 2016 15:41:48 +0000
Subject: [issue26330] shutil.disk_usage() on Windows can't properly handle
 unicode
In-Reply-To: <1455117077.45.0.531847730839.issue26330@psf.upfronthosting.co.za>
Message-ID: <1455118908.82.0.872288424412.issue26330@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Different but kind of related, disk_usage() is not able to accept bytes:

>>> shutil.disk_usage(b'.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python34\lib\shutil.py", line 989, in disk
    total, free = nt._getdiskusage(path)
TypeError: must be str, not bytes
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Wed Feb 10 10:44:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 15:44:32 +0000
Subject: [issue26330] shutil.disk_usage() on Windows can't properly handle
 unicode
In-Reply-To: <1455118908.82.0.872288424412.issue26330@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaZOxEUMY0kBAtpTsgyW=cZroBjJN4PveneB=UKhRg8vw@mail.gmail.com>


STINNER Victor added the comment:

> Different but kind of related, disk_usage() is not able to accept bytes:

On Python 3, I don't think that it's a big issue: bytes filenames are
deprecated.

See the current thread on python-dev:
https://mail.python.org/pipermail/python-dev/2016-February/143150.html

It's really much better to use Unicode on Windows, and I also suggest
you to use Unicode on UNIX/BSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Wed Feb 10 11:01:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 16:01:15 +0000
Subject: [issue26329] os.path.normpath("//") returns //
In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za>
Message-ID: <1455120075.57.0.729505549244.issue26329@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue636648.

This is intended behavior. It was introduced in changeset 01d5b80a3c03.

>From the POSIX Specification [1]:

"""
A pathname consisting of a single <slash> shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. If a pathname begins with two successive <slash> characters, the first component following the leading <slash> characters may be interpreted in an implementation-defined manner, although more than two leading <slash> characters shall be treated as a single <slash> character.
"""

See also Stack Overflow and Stack Exchange questions: [2], [3], [4].

May be we should add an explanation and a link to the specification in the documentation and comments.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12
[2] http://stackoverflow.com/questions/7816818/why-doesnt-os-normapath-collapse-a-leading-double-slash
[3] http://unix.stackexchange.com/questions/12283/unix-difference-between-path-starting-with-and
[4] http://unix.stackexchange.com/questions/1910/how-does-linux-handle-multiple-consecutive-path-separators-home-username

----------
components: +Documentation -Library (Lib)
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26329>
_______________________________________

From report at bugs.python.org  Wed Feb 10 11:12:31 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Feb 2016 16:12:31 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455120751.71.0.201420680863.issue26289@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks for the updates! No further comments from me - the patch looks good as far as I'm concerned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26289>
_______________________________________

From report at bugs.python.org  Wed Feb 10 12:09:49 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 10 Feb 2016 17:09:49 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455124189.43.0.0713325743113.issue26289@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


Added file: http://bugs.python.org/file41887/fast_divmod_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26289>
_______________________________________

From report at bugs.python.org  Wed Feb 10 12:27:22 2016
From: report at bugs.python.org (Erik Purins)
Date: Wed, 10 Feb 2016 17:27:22 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1455125242.65.0.620522990669.issue23078@psf.upfronthosting.co.za>


Changes by Erik Purins <erik at purins.com>:


----------
nosy: +epu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Wed Feb 10 12:50:25 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Feb 2016 17:50:25 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
Message-ID: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>


New submission from Georg Brandl:

As discussed on python-ideas: https://mail.python.org/pipermail/python-ideas/2016-February/038354.html

The rules are: 
Underscores are allowed anywhere in numeric literals, except:

* at the beginning of a literal (obviously)
* at the end of a literal
* directly after a dot (since the underscore could start an attribute name)
* directly after a sign in exponents (for consistency with leading signs)
* in the middle of the "0x", "0o" or "0b" base specifiers

Currently this only touches literals, not the inputs of int() or float().  Whether they should accept this syntax is debatable (I'd vote no).

Otherwise missing: doc updates.

Review question: is PyMem_RawStrdup/RawFree the right API to use here?

----------
components: Interpreter Core
files: numeric_underscores.diff
keywords: patch
messages: 260026
nosy: georg.brandl
priority: normal
severity: normal
stage: patch review
status: open
title: Tokenizer: allow underscores for grouping in numeric literals
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41888/numeric_underscores.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 12:52:56 2016
From: report at bugs.python.org (Justin Mayfield)
Date: Wed, 10 Feb 2016 17:52:56 +0000
Subject: [issue25593] _sock_connect_cb can be called twice resulting in
 InvalidStateError
In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za>
Message-ID: <1455126776.76.0.80838976192.issue25593@psf.upfronthosting.co.za>


Justin Mayfield added the comment:

Alexander,

That sounds unrelated.  I'd treat it as a new issue until you have concrete evidence to the contrary.

Also on face value it sounds like it might just be your operating systems open file limit.  On OSX I think the default open file limit is in the hundreds (256 on my box).  Generally on unix-oid platforms it can be checked and changed with the `ulimit -n` command.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25593>
_______________________________________

From report at bugs.python.org  Wed Feb 10 12:54:50 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 10 Feb 2016 17:54:50 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455126890.88.0.755004913144.issue26331@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 13:03:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 18:03:29 +0000
Subject: [issue26329] os.path.normpath("//") returns //
In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za>
Message-ID: <1455127409.68.0.516221450202.issue26329@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: serhiy.storchaka -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26329>
_______________________________________

From report at bugs.python.org  Wed Feb 10 13:12:52 2016
From: report at bugs.python.org (Collin Anderson)
Date: Wed, 10 Feb 2016 18:12:52 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1455127972.02.0.303234100231.issue25228@psf.upfronthosting.co.za>


Collin Anderson added the comment:

The issue I'm currently running into, is that although browsers correctly ignore invalid Set-Cookie values, they allow 'any CHAR except CTLs or ";"' in cookie values set via document.cookie.

So, if you say document.cookie = 'key=va"lue; path=/', the browser will happily pass 'key=va"lue;' to the server on future requests.

So, I like the behavior of this patch, which skips over these invalid cookies and continues parsing. I've cleaned the patch up a little, but it should be the same logically.

----------
nosy: +collinanderson
Added file: http://bugs.python.org/file41889/cookie-bracket-quotes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25228>
_______________________________________

From report at bugs.python.org  Wed Feb 10 13:25:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 18:25:53 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455128753.48.0.671579495181.issue26331@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I prefer simpler and more strict rule:

* Underscores are allowed only between digits in numeric literals.

Thus 1__2, 12_, 1_.2, 1_e2, 1e_2, 1_j, 0x_12 are not allowed.

It is easier to make the rule more lenient later if it will be needed.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 13:36:38 2016
From: report at bugs.python.org (JK)
Date: Wed, 10 Feb 2016 18:36:38 +0000
Subject: [issue26332] OSError: exception: access violation writing <...>
 (Windows 10 x64, Python 3.5.1)
Message-ID: <1455129398.68.0.407875580594.issue26332@psf.upfronthosting.co.za>


New submission from JK:

Hi!

I came across this mysterious bug the other week, and I haven't yet found any resolution to it. In my case, I am using a proprietary 3rd party C/C++ DLL for functionality within Python, however I've come across a few others who have run into the same issue with an open source project.

My traceback is essentially:

    return cppapi.DoSomething(hAlpha, pzString1, pzString2);
OSError: exception: access violation writing 0x00000000576EE908

However, you can see a very similar scenario taking place here too:
https://github.com/asweigart/pyperclip/issues/25

(However, I did not see a bug report filed here on behalf of them)

This MIGHT be related to http://bugs.python.org/issue20160 but I am not certain.

Thanks!

----------
components: Windows, ctypes
messages: 260030
nosy: jk, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: OSError: exception: access violation writing <...> (Windows 10 x64, Python 3.5.1)
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26332>
_______________________________________

From report at bugs.python.org  Wed Feb 10 13:43:40 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Feb 2016 18:43:40 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455129820.35.0.097913967706.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It sure is more strict, but I don't think it's simpler (and it's definitely not simpler to implement).

(Also 1_j is pretty nice, I wouldn't want to lose that.)

We can also check what other languages do.

* Rust: very much like this, but trailing underscores allowed.
* Perl 5: same as here, but underscores after dot and trailing underscores allowed.
* Ruby: only between digits.

* Swift: the grammar productions say it's basically the same as Rust.  The textual description says "between digits".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 14:03:45 2016
From: report at bugs.python.org (Aaron Halfaker)
Date: Wed, 10 Feb 2016 19:03:45 +0000
Subject: [issue26333] Multiprocessing imap hangs when generator input errors
Message-ID: <1455131025.64.0.640942257663.issue26333@psf.upfronthosting.co.za>


New submission from Aaron Halfaker:

multiprocessing.imap will hang and not raise an error if an error occurs in the generator that is being mapped over.  I'd expect the error to be raised and/or the process to fail.  

For example, run the following code in python 2.7 or 3.4:

    from multiprocessing import Pool

    def add_one(v):
        return v+1

    pool = Pool(processes=2)

    values = ["1", "2", "3", "4", "foo", "5", "6", "7", "8"]
    value_iter = (int(v) for v in values)

    for new_val in pool.imap(add_one, value_iter):
        print(new_val)

And output should look something like this:

    $ python demo_hanging.py 
    2
    3
    4
    5
    Exception in thread Thread-2:
    Traceback (most recent call last):
      File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
        self.run()
      File "/usr/lib/python3.4/threading.py", line 868, in run
        self._target(*self._args, **self._kwargs)
      File "/usr/lib/python3.4/multiprocessing/pool.py", line 378, in _handle_tasks
        for i, task in enumerate(taskseq):
      File "/usr/lib/python3.4/multiprocessing/pool.py", line 286, in <genexpr>
        self._taskqueue.put((((result._job, i, func, (x,), {})
      File "demo_hanging.py", line 9, in <genexpr>
        value_iter = (int(v) for v in values)
    ValueError: invalid literal for int() with base 10: 'foo'

The script will then hang indefinitely.

----------
components: Library (Lib)
messages: 260032
nosy: Aaron Halfaker
priority: normal
severity: normal
status: open
title: Multiprocessing imap hangs when generator input errors
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26333>
_______________________________________

From report at bugs.python.org  Wed Feb 10 14:04:27 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 10 Feb 2016 19:04:27 +0000
Subject: [issue26333] Multiprocessing imap hangs when generator input errors
In-Reply-To: <1455131025.64.0.640942257663.issue26333@psf.upfronthosting.co.za>
Message-ID: <1455131067.85.0.218402899442.issue26333@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +jnoller, sbt
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26333>
_______________________________________

From report at bugs.python.org  Wed Feb 10 14:46:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 19:46:55 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455133615.94.0.754016409256.issue26331@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

* Java: only between digits. [1]
* Julia: only between digits. [2] (not well specified)
* C# 7.0 (proposal): only between digits, but adjacent underscores allowed. [3]
* Ada: only between digits. [4] (strong but very simple rules)
* D: very much like proposed patch, but trailing underscores allowed. [5]
* Perl 5: only between digits as documented (23__500 is not legal), but actually more lenient. [6]

[1] https://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html
[2] http://docs.julialang.org/en/release-0.4/manual/integers-and-floating-point-numbers/
[3] https://github.com/dotnet/roslyn/issues/216
[4] http://archive.adaic.com/standards/83lrm/html/lrm-02-04.html#2.4
[5] http://dlang.org/spec/lex.html#integerliteral
[6] http://perldoc.perl.org/perldata.html#Scalar-value-constructors

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 14:52:44 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Wed, 10 Feb 2016 19:52:44 +0000
Subject: [issue26334] bytes.translate() doesn't take keyword arguments;
 docs suggests it does
Message-ID: <1455133964.48.0.745384045329.issue26334@psf.upfronthosting.co.za>


New submission from Nicholas Chammas:

The docs for `bytes.translate()` [0] show the following signature:

```
bytes.translate(table[, delete])
```

However, calling this method with keyword arguments yields:

```
>>> b''.translate(table='la table', delete=b'delete')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: translate() takes no keyword arguments
```

I'm guessing other methods have this same issue. (e.g. `str.translate()`)

Do the docs need to be updated, or should these methods be updated to accept keyword arguments, or something else?

[0] https://docs.python.org/3/library/stdtypes.html#bytes.translate

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 260034
nosy: Nicholas Chammas, docs at python
priority: normal
severity: normal
status: open
title: bytes.translate() doesn't take keyword arguments; docs suggests it does
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26334>
_______________________________________

From report at bugs.python.org  Wed Feb 10 15:21:17 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 10 Feb 2016 20:21:17 +0000
Subject: [issue26334] bytes.translate() doesn't take keyword arguments;
 docs suggests it does
In-Reply-To: <1455133964.48.0.745384045329.issue26334@psf.upfronthosting.co.za>
Message-ID: <1455135677.39.0.427720448349.issue26334@psf.upfronthosting.co.za>


SilentGhost added the comment:

I don't think docs suggest that in any way. The keyword arguments are typically described like this: https://docs.python.org/3/library/stdtypes.html#str.split

bytes.translate has a typical signature of a function with optional positional arguments.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26334>
_______________________________________

From report at bugs.python.org  Wed Feb 10 15:25:04 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 10 Feb 2016 20:25:04 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455135904.31.0.222167481374.issue26331@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I prefer simpler and more strict rule:
> * Underscores are allowed only between digits in numeric literals.

+1.  But in any case we need a PEP for this change.

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 15:52:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Feb 2016 20:52:18 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455137538.92.0.128921878565.issue26331@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

C++14 uses the same strict rule as Ada, but uses apostrphes instead of underscores. [1]

Thus there are two groups of languages, implementing strict or lenient rules:

* Strict: Ada, C++, Java, C#, Ruby, Julia, Perl (as documented), Swift (textual description).
* Lenient: D, Rust, Perl (actually), Swift (grammar productions).

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 16:04:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 21:04:56 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1455138296.56.0.404818262381.issue25228@psf.upfronthosting.co.za>


Martin Panter added the comment:

To move forward on this, I would like someone else (hopefully Antoine? :) to confirm my theory about the cookie injection attack, or otherwise explain why the patch won?t (re)open any security holes. Also, I would like to add some more test cases based on Sergey Bobrov?s post (especially the from the heading ??????????? ????????? Cookie #3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25228>
_______________________________________

From report at bugs.python.org  Wed Feb 10 16:31:38 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Wed, 10 Feb 2016 21:31:38 +0000
Subject: [issue26334] bytes.translate() doesn't take keyword arguments;
 docs suggests it does
In-Reply-To: <1455133964.48.0.745384045329.issue26334@psf.upfronthosting.co.za>
Message-ID: <1455139898.86.0.532771835419.issue26334@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

So you're saying if `bytes.translate()` accepted keyword arguments, its signature would look something like this?

```
bytes.translate(table, delete=None)
```

I guess I was under the mistaken assumption that argument names in the docs always matched keyword arguments in the signature.

But you're right, a strictly positional argument (I guess specified via something like `args*`?) doesn't have a name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26334>
_______________________________________

From report at bugs.python.org  Wed Feb 10 16:52:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 21:52:51 +0000
Subject: [issue17956] concurrent.futures: add ScheduledExecutor
In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za>
Message-ID: <1455141170.99.0.767668646879.issue17956@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: add ScheduledExecutor -> concurrent.futures: add ScheduledExecutor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17956>
_______________________________________

From report at bugs.python.org  Wed Feb 10 16:56:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 21:56:09 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
In-Reply-To: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>
Message-ID: <1455141369.71.0.785134419895.issue26325@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_support_check_no_resource_warning_2.patch LGTM, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Wed Feb 10 16:57:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 21:57:49 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455141469.52.0.65506310729.issue25994@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I just added a comment on test_os.py, you may factorize the code.

Ah, Serhiy created the issue #26325 for that. Nice.

It's up to you to commit this change, or #26325 first, both are good now ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25994>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:05:00 2016
From: report at bugs.python.org (Alexander Mohr)
Date: Wed, 10 Feb 2016 22:05:00 +0000
Subject: [issue25593] _sock_connect_cb can be called twice resulting in
 InvalidStateError
In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za>
Message-ID: <1455141900.04.0.97245390763.issue25593@psf.upfronthosting.co.za>


Alexander Mohr added the comment:

sorry for disruption!  ends up our router seems to be doing some kind of QoS limits on # of connections :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25593>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:07:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:07:00 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1455142020.24.0.966938628171.issue25985@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Review: LGTM, with a minor comment.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25985>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:11:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:11:24 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455142284.42.0.227700106446.issue26318@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, I don't think that it can be changed today.

io.open(int).name is an int since Python 2.6. Changing it may break applications for a little benefit.

> `io.open(fd, ...).name` returns numeric fd instead of None. This lead to some nasty bugs.

Why do you test None? Why not testing isinstance(name, int)?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26318>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:14:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:14:09 +0000
Subject: [issue26315] Optimize mod division for ints
In-Reply-To: <1454970675.84.0.301967594836.issue26315@psf.upfronthosting.co.za>
Message-ID: <1455142449.55.0.986956970906.issue26315@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Is this patch is a subset of issue #26289 patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26315>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:21:43 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Feb 2016 22:21:43 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455142903.19.0.562202800916.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

PEP 515 is written up and posted to python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:25:40 2016
From: report at bugs.python.org (Peter Brady)
Date: Wed, 10 Feb 2016 22:25:40 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1455143140.5.0.858585728087.issue25295@psf.upfronthosting.co.za>


Peter Brady added the comment:

Yes. The patch you suggested restores the old behavior of the lru_cache.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25295>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:26:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:26:50 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1455143210.93.0.426639347101.issue26200@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 3084914245d2 by Raymond Hettinger in branch 'default':
> Issue #26200:  The SETREF macro adds unnecessary work in some cases.
> https://hg.python.org/cpython/rev/3084914245d2

The code using Py_DECREF() doesn't look to be vulnerable to the bug described in Py_SETREF() doc. The change (revert) looks good to me.

So I understand that calling Py_DECREF() manually (in the "right" order, as done in the change) is a reasonable answer to users wanting a "fast" Py_SETREF().

What do you think?

I don't suggest to mention it in Py_SETREF() documentation. I would prefer that users who don't understand well reference counting (ex: me ;-)) use Py_SETREF() to avoid bugs.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26200>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:29:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:29:47 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
In-Reply-To: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>
Message-ID: <1455143387.6.0.65002181887.issue26312@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yeah, I also expect SystemError from C functions (of the Python C API) badly used.

RuntimeError is more used in programming bugs at Python level.

pyarg_parse_error.patch LGTM.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26312>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:30:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:30:22 +0000
Subject: =?utf-8?q?=5Bissue26316=5D_Probable_typo_in_Arg_Clinic=E2=80=99s_linear?=
 =?utf-8?b?X2Zvcm1hdCgp?=
In-Reply-To: <1454985153.85.0.932055658559.issue26316@psf.upfronthosting.co.za>
Message-ID: <1455143422.13.0.743552982832.issue26316@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Go ahead.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26316>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:31:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:31:55 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
In-Reply-To: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>
Message-ID: <1455143515.35.0.684360169858.issue24916@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Serhiy: Can you please take a look since this issue now depends on your issue #25985?

----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24916>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:38:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:38:46 +0000
Subject: [issue26314] interned strings are stored in a dict,
 a set would use less memory
In-Reply-To: <1454964166.73.0.652183434251.issue26314@psf.upfronthosting.co.za>
Message-ID: <1455143926.03.0.177337592458.issue26314@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Why did you remove _Py_ReleaseInternedStrings()? It looks like a big memory leak when Python is embedded.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26314>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:39:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Feb 2016 22:39:48 +0000
Subject: [issue25593] _sock_connect_cb can be called twice resulting in
 InvalidStateError
In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za>
Message-ID: <1455143988.28.0.693152997629.issue25593@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25593>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:52:55 2016
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 10 Feb 2016 22:52:55 +0000
Subject: [issue23530] os and multiprocessing.cpu_count do not respect
 cpuset/affinity
In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za>
Message-ID: <1455144775.26.0.894634541041.issue23530@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23530>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:55:37 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Wed, 10 Feb 2016 22:55:37 +0000
Subject: [issue26335] Make mmap.write return the number of bytes written like
 other write methods
Message-ID: <1455144937.95.0.515520937166.issue26335@psf.upfronthosting.co.za>


New submission from Jakub Stasiak:

Since mmap objects are said to "behave like both bytearray and like file objects" I believe it's appropriate for the mmap.write() method to return the number of bytes written like write() of other file objects/interfaces I could find in the standard library for consistency reasons:

https://docs.python.org/3/library/io.html#io.BufferedIOBase.write
https://docs.python.org/3/library/io.html#io.BufferedWriter.write
https://docs.python.org/3/library/io.html#io.RawIOBase.write
https://docs.python.org/3/library/io.html#io.TextIOBase.write

Why I believe this would be useful: code that writes to file objects and tests the number of bytes/characters written right now will likely fail when it's passed a mmap object because its write() method returns None. With this patch applied it'll work transparently.

Please find proposed patch attached, I included information about the exception type in the documentation as it seems fitting (apologies for generating the patch using Git, I'll generate using Mercurial if necessary).

----------
components: IO, Library (Lib)
keywords: patch
messages: 260053
nosy: jstasiak
priority: normal
severity: normal
status: open
title: Make mmap.write return the number of bytes written like other write methods
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41890/mmap_write_return_count.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26335>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:57:34 2016
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 10 Feb 2016 22:57:34 +0000
Subject: [issue25937] DIfference between utf8 and utf-8 when i define python
 source code encoding.
In-Reply-To: <1450928989.2.0.861306801503.issue25937@psf.upfronthosting.co.za>
Message-ID: <1455145054.32.0.237633513881.issue25937@psf.upfronthosting.co.za>


Jim Jewett added the comment:

Does (did?) the utf8 special case allow for a much faster startup time, by not requiring all of the codecs machinery?

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25937>
_______________________________________

From report at bugs.python.org  Wed Feb 10 17:58:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Feb 2016 22:58:43 +0000
Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon
 exception
In-Reply-To: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za>
Message-ID: <20160210225839.11215.21220@psf.io>


Roundup Robot added the comment:

New changeset 1ba0deb52223 by Charles-Fran?ois Natali in branch 'default':
Issue #23992: multiprocessing: make MapResult not fail-fast upon exception.
https://hg.python.org/cpython/rev/1ba0deb52223

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23992>
_______________________________________

From report at bugs.python.org  Wed Feb 10 18:05:18 2016
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 10 Feb 2016 23:05:18 +0000
Subject: [issue26324] sum() incorrect on negative zeros
In-Reply-To: <1455062882.26.0.0214307271238.issue26324@psf.upfronthosting.co.za>
Message-ID: <1455145518.97.0.305384794246.issue26324@psf.upfronthosting.co.za>


Jim Jewett added the comment:

Even if Ethan's argument about an explicit start value were not convincing, Mark + Raymond would count as authoritative for floats.

Anyone can reopen if needed; I just don't want the issue to languish forever if there is at least grudging agreement.

----------
nosy: +Jim.Jewett
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26324>
_______________________________________

From report at bugs.python.org  Wed Feb 10 18:09:43 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 10 Feb 2016 23:09:43 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455145783.01.0.367984629157.issue26331@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Regarding the patch: if trailing underscores are not allowed, `0 if 1_____else 1` should be illegal.

----------
nosy: +encukou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed Feb 10 18:10:24 2016
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 10 Feb 2016 23:10:24 +0000
Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming
 a one-to-one Pid -> process mapping.
In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za>
Message-ID: <1455145824.55.0.0396373252093.issue24303@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Anyone opposed to me committing the patch I submitted?
It slves a real problem, and is fairly straight-forward (and conceptually more correct).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24303>
_______________________________________

From report at bugs.python.org  Wed Feb 10 18:25:46 2016
From: report at bugs.python.org (Srikanth Viswanathan)
Date: Wed, 10 Feb 2016 23:25:46 +0000
Subject: [issue25882] argparse help error: arguments created by
 add_mutually_exclusive_group() are shown outside their parent group created
 by add_argument_group()
In-Reply-To: <1450271683.16.0.602190712987.issue25882@psf.upfronthosting.co.za>
Message-ID: <1455146746.66.0.121663478351.issue25882@psf.upfronthosting.co.za>


Changes by Srikanth Viswanathan <srikanthv2 at gmail.com>:


----------
nosy: +srikanth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25882>
_______________________________________

From report at bugs.python.org  Wed Feb 10 18:30:29 2016
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 10 Feb 2016 23:30:29 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
In-Reply-To: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>
Message-ID: <1455147029.9.0.564641006226.issue26312@psf.upfronthosting.co.za>


Jim Jewett added the comment:

It feels a bit odd to say that I've performed a triage review given the three people already involved -- but I did, and I think it is ready to commit.

I believe it is a bug fix, but too subtle a bug to justify backporting.

The only question is whether there should be a "What's New?" entry for the change.

----------
nosy: +Jim.Jewett
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26312>
_______________________________________

From report at bugs.python.org  Wed Feb 10 18:30:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Feb 2016 23:30:55 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
In-Reply-To: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>
Message-ID: <1455147055.86.0.735491681146.issue24916@psf.upfronthosting.co.za>


Martin Panter added the comment:

I just added the dependency to reflect that the patch here will need updating.

The main concern here is Thomas?s question: does it matter that py_version loses prerelease info?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24916>
_______________________________________

From report at bugs.python.org  Wed Feb 10 18:42:35 2016
From: report at bugs.python.org (Mike Frysinger)
Date: Wed, 10 Feb 2016 23:42:35 +0000
Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming
 a one-to-one Pid -> process mapping.
In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za>
Message-ID: <1455147755.92.0.338324927133.issue24303@psf.upfronthosting.co.za>


Mike Frysinger added the comment:

i don't feel strongly about either version

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24303>
_______________________________________

From report at bugs.python.org  Wed Feb 10 19:13:41 2016
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 11 Feb 2016 00:13:41 +0000
Subject: [issue26296] colorys rgb_to_hls algorithm error
In-Reply-To: <1454680812.05.0.172060571572.issue26296@psf.upfronthosting.co.za>
Message-ID: <1455149621.85.0.131791612844.issue26296@psf.upfronthosting.co.za>


Jim Jewett added the comment:

The modulus fixes it for exact numbers.  It doesn't produce exactly the same result with floats, because of rounding.  Is that a problem?

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26296>
_______________________________________

From report at bugs.python.org  Wed Feb 10 19:52:13 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 11 Feb 2016 00:52:13 +0000
Subject: [issue26314] interned strings are stored in a dict,
 a set would use less memory
In-Reply-To: <1454964166.73.0.652183434251.issue26314@psf.upfronthosting.co.za>
Message-ID: <1455151933.75.0.719379689329.issue26314@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Because it was only called from within an "#ifdef __INSURE__" which we weren't using.  I called it an "example" patch for a reason.  Updating that function to deal with the set instead of dict seems wise.

Ironically... a few days after we did this we may have just found reason to put _Py_ReleaseInternedStrings() back and use it when compiled using clang sanitizers.  (untested)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26314>
_______________________________________

From report at bugs.python.org  Wed Feb 10 20:18:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 01:18:44 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
In-Reply-To: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>
Message-ID: <1455153524.43.0.888649826225.issue26312@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The only question is whether there should be a "What's New?" entry for the change.

I don't think so. It's low level and nobody should see this exception anyway :-) It's an obvious bug in a C extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26312>
_______________________________________

From report at bugs.python.org  Wed Feb 10 20:43:11 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 11 Feb 2016 01:43:11 +0000
Subject: [issue25639] open 'PhysicalDriveN' on windows fails (since python
 3.5) with OSError: [WinError 1] Incorrect function
In-Reply-To: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za>
Message-ID: <1455154991.23.0.121089811515.issue25639@psf.upfronthosting.co.za>


Eryk Sun added the comment:

I'm closing this as a duplicate of issue 25717. Martin's patch fixes this problem since it's just another case of _Py_fstat failing for a valid file. In this case the problem is volume and disk files (e.g. r"\\.\C:" and r"\\.\PhysicalDrive1") that don't support querying file information.

----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25639>
_______________________________________

From report at bugs.python.org  Wed Feb 10 21:12:47 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Feb 2016 02:12:47 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1455156767.34.0.583705006271.issue13501@psf.upfronthosting.co.za>


Ned Deily added the comment:

Martin, thanks for updating the patch. I've left some review comments on Rietveld.  After reviewing it, I think Garrett's original specification is correct: there is a need for four options to preserve current expected behavior although the default is slightly more complicated than stated.  The current behavior is: enable building readline with GNU readline if found on the search paths, possibly modified by CPPFLAGS and LDFLAGS, and, if not found and on OS X, use editline if found on the search paths.  Some build scripts depend on that behavior.

----------
assignee: ned.deily -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Wed Feb 10 21:17:37 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Feb 2016 02:17:37 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1455157057.5.0.570588416717.issue13501@psf.upfronthosting.co.za>


Ned Deily added the comment:

That said, it *might* be OK to change the default behavior to just remove the "and on OS X" condition:  enable building readline with GNU readline if found on the search paths, possibly modified by CPPFLAGS and LDFLAGS, and, if not found, use editline if found on the search paths.  That's probably the desired behavior on FreeBSD systems where, AFAIK, GNU readline isn't shipped by default but BSD editline is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Wed Feb 10 22:02:37 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 11 Feb 2016 03:02:37 +0000
Subject: [issue18199] Windows: support path longer than 260 bytes using "\\?\"
 prefix
In-Reply-To: <1371050681.12.0.381093438517.issue18199@psf.upfronthosting.co.za>
Message-ID: <1455159757.02.0.743086101475.issue18199@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> There is a problem with os.chdir(): It doesn't work with
> \\?\ notation.

The process current directory is part of the Windows API, so it's subject to the MAX_PATH limit [1]. See SetCurrentDirectory [2]. Python can't do anything about this. 

As to shutil.rmtree, I agree it's an example of why the Windows path-length problem needs to be addressed more generally. Maybe there could be a __path__ special method supported by pathlib paths. On Windows this could resolve to an absolute path prefixed with "\\?\".

[1]: Native NT relative paths are relative to a handle in the 
     OBJECT_ATTRIBUTES record that's used to create or open an 
     object. This isn't generally exposed in the Windows API, 
     except in the registry API.
[2]: https://msdn.microsoft.com/en-us/library/aa365530

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18199>
_______________________________________

From report at bugs.python.org  Wed Feb 10 22:11:03 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 11 Feb 2016 03:11:03 +0000
Subject: [issue22121] IDLE should start with HOME as the initial working
 directory
In-Reply-To: <1406966032.01.0.548285467026.issue22121@psf.upfronthosting.co.za>
Message-ID: <1455160263.45.0.0937377752418.issue22121@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> What we want seems to be a normal thing to do, and achieved by 
> some, but perhaps by a post installation script.

It would help to have a couple of the bdist_wininst functions available for a post-install script:

    create_shortcut (CreateShortcut)
    get_special_folder_path (GetSpecialFolderPath)

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22121>
_______________________________________

From report at bugs.python.org  Wed Feb 10 22:26:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Feb 2016 03:26:40 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
 was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1455161200.37.0.956225076159.issue12463@psf.upfronthosting.co.za>


Martin Panter added the comment:

Michael?s patch looks like it adds some backwards compatibility problems. The forking server overwrites a signal handler, and shutdown() no longer seems to wait at all.

It seems that people want shutdown() to do different things. Mark doesn?t want it to wait for the server in case an exception stops serve_forever() from starting its loop. So he has to rely on join() rather than just shutdown() to ensure that serve_forever() will no longer run.

Antoine wants shutdown() to guarantee that serve_forever() has stopped. So he has to hope that no exception (e.g. KeyboardInterrupt) prevents serve_forever() from starting. I think I agree with this. If you want to do extra processing before calling serve_forever(), maybe use an exception handler, different thread, or synchronization mechanism to avoid the lockout problem instead. I suggest just documenting the way things work and leaving it at that.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Wed Feb 10 22:32:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Feb 2016 03:32:20 +0000
Subject: [issue13749] socketserver can't stop
In-Reply-To: <1326136769.56.0.386749729049.issue13749@psf.upfronthosting.co.za>
Message-ID: <1455161540.13.0.284409873577.issue13749@psf.upfronthosting.co.za>


Martin Panter added the comment:

For stopping a single-threaded server from a request handler, perhaps see my patch for Issue 23430, which should allow calling sys.exit() or raising exceptions like SystemExit that do not inherit Exception.

It seems to me that shutdown() can only sensibly be used from a separate thread. If a forking server is used, that thread would have to be in the initial server listening process. See also Issue 12463 for some proposals for changing shutdown().

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13749>
_______________________________________

From report at bugs.python.org  Wed Feb 10 23:05:27 2016
From: report at bugs.python.org (Jonathan Goble)
Date: Thu, 11 Feb 2016 04:05:27 +0000
Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern
 object
Message-ID: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za>


New submission from Jonathan Goble:

Once a regular expression is compiled with `obj = re.compile()`, it would be nice to have access to the raw bytecode, probably as `obj.code` or `obj.bytecode`, so it can be explored programmatically. Currently, regex bytecode is only stored in a C struct and not exposed to Python code; the only way to examine the compiled version is to pass the `re.DEBUG` flag to `re.compile()`, which prints only to stdout and outputs not the finished bytecode, but a "pretty-printed" intermediate representation useless for programmatic analysis.

This is basically requesting the equivalent of the `co_code` attribute of the code object returned by the built-in `compile()`, but for regular expression objects instead of Python code objects.

Given that the bytecode can actually be multi-byte integers, `regexobj.bytecode` should return a list (perhaps even just the same list passed to the C function?) or an `array.array()` instance, rather than a bytestring.

----------
components: Library (Lib), Regular Expressions
messages: 260072
nosy: Jonathan Goble, ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Expose regex bytecode as attribute of compiled pattern object
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26336>
_______________________________________

From report at bugs.python.org  Wed Feb 10 23:42:57 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Feb 2016 04:42:57 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
In-Reply-To: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>
Message-ID: <1455165777.39.0.126758452004.issue24916@psf.upfronthosting.co.za>


Ned Deily added the comment:

My understanding is that the "+" is added to the PY_VERSION in Include/patchlevel.h by the release management process after any tagged release, whether pre-release or final.  So '+" is supposed to be set whenever CPython is built from anything other than an official tagged revision.  AFAICT, "py_version" and friends were added to sysconfig when sysconfig was initially moved out of distutils (in fa69e891edf4) to become its own standalone module as part of the last big set of distutils enhancements which were later largely reverted, ending up with two versions of sysconfig: the newer standalone sysconfig.py and with the older distutils/sysconfig.py.  It appears "py_version" and friends have never been implemented in the distutils/sysconfig.py so it's likely that they aren't used much in the wild but it would be nice to not break the current compatibility.  Perhaps expanding sys.version_info to contain the "modified" (?) ("+") field would be a good idea or possibly adding a new value to "releaselevel".  As it currently stands:

$ /usr/local/bin/python3.5
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version
'3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]'
>>> sys.version_info
sys.version_info(major=3, minor=5, micro=1, releaselevel='final', serial=0)

$ ./python
Python 3.5.1+ (default, Feb 11 2016, 14:00:02)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version_info
sys.version_info(major=3, minor=5, micro=1, releaselevel='final', serial=0)
>>> sys.version
'3.5.1+ (default, Feb 11 2016, 14:00:02) \n[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]'

It seems wrong that one cannot use sys.version_info to distinguish between a release build and a post-release development build.  

I'm nosying Georg and Benjamin for institutional memory picking.

----------
nosy: +benjamin.peterson, georg.brandl, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24916>
_______________________________________

From report at bugs.python.org  Wed Feb 10 23:55:47 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Feb 2016 04:55:47 +0000
Subject: [issue26308] Solaris 10 build issues
In-Reply-To: <1454944020.19.0.240398292442.issue26308@psf.upfronthosting.co.za>
Message-ID: <1455166547.79.0.542705066981.issue26308@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26308>
_______________________________________

From report at bugs.python.org  Thu Feb 11 00:55:17 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Thu, 11 Feb 2016 05:55:17 +0000
Subject: [issue26337] Bypass imghdr module determines the type of image
Message-ID: <1455170117.9.0.169068464747.issue26337@psf.upfronthosting.co.za>


New submission from Ramin Farajpour Cami:

import imghdr
imghdr.what('phppng.png')

output : 
'png'

if you set javascript script in file .png or .jpg ,
output : 
ValueError: invalid \x escape

Hexdump:
root at Ramin:~# hexdump -C phppng.png
00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52
|.PNG........IHDR|
00000010  00 00 00 20 00 00 00 20  08 02 00 00 00 fc 18 ed  
|... ... ........|
00000020  a3 00 00 00 09 70 48 59  73 00 00 0e c4 00 00 0e
|.....pHYs.......|
00000030  c4 01 95 2b 0e 1b 00 00  00 60 49 44 41 54 48 89  |...+.....`IDATH.|
00000040  63 5c 3c 3f 3d 24 5f 47  45 54 5b 30 5d 28 24 5f  
|c\<?=$_GET[0]($_|  ### Here PHP Code 
00000050  50 4f 53 54 5b 31 5d 29  3b 3f 3e 58 80 81 81 c1  |POST[1]);?>X....|
00000060  73 5e 37 93 fc 8f 8b db  7e 5f d3 7d aa 27 f7 f1  |s^7.....~_.}.'..|
00000070  e3 c9 bf 5f ef 06 7c b2  30 30 63 d9 b9 67 fd d9  |..._..|.00c..g..|
00000080  3d 1b ce 32 8c 82 51 30  0a 46 c1 28 18 05 a3 60  |=..2..Q0.F.(...`|
00000090  14 8c 82 51 30 0a 86 0d  00 00 81 b2 1b 02 07 78  |...Q0..........x|
000000a0  0d 0c 00 00 00 00 49 45  4e 44 ae 42 60 82        |......IEND.B`.|
000000ae

----------
components: Library (Lib)
files: phppng.png
messages: 260074
nosy: Ramin Farajpour Cami
priority: normal
severity: normal
status: open
title: Bypass imghdr module determines the type of image
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41891/phppng.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26337>
_______________________________________

From report at bugs.python.org  Thu Feb 11 01:58:24 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Feb 2016 06:58:24 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1455173904.12.0.0915959778863.issue26200@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Most of the SETREFs in the next() functions in the itertools module should also be restored to there former state.  They look to have been correct before the change, so there was no improvement, only degradation.  Much of that code had been finely tuned and battle tested over many years -- the addition of SETREFs was gratuitous.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26200>
_______________________________________

From report at bugs.python.org  Thu Feb 11 02:09:07 2016
From: report at bugs.python.org (Jens Diemer)
Date: Thu, 11 Feb 2016 07:09:07 +0000
Subject: [issue18199] Windows: support path longer than 260 bytes using "\\?\"
 prefix
In-Reply-To: <1371050681.12.0.381093438517.issue18199@psf.upfronthosting.co.za>
Message-ID: <1455174547.93.0.0315254368016.issue18199@psf.upfronthosting.co.za>


Jens Diemer added the comment:

I have made https://github.com/jedie/pathlib_revised to address this, see: https://github.com/jedie/pathlib_revised#windows-max_path

The idea is to add a property (I call it 'extended_path') and this will add the \\?\ prefix on all absolute path under windows. Under non-Windows the property will return ".path"
And i patch methods like 'chmod', 'unlink', 'rename' etc. to use the 'extended_path' property and i add more methods like 'link', 'listdir', 'copyfile' etc.

The source code is here: https://github.com/jedie/pathlib_revised/blob/master/pathlib_revised/pathlib.py

This is another thing: Why are not all filesystem access methods implemented in pathlib?!?
e.g.: There is Path.unlink() but no Path.link()
There is Path.rmdir() but no Path.chdir()
and many more.

And the last thing is: Why is pathlib so bad designed? It's ugly to extend it. But this address: https://bugs.python.org/issue24132

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18199>
_______________________________________

From report at bugs.python.org  Thu Feb 11 03:08:41 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 08:08:41 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455178121.98.0.551620278606.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

New patch matching revision of PEP.

----------
Added file: http://bugs.python.org/file41892/numeric_underscores_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Thu Feb 11 03:15:59 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Thu, 11 Feb 2016 08:15:59 +0000
Subject: [issue26337] Bypass imghdr module determines the type of image
In-Reply-To: <1455170117.9.0.169068464747.issue26337@psf.upfronthosting.co.za>
Message-ID: <1455178559.41.0.774463969817.issue26337@psf.upfronthosting.co.za>


Changes by Ramin Farajpour Cami <ramin.blackhat at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26337>
_______________________________________

From report at bugs.python.org  Thu Feb 11 03:16:29 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 11 Feb 2016 08:16:29 +0000
Subject: [issue25937] DIfference between utf8 and utf-8 when i define python
 source code encoding.
In-Reply-To: <1450928989.2.0.861306801503.issue25937@psf.upfronthosting.co.za>
Message-ID: <1455178589.31.0.0599435094671.issue25937@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Serhiy: Removing the shortcut would slow down the tokenizer a lot since UTF-8 encoded source code is the norm, not the exception.

The "problem" here is that the tokenizer trusts the source code in being in the correct encoding when you use one of utf-8 or iso-8859-1 and then skips the usual "decode into unicode, then encode to utf-8" step.

>From a purist point of view, you are right, Python should always pass through those steps to detect encoding errors, but from a practical point of view, I think the optimization is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25937>
_______________________________________

From report at bugs.python.org  Thu Feb 11 04:32:55 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 11 Feb 2016 09:32:55 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1455183175.18.0.528893094855.issue23606@psf.upfronthosting.co.za>


Eryk Sun added the comment:

If the examples continue to use printf, then msvcrt.dll is the best option. The universal CRT exports a single Swiss-Army-knife function, __stdio_common_vfprintf, which requires 5 parameters, including a va_list for the variadic argument list. That's not appropriate for a tutorial. We just need a docs update to warn that msvcrt.dll has its own set of file descriptors, heap, and thread-locale state.

> Does it mean `cdll.msvcrt` is not the standard way to access 
> the C symbols anymore?

On a tangent, cdll.msvcrt shouldn't be recommended anywhere in the ctypes docs. All code that uses cdll.msvcrt shares the same restype, argtypes, and errcheck prototypes for each function pointer, which is an unholy mess. The docs should recommend CDLL('mscvrt') or CDLL('msvcrt', use_errno=True). Every module or package should use its own private instance of CDLL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Thu Feb 11 04:53:16 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 11 Feb 2016 09:53:16 +0000
Subject: [issue26337] Bypass imghdr module determines the type of image
In-Reply-To: <1455170117.9.0.169068464747.issue26337@psf.upfronthosting.co.za>
Message-ID: <1455184396.9.0.289886318331.issue26337@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I'm sorry, I don't understand what you think is the bug here. It looks like you are passing a corrupted file which has a PNG extension but is not actually a PNG file (it contains PHP code). What do you expect should happen?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26337>
_______________________________________

From report at bugs.python.org  Thu Feb 11 05:02:46 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 11 Feb 2016 10:02:46 +0000
Subject: [issue26328] shutil._copyxattr() function shouldn't fail if setting
 security.selinux xattr fails
In-Reply-To: <1455109424.72.0.659631056233.issue26328@psf.upfronthosting.co.za>
Message-ID: <1455184966.76.0.994348529914.issue26328@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26328>
_______________________________________

From report at bugs.python.org  Thu Feb 11 05:06:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 10:06:35 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455185195.6.0.867231863907.issue26331@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch implements strict underscore rules. The implementation is not more complex.

----------
Added file: http://bugs.python.org/file41893/numeric_underscores_strict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Thu Feb 11 05:21:20 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Thu, 11 Feb 2016 10:21:20 +0000
Subject: [issue26337] Bypass imghdr module determines the type of image
In-Reply-To: <1455170117.9.0.169068464747.issue26337@psf.upfronthosting.co.za>
Message-ID: <1455186080.45.0.240377839559.issue26337@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

images can be served with a content type of text/html,(which means we can certainly inject HTML).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26337>
_______________________________________

From report at bugs.python.org  Thu Feb 11 05:23:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 10:23:24 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
In-Reply-To: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>
Message-ID: <1455186204.06.0.255598275612.issue26312@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

SystemError is not new exception. It could be raised on other programming bugs. In any case I doesn't expect that anybody catches such exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26312>
_______________________________________

From report at bugs.python.org  Thu Feb 11 05:42:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 10:42:20 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
In-Reply-To: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>
Message-ID: <20160211104216.68420.32857@psf.io>


Roundup Robot added the comment:

New changeset c7eff18f3840 by Serhiy Storchaka in branch 'default':
Issue #26312: SystemError is now raised in all programming bugs with using
https://hg.python.org/cpython/rev/c7eff18f3840

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26312>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:11:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 11:11:03 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <20160211111100.60091.47687@psf.io>


Roundup Robot added the comment:

New changeset 935d7804d1be by Serhiy Storchaka in branch 'default':
Issue #25985: sys.version_info is now used instead of sys.version
https://hg.python.org/cpython/rev/935d7804d1be

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25985>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:12:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 11:12:45 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
In-Reply-To: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>
Message-ID: <20160211111243.2653.61534@psf.io>


Roundup Robot added the comment:

New changeset e9a4b30e3e43 by Serhiy Storchaka in branch '3.5':
Issue #26325: Added test.support.check_no_resource_warning() to check that
https://hg.python.org/cpython/rev/e9a4b30e3e43

New changeset faf676d8c054 by Serhiy Storchaka in branch 'default':
Issue #26325: Added test.support.check_no_resource_warning() to check that
https://hg.python.org/cpython/rev/faf676d8c054

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:21:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 11:21:54 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <20160211112149.68422.1478@psf.io>


Roundup Robot added the comment:

New changeset f98ed0616d07 by Serhiy Storchaka in branch 'default':
Issue #25994: Added the close() method and the support of the context manager
https://hg.python.org/cpython/rev/f98ed0616d07

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25994>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:28:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 11:28:33 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1455190113.08.0.304080747628.issue26200@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Raymond Hettinger: "Most of the SETREFs in the next() functions in the itertools module should also be restored to there former state.  They look to have been correct before the change, so there was no improvement, only degradation.  Much of that code had been finely tuned and battle tested over many years -- the addition of SETREFs was gratuitous."

I guess that your concern is performance. Did you notice a performance difference on a micro-benchmark? I don't think that it's possible to see any difference with the addition of a single if in C.

I disagree that the change is gratuitous: it was discussed at length and approved on python-dev and the issue #20440. The idea was not new, it was already proposed in issue #3081 (opened in 2008). The issue #20440 (Py_SETREF) is a generic fix of the bug #16447. PyPy dev found crazy bugs in CPython :-)

IMHO correctness matters more than performance here.

Oh, and by the way, I like a macro which avoids 3 lines of C code ;-) It makes the code shorter and more readable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26200>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:32:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 11:32:19 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <20160211113216.19989.72418@psf.io>


Roundup Robot added the comment:

New changeset e951d76f1945 by Serhiy Storchaka in branch '3.5':
Issue #25995: os.walk() no longer uses FDs proportional to the tree depth.
https://hg.python.org/cpython/rev/e951d76f1945

New changeset 6197a09a56b1 by Serhiy Storchaka in branch 'default':
Issue #25995: os.walk() no longer uses FDs proportional to the tree depth.
https://hg.python.org/cpython/rev/6197a09a56b1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25995>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:33:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 11:33:18 +0000
Subject: [issue26312] Raise SystemError on programmical errors in
 PyArg_Parse*()
In-Reply-To: <1454960373.85.0.989575322137.issue26312@psf.upfronthosting.co.za>
Message-ID: <1455190398.7.0.847108184474.issue26312@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks for your review.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26312>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:33:56 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Thu, 11 Feb 2016 11:33:56 +0000
Subject: [issue26337] Bypass imghdr module determines the type of image
In-Reply-To: <1455170117.9.0.169068464747.issue26337@psf.upfronthosting.co.za>
Message-ID: <1455190436.46.0.529552218389.issue26337@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

In normal if you choose a image and open image with editor set codes to image you get error , but I able to bypass image for upload if I use module imghdr for check valid image , booom upload image with malicious code ,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26337>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:34:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 11:34:09 +0000
Subject: [issue25985] Use sys.version_info instead of sys.version
In-Reply-To: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>
Message-ID: <1455190449.2.0.571806286298.issue25985@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25985>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:37:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 11:37:19 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
In-Reply-To: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>
Message-ID: <1455190639.92.0.703042281432.issue24916@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Most changes were committed in issue25985. Only _PY_VERSION is left. I have no strong opinion about this, but +0 for keeping "+".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24916>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:38:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 11:38:28 +0000
Subject: [issue26325] Add helper to check that no ResourceWarning is emitted
In-Reply-To: <1455099242.2.0.566872742177.issue26325@psf.upfronthosting.co.za>
Message-ID: <1455190708.9.0.152275275718.issue26325@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26325>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:40:14 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 11:40:14 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455190814.36.0.850487607584.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

This patch includes int(), float(), complex() operations, as well as _pydecimal.

----------
Added file: http://bugs.python.org/file41894/numeric_underscores_v3_full.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:41:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 11:41:09 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1455190869.26.0.493971933533.issue25994@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed with using the helper from issue26325 for testing.

Thank you all for your reviews, especially for help with the documentation.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25994>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:43:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 11:43:04 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <1455190984.8.0.73127983674.issue25995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

walk_consume_fds_opt1.patch is applied in 3.5 (it is more reliable with the absence of close()) and walk_consume_fds_opt2.patch is applied in 3.6.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25995>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:53:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 11:53:27 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1455190869.26.0.493971933533.issue25994@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ6cJfL=2WUxy9cZMLTxwaNeG8AYpJDgDf=Q79m0C4PdA@mail.gmail.com>


STINNER Victor added the comment:

> Committed with using the helper from issue26325 for testing.

Great! Good job.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25994>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:55:14 2016
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 11 Feb 2016 11:55:14 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1455191714.82.0.414127090173.issue26182@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I added the PyErr_WarnEx(PyExc_DeprecationWarning, ...) in Python/ast.c, right below the check for None, True and False as names. Running the following test the message is properly printed:

def test_async(self):
    with self.assertWarnsRegex(DeprecationWarning, "reserved keyword"):
        async = 33

However, the test does not pass, because the DeprecationWarning is not triggered. I am sorry but as a cpython beginner I can not figure out how to solve the problem, so I hope someone else can find the time to do it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26182>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:57:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 11:57:18 +0000
Subject: [issue25596] Use scandir() to speed up the glob module
In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za>
Message-ID: <1455191838.29.0.481994398126.issue25596@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch is completed now. The with statement is used to avoid FD leaks.

----------
Added file: http://bugs.python.org/file41895/glob_scandir_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25596>
_______________________________________

From report at bugs.python.org  Thu Feb 11 06:58:32 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 11 Feb 2016 11:58:32 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455191912.47.0.304511120412.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

So, shall we include it ? Otherwise, py8601 (https://bitbucket.org/micktwomey/pyiso8601/) looks pretty popular and well maintained (various committers, started in 2012, last commit in 2016).
I think we should hurry, that's a great shame it has been while Python is able to generate a 8601 datetime but not parsing it back.

----------
nosy: +deronnax

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 11 07:04:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 12:04:12 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455192252.0.0.642781206888.issue15873@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm working on the OpenStack project and iso8601 is heavily used.


> Otherwise, py8601 (https://bitbucket.org/micktwomey/pyiso8601/) looks pretty popular and well maintained (various committers, started in 2012, last commit in 2016).

I don't think that we should add the iso8601 module to the stdlib, but merge iso8601 "features" into the datetime module.

The iso8601 module supports Python 2.7 and so has to implement its own timezone classes. The datetime module now has datetime.timezone since Python 3.2 for fixed timezone.

The iso8601 module provides functions. I would prefer datetime.datetime *methods*.

Would you mind to try to implement that? It would be kind to contact iso8601 author before.

The important part is also unit tests.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 11 07:25:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 12:25:19 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1455193519.25.0.132541521943.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Py_SETREF() is used not only for fixing possible bugs. It can make the correct code shorter and cleaner. For example Stephan appreciated this in df78978dacab. In most case the difference between Py_DECREF and Py_XDECREF looks negligible.

Most of the SETREFs in the next() functions in the itertools module replace Py_CLEAR and therefore don't add additional overhead (but may fix possible bugs). The only Py_DECREF were replaced in tee_next() and accumulate_next(). But they are used not in tight loop. Py_SETREF in tee_next() is executed only for every 57th call. It unlikely causes any measurable degradation. Py_SETREF in accumulate_next() is used together with calling PyIter_Next and PyNumber_Add() or PyObject_CallFunctionObjArgs() which takes much more time.

In any case it would be nice to see any measurements that show a degradation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26200>
_______________________________________

From report at bugs.python.org  Thu Feb 11 07:41:53 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 12:41:53 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455194513.08.0.168055113663.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

New patch with minimal doc updates.

----------
Added file: http://bugs.python.org/file41896/numeric_underscores_v4_full.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Thu Feb 11 08:12:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 13:12:29 +0000
Subject: [issue25264] test_marshal always crashs on "AMD64 Windows10 2.7"
 buildbot
In-Reply-To: <1443513708.82.0.964856310612.issue25264@psf.upfronthosting.co.za>
Message-ID: <1455196349.91.0.103184450807.issue25264@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25264>
_______________________________________

From report at bugs.python.org  Thu Feb 11 08:17:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 13:17:12 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1455196632.54.0.903885449744.issue25911@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

New tests emit deprecation warnings on Windows and failed.

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/1753/steps/test/logs/stdio
test_rmdir_on_directory_link_to_missing_target (test.test_os.Win32SymlinkTests) ... D:\buildarea\3.x.bolen-windows8\build\lib\os.py:447: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  for name in listdir(dir):
D:\buildarea\3.x.bolen-windows8\build\lib\os.py:441: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  return path.isdir(self.path)
D:\buildarea\3.x.bolen-windows8\build\lib\ntpath.py:249: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  st = os.lstat(path)
D:\buildarea\3.x.bolen-windows8\build\lib\test\test_os.py:2688: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  func(name, *func_args)
D:\buildarea\3.x.bolen-windows8\build\lib\unittest\case.py:176: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  callable_obj(*args, **kwargs)
D:\buildarea\3.x.bolen-windows8\build\lib\test\test_os.py:1881: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  sorted(os.listdir(path)),
D:\buildarea\3.x.bolen-windows8\build\lib\test\test_os.py:1867: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  sorted(os.listdir(os.fsencode(support.TESTFN))),
test test_os failed
skipped 'currently fails; consider for improvement'

======================================================================
FAIL: test_walk_bottom_up (test.test_os.BytesWalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_os.py", line 894, in test_walk_bottom_up
    self.sub2_tree)
AssertionError: Tuples differ: ('@test_4312_tmp\\TEST1\\SUB2', ['broken_link', 'link'], ['tmp3']) != ('@test_4312_tmp\\TEST1\\SUB2', ['link'], ['broken_link', 'tmp3'])

First differing element 1:
['broken_link', 'link']
['link']

- ('@test_4312_tmp\\TEST1\\SUB2', ['broken_link', 'link'], ['tmp3'])
?                                                 ----------

+ ('@test_4312_tmp\\TEST1\\SUB2', ['link'], ['broken_link', 'tmp3'])
?                                 ++++++++++


======================================================================
FAIL: test_walk_prune (test.test_os.BytesWalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_os.py", line 874, in test_walk_prune
    self.assertEqual(all[1], self.sub2_tree)
AssertionError: Tuples differ: ('@test_4312_tmp\\TEST1\\SUB2', ['broken_link', 'link'], ['tmp3']) != ('@test_4312_tmp\\TEST1\\SUB2', ['link'], ['broken_link', 'tmp3'])

First differing element 1:
['broken_link', 'link']
['link']

- ('@test_4312_tmp\\TEST1\\SUB2', ['broken_link', 'link'], ['tmp3'])
?                                                 ----------

+ ('@test_4312_tmp\\TEST1\\SUB2', ['link'], ['broken_link', 'tmp3'])
?                                 ++++++++++

Proposed patch should silence warnings. Could anyone please test it on Windows?

----------
status: closed -> open
Added file: http://bugs.python.org/file41897/test_walk_bytes_deprecate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25911>
_______________________________________

From report at bugs.python.org  Thu Feb 11 08:17:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 13:17:24 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1455196644.96.0.966836296951.issue25911@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution: fixed -> 
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25911>
_______________________________________

From report at bugs.python.org  Thu Feb 11 09:01:45 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 11 Feb 2016 14:01:45 +0000
Subject: [issue26214] textwrap should minimize number of breaks in extra long
 words
In-Reply-To: <1453882121.55.0.184610339904.issue26214@psf.upfronthosting.co.za>
Message-ID: <1455199305.39.0.288077645104.issue26214@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26214>
_______________________________________

From report at bugs.python.org  Thu Feb 11 09:22:55 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 11 Feb 2016 14:22:55 +0000
Subject: [issue26002] make statistics.median_grouped more efficient
In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>
Message-ID: <1455200575.34.0.672940705981.issue26002@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Looks good to me.

I've run some quick timing tests, and for very small lists, there's no significant difference, but for larger lists I'm getting up to a 50% speedup. Nicely done, thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26002>
_______________________________________

From report at bugs.python.org  Thu Feb 11 09:30:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 14:30:05 +0000
Subject: [issue19543] Add -3 warnings for codec convenience method changes
In-Reply-To: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za>
Message-ID: <1455201005.43.0.964673800911.issue19543@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is there something left to do with this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19543>
_______________________________________

From report at bugs.python.org  Thu Feb 11 09:33:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 14:33:13 +0000
Subject: [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1455201193.51.0.762969977724.issue15068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15068>
_______________________________________

From report at bugs.python.org  Thu Feb 11 09:34:22 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 11 Feb 2016 14:34:22 +0000
Subject: [issue26086] Bug in os module
In-Reply-To: <1452548126.01.0.956593686661.issue26086@psf.upfronthosting.co.za>
Message-ID: <1455201262.12.0.616871813626.issue26086@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I don't see any conclusive evidence that this is a bug in the Python interpreter, so I'm going to close the issue.

Hana, if you are still having this problem, please join the main python mailing list https://mail.python.org/mailman/listinfo/python-list or newsgroup comp.lang.python, and we should be able to help you there. (But please don't post screen shots, copy and paste the text of the exception into your message.)

----------
nosy: +steven.daprano
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26086>
_______________________________________

From report at bugs.python.org  Thu Feb 11 09:37:34 2016
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Thu, 11 Feb 2016 14:37:34 +0000
Subject: [issue26338] remove duplicate bind addresses in create_server
Message-ID: <1455201454.94.0.572810493705.issue26338@psf.upfronthosting.co.za>


New submission from Sebastien Bourdeauducq:

https://github.com/python/asyncio/issues/315

New patch attached.

----------
components: asyncio
files: asyncio_norebind.diff
keywords: patch
messages: 260108
nosy: gvanrossum, haypo, sebastien.bourdeauducq, yselivanov
priority: normal
severity: normal
status: open
title: remove duplicate bind addresses in create_server
versions: Python 3.5
Added file: http://bugs.python.org/file41898/asyncio_norebind.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26338>
_______________________________________

From report at bugs.python.org  Thu Feb 11 10:02:01 2016
From: report at bugs.python.org (sherpa)
Date: Thu, 11 Feb 2016 15:02:01 +0000
Subject: [issue26339] Python rk0.3b1 KeyError: 'config_argparse_rel_path'
Message-ID: <1455202921.22.0.411034223357.issue26339@psf.upfronthosting.co.za>


New submission from sherpa:

Hi,
we use python 2.7.3 on Linux SuSe Enterprise 11 x86 64 bits.
After installing the python module rk0.3b1, we have this error when rk parse the configuration file: KeyError: 'config_argparse_rel_path' after this function dict.__getitem__(self, key)

You will find below the debugger trace:

# python -m pdb /opt/python-2.7.3/bin/rk

> /opt/python-2.7.3/bin/rk(3)<module>()

-> __requires__ = 'rk==0.3b1'

(Pdb) cont

Traceback (most recent call last):

  File "/opt/python-2.7.3/lib/python2.7/pdb.py", line 1314, in main

    pdb._runscript(mainpyfile)

  File "/opt/python-2.7.3/lib/python2.7/pdb.py", line 1233, in _runscript

    self.run(statement)

  File "/opt/python-2.7.3/lib/python2.7/bdb.py", line 387, in run

    exec cmd in globals, locals

  File "<string>", line 1, in <module>

  File "/opt/python-2.7.3/bin/rk", line 3, in <module>

    __requires__ = 'rk==0.3b1'

  File "build/bdist.linux-x86_64/egg/rk/rk.py", line 253, in main

    create_dictionaries()

  File "build/bdist.linux-x86_64/egg/rk/rk.py", line 25, in create_dictionaries

    config_argparse_rel_path = config["config_argparse_rel_path"]

  File "/opt/python-2.7.3/lib/python2.7/site-packages/configobj.py", line 554, in __getitem__

    val = dict.__getitem__(self, key)

KeyError: 'config_argparse_rel_path'

Uncaught exception. Entering post mortem debugging

Running 'cont' or 'step' will restart the program

> /opt/python-2.7.3/lib/python2.7/site-packages/configobj.py(554)__getitem__()

-> val = dict.__getitem__(self, key)

(Pdb)

----------
components: Installation
files: pdb_rk0.3b1.txt
messages: 260109
nosy: sherpa
priority: normal
severity: normal
status: open
title: Python rk0.3b1 KeyError: 'config_argparse_rel_path'
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41899/pdb_rk0.3b1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26339>
_______________________________________

From report at bugs.python.org  Thu Feb 11 10:27:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 15:27:00 +0000
Subject: [issue26315] Optimize mod division for ints
In-Reply-To: <1454970675.84.0.301967594836.issue26315@psf.upfronthosting.co.za>
Message-ID: <20160211152630.1541.18219@psf.io>


Roundup Robot added the comment:

New changeset 37bacf3fa1f5 by Yury Selivanov in branch 'default':
Issues #26289 and #26315: Optimize floor/modulo div for single-digit longs
https://hg.python.org/cpython/rev/37bacf3fa1f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26315>
_______________________________________

From report at bugs.python.org  Thu Feb 11 10:27:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 15:27:00 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <20160211152630.1541.73722@psf.io>


Roundup Robot added the comment:

New changeset 37bacf3fa1f5 by Yury Selivanov in branch 'default':
Issues #26289 and #26315: Optimize floor/modulo div for single-digit longs
https://hg.python.org/cpython/rev/37bacf3fa1f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26289>
_______________________________________

From report at bugs.python.org  Thu Feb 11 10:27:35 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 15:27:35 +0000
Subject: [issue26315] Optimize mod division for ints
In-Reply-To: <1454970675.84.0.301967594836.issue26315@psf.upfronthosting.co.za>
Message-ID: <1455204455.65.0.0692451603089.issue26315@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26315>
_______________________________________

From report at bugs.python.org  Thu Feb 11 10:29:32 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 15:29:32 +0000
Subject: [issue26289] Optimize floor division for ints
In-Reply-To: <1454638074.35.0.0871962001647.issue26289@psf.upfronthosting.co.za>
Message-ID: <1455204572.22.0.585780933942.issue26289@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Committed.  Thank you Serhiy, Mark and Victor for helping with the patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26289>
_______________________________________

From report at bugs.python.org  Thu Feb 11 11:05:05 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Feb 2016 16:05:05 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1455206705.88.0.63317003714.issue26317@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The makefiles use CC throughout and don't look at and OBJC variable. Is that variable a standard way to specify an ObjC compiler in makefiles? 

Make's default ruleset for compiling .m files uses $(CC) and doesn't look at $(OBJC).

I wouldn't be opposed to a patch that makes it possible to specify an ObjC compiler, could you write such a patch?  BTW. The patch should also update the autoconf script (use AC_PROG_OBJC).

----------
components: +Macintosh
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:04:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 17:04:14 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <1455210254.31.0.426134370801.issue25709@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: serhiy.storchaka -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:05:42 2016
From: report at bugs.python.org (vs)
Date: Thu, 11 Feb 2016 17:05:42 +0000
Subject: [issue26340] modal dialog with transient method;
 parent window fails to iconify
Message-ID: <1455210342.9.0.230352859774.issue26340@psf.upfronthosting.co.za>


New submission from vs:

Consider the following code implementing a custom modal dialog:

from Tkinter import *

def dialog():
    win = Toplevel()
    Label(win, text='Modal Dialog').pack()
    win.transient(win.master)
    win.focus_set()
    win.grab_set()
    win.wait_window()

root = Tk()
Button(root, text='Custom Dialog', command=dialog).pack()
root.mainloop()

In Python 2.7.3, the parent window behaves as expected when the modal dialog is active. That is, the parent window responds to minimize, maximize, and close events. The modal dialog window iconifies and closes together with the parent window. If a user presses Show Desktop button in Windows OS, the parent and the dialog iconify together and can be restored from the Taskbar.

However, in more recent Python releases (I tested 2.7.8, 2.7.11 and 3.5.1), the parent window does not respond to any of the three window commands. If the modal dialog is open and the user presses Show Desktop, both windows iconify, but they CANNOT be restored or closed from the Taskbar. The only way to close such an application is to kill it through the Task Manager.

----------
components: Tkinter, Windows
messages: 260114
nosy: paul.moore, steve.dower, tim.golden, vs, zach.ware
priority: normal
severity: normal
status: open
title: modal dialog with transient method; parent window fails to iconify
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26340>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:23:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Feb 2016 17:23:36 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <20160211172332.15937.57248@psf.io>


Roundup Robot added the comment:

New changeset b9c8f1c80f47 by Serhiy Storchaka in branch '3.3':
Issue #25709: Fixed problem with in-place string concatenation and utf-8 cache.
https://hg.python.org/cpython/rev/b9c8f1c80f47

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:23:56 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 17:23:56 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <1455211436.39.0.15894696756.issue25709@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Backpicked to 3.3. Sorry for the wait.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:24:46 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 17:24:46 +0000
Subject: [issue24668] Deprecate 00000 as a synonym for 0
In-Reply-To: <1437303517.79.0.631832090122.issue24668@psf.upfronthosting.co.za>
Message-ID: <1455211486.14.0.122689133943.issue24668@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Closing now.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24668>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:25:39 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 17:25:39 +0000
Subject: [issue15693] expose glossary link on hover
In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za>
Message-ID: <1455211539.28.0.319404701099.issue15693@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15693>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:25:45 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 17:25:45 +0000
Subject: [issue4173] PDF documentation: long verbatim lines are cut off at
 right hand side
In-Reply-To: <1224684717.3.0.110027961744.issue4173@psf.upfronthosting.co.za>
Message-ID: <1455211545.87.0.609878043826.issue4173@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4173>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:25:52 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 17:25:52 +0000
Subject: [issue4145] tabulary entries in PDF documentation
In-Reply-To: <1224406019.73.0.627994354189.issue4145@psf.upfronthosting.co.za>
Message-ID: <1455211552.42.0.904088940055.issue4145@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4145>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:26:15 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 17:26:15 +0000
Subject: [issue20741] Documentation archives should be available also in
 tar.xz format
In-Reply-To: <1393142720.31.0.255845110134.issue20741@psf.upfronthosting.co.za>
Message-ID: <1455211575.37.0.380156007497.issue20741@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20741>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:37:12 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 11 Feb 2016 17:37:12 +0000
Subject: [issue20741] Documentation archives should be available also in
 tar.xz format
In-Reply-To: <1393142720.31.0.255845110134.issue20741@psf.upfronthosting.co.za>
Message-ID: <1455212232.58.0.230682698537.issue20741@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20741>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:50:07 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Feb 2016 17:50:07 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455213007.8.0.297446375214.issue26331@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Thu Feb 11 12:54:30 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Feb 2016 17:54:30 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1455213270.54.0.111398397068.issue26182@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You need to temporarily turn on warnings for it to work. For example:

  with warnings.catch_warnings():
      warnings.simplefilter('always')
      with self.assertWarnsRegex(DeprecationWarning, "reserved keyword"):
        exec('async = 33')

Do notice I used exec() as otherwise the warning will be triggered at import instead of when the test runs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26182>
_______________________________________

From report at bugs.python.org  Thu Feb 11 13:00:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 18:00:22 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1455213622.63.0.542169770131.issue26182@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26182>
_______________________________________

From report at bugs.python.org  Thu Feb 11 13:00:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 18:00:32 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1455211436.39.0.15894696756.issue25709@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa5b8BaJUjW7XHRXBHYgs_a_z=PsCf8era0p1adXpkB7g@mail.gmail.com>


STINNER Victor added the comment:

2016-02-11 18:23 GMT+01:00 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl added the comment:
>
> Backpicked to 3.3. Sorry for the wait.

Good, this bugfix is useful :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Thu Feb 11 13:21:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 18:21:32 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <1455214892.1.0.0766993012326.issue25709@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I wait only Greg's approving for 3.3. If I'll not get it in a day, I'll commit the patch for 3.4+.

Maybe it was my fault. I made a mistake in Georg's name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Thu Feb 11 13:24:32 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Feb 2016 18:24:32 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <1455215072.43.0.292644926393.issue25709@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Actually I prefer Greg to Gerg, so it's only half bad. :D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Thu Feb 11 13:48:57 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 11 Feb 2016 18:48:57 +0000
Subject: [issue18199] Windows: support path longer than 260 bytes using "\\?\"
 prefix
In-Reply-To: <1371050681.12.0.381093438517.issue18199@psf.upfronthosting.co.za>
Message-ID: <1455216537.57.0.0253650974626.issue18199@psf.upfronthosting.co.za>


Steve Dower added the comment:

Paths prefixed with "\\?\" also need to be normalized, not just absolute. AFAIK there are no official docs on what normalization is required, but it includes at least trimming trailing dots on directory names, removing "." and ".." sections, adjacent backslashes, and removing trailing spaces on any segment.

Without this, you will access/create/etc. files that users cannot otherwise see or modify.

I don't disagree that we should add the prefix for long paths, but we need to at least get most of the normalization correct so that cases like this work:

>>> open('C:\\Dir \\file.txt.', 'r').read()
"Content"
>>> open('\\\\?\\C:\\Dir \\file.txt.', 'r').read()
FileNotFoundError: [Errno 2] No such file or directory: '\\\\?\\C:\\Dir \\file.txt.'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18199>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:15:07 2016
From: report at bugs.python.org (Mike Taylor)
Date: Thu, 11 Feb 2016 19:15:07 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1455218107.71.0.46277786004.issue24712@psf.upfronthosting.co.za>


Mike Taylor added the comment:

Great, thanks Ezio! Will take a stab now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24712>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:22:36 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 19:22:36 +0000
Subject: [issue26341] Implement free-list for single-digit longs
Message-ID: <1455218556.74.0.414585930827.issue26341@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The attached patch implements a free-list for single-digit longs.  We already have free lists for many fundamental types, such as floats & unicode.

The patch improves performance in micro-benchmarks by 10-20%.  It'll also lessen memory fragmentation issues.


== Benchmarks ==

### spectral_norm ###
Min: 0.268018 -> 0.245042: 1.09x faster
Avg: 0.289548 -> 0.257861: 1.12x faster
Significant (t=18.82)
Stddev: 0.01004 -> 0.00640: 1.5680x smaller

-m timeit -s "loops=tuple(range(1000))" "for x in loops: x+x"
with patch: 34.5 usec           without patch: 45.9 usec


== Why only single-digit? ==

I've also a patch that implements free-lists for 1-digit, 2-digits and 3-digits longs, and collects statistics on them.  It looks like we only want to optimize 1-digit longs:

* 2to3 benchmark (the first number is the number of all N-digit longs, the second number is the number of longs created via free-list):

===> d1_longs = 142384 124759
===> d2_longs = 6872 6264
===> d3_longs = 2907 2834

* richards:
===> d1_longs = 219630 219033
===> d2_longs = 1455 1096
===> d3_longs = 630 627

* spectral_norm:
===> d1_longs = 133928432 133927838
===> d2_longs = 1471 1113
===> d3_longs = 630 627

----------
assignee: yselivanov
components: Interpreter Core
files: long_fl.patch
keywords: patch
messages: 260124
nosy: haypo, mark.dickinson, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Implement free-list for single-digit longs
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41900/long_fl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26341>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:32:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 19:32:03 +0000
Subject: [issue26341] Implement free-list for single-digit longs
In-Reply-To: <1455218556.74.0.414585930827.issue26341@psf.upfronthosting.co.za>
Message-ID: <1455219123.89.0.878254180205.issue26341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as a duplicate of issue24165.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26341>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:33:58 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 19:33:58 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
Message-ID: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This patch implements a fast path for &, |, and ^ bit operations for single-digit positive longs.  We already have fast paths for ~, and pretty much every other long op.


-m timeit -s "x=21827623" "x&2;x&2;x&2;x&333;x&3;x&3;x&4444;x&4"
with patch: 0.181          without patch: 0.403


-m timeit -s "x=21827623" "x|21222;x|23;x|2;x|333;x|3;x|3;x|4444;x|4"
with patch: 0.241          without patch: 0.342


-m timeit -s "x=21827623" "x^21222;x^23;x^2;x^333;x^3;x^3;x^4444;x^4"
with patch: 0.241          without patch: 0.332

----------
assignee: yselivanov
components: Interpreter Core
files: fast_bits.patch
keywords: patch
messages: 260126
nosy: haypo, mark.dickinson, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Faster bit ops for single-digit positive longs
type: performance
Added file: http://bugs.python.org/file41901/fast_bits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:37:31 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 19:37:31 +0000
Subject: [issue26341] Implement free-list for single-digit longs
In-Reply-To: <1455218556.74.0.414585930827.issue26341@psf.upfronthosting.co.za>
Message-ID: <1455219451.15.0.248825596422.issue26341@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

You're right Serhiy, closing this one.

----------
resolution:  -> duplicate
superseder:  -> Free list for single-digits ints

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26341>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:38:16 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 19:38:16 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455219496.95.0.377543051855.issue24165@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I think that we only need to add free-list for 1-digit longs.  Please see my patch & explanation in issue #26341.

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:57:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 19:57:32 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455220652.04.0.256528928701.issue24165@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Did you test on platform with 30-bit digits? I tested with 15-bit digits.

Could you repeat my microbenchmarks from msg242919?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:57:51 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 11 Feb 2016 19:57:51 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455220671.71.0.223026117805.issue24165@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 14:59:31 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 19:59:31 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455220771.79.0.9590342192.issue24165@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Did you test on platform with 30-bit digits?

Yes.

> Could you repeat my microbenchmarks from msg242919?

Sure. With your patches or with mine from issue #26341?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 15:09:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Feb 2016 20:09:28 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455221368.36.0.810020986722.issue24165@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With all three patches if you want (I don't expect a difference between your patch and my single-digit patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 15:09:40 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 20:09:40 +0000
Subject: [issue26341] Implement free-list for single-digit longs
In-Reply-To: <1455218556.74.0.414585930827.issue26341@psf.upfronthosting.co.za>
Message-ID: <1455221380.58.0.705200531406.issue26341@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26341>
_______________________________________

From report at bugs.python.org  Thu Feb 11 15:58:10 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Feb 2016 20:58:10 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1455224290.01.0.176713468838.issue26200@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It may just be me, but I find the code the be less readable.  The presence of the SETREFs in the itertools modules makes it harder for me to count and track all the references to make sure the code is correct.  For me, it is an obstacle to maintenance.

The itertools code was carefully thought-out, reviewed, clear (at least to its creator and maintainer), and finely tuned.   It has been stable for a very long time and I don't think it should have been changed.

The module was designed for high-performance and I'm opposed to adding unnecessary work.  As you know, these kind of things are very difficult to run timings on, but it is clear to both of us that the wholesale replacement of Py_DECREF with Py_XDECREF adds unnecessary load to the Branch Target Buffer and to the I-cache.  In general, unnecessary work is always a step in the wrong direction, particularly in a module designed for performance.

Another occasional issue with the SETREF macro is that gets it the way of trying to defer all decrefs until as late as possible in a function call.  The LRU cache is a example of a place where we want to bring the whole data structure into a coherent state prior to any of the decrefs (I even have to do that in the pure python lru cache code to guard against premature re-entrancy).

As the creator and principal maintainer of itertools, I'm stating a very strong preference to restore the code in the next() methods.

Please don't make this hard for me (When one of the most experienced of the active developers states a strong code preference and gives the reasons for it, there shouldn't have to be struggle to get it done).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26200>
_______________________________________

From report at bugs.python.org  Thu Feb 11 16:29:37 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 21:29:37 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455226177.1.0.364289280217.issue24165@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Best of 5s:

-m timeit -s "r = range(10**4)" -- "for i in r: pass"
orig: 239 usec
my patch: 148
int_free_list_2: 151
int_free_list_multi: 156


-m timeit -s "r = range(10**5)" -- "for i in r: pass"
orig: 2.4 msec
my patch: 1.47
int_free_list_2: 1.53
int_free_list_multi: 1.57


-m timeit -s "a = list(range(10**4))" -- "for i, x in enumerate(a): pass"
orig: 416 usec
my: 314
int_free_list_2: 314
int_free_list_multi: 317


-m timeit -s "a = list(range(10**5))" -- "for i, x in enumerate(a): pass"
orig: 4.1 msec
my: 3.13
int_free_list_2: 3.14
int_free_list_multi: 3.13


-m timeit -s "from base64 import b85encode; a = bytes(range(256))*100" -- "b85encode(a)"
orig: 3.49 msec
my: 3.28
int_free_list_2: 3.30
int_free_list_multi: 3.31


-m timeit -s "loops=tuple(range(1000))" "for x in loops: x+x"
orig: 44.4 usec
my: 35.2
int_free_list_2: 35.4
int_free_list_multi: 35.5


spectral_norm (against default):
my: 1.12x faster
int_free_list_2: 1.12x faster
int_free_list_multi: 1.12x faster


==========

All in all, all patches show the same performance improvement.  I guess we can go with int_free_list_multi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 16:29:48 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 11 Feb 2016 21:29:48 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1455226188.89.0.805131548139.issue26200@psf.upfronthosting.co.za>


Stefan Krah added the comment:

As Serhiy mentioned, I'm really happy with the Py_SETREF() macro and I understand the reasons why it was applied so broadly.

But if a module maintainer prefers not to change existing (and
correct) code, then that should have priority (also, the existing
version was quite readable).

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26200>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:10:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 22:10:13 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1455228613.67.0.541303742159.issue26200@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26200>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:11:23 2016
From: report at bugs.python.org (Gustavo Goretkin)
Date: Thu, 11 Feb 2016 22:11:23 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
Message-ID: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>


New submission from Gustavo Goretkin:

I am on OS X 10.9.5

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.O_CLOEXEC
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'os' has no attribute 'O_CLOEXEC'

I checked on my system
$ man 2 open | grep CLOEXEC
           O_CLOEXEC       mark as close-on-exec
     The O_CLOEXEC flag causes the file descriptor to be marked as close-on-
     exec, setting the FD_CLOEXEC flag.  The state of the file descriptor

I first noticed this on an anaconda distribution of python, but it looks like it is also present on the 3.5 .dmg file on https://www.python.org/downloads/

----------
components: Macintosh
messages: 260135
nosy: Gustavo Goretkin, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: os.O_CLOEXEC not available on OS X
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:17:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 22:17:09 +0000
Subject: [issue26292] Raw I/O writelines() broken for non-blocking I/O
In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za>
Message-ID: <1455229029.49.0.241124243744.issue26292@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Raw I/O writelines() broken -> Raw I/O writelines() broken for non-blocking I/O

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26292>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:21:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 22:21:54 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
In-Reply-To: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>
Message-ID: <1455229314.92.0.662170435579.issue26342@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fast_bits.patch LGTM. But it would be better to have at least two reviews.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:32:49 2016
From: report at bugs.python.org (Gustavo Goretkin)
Date: Thu, 11 Feb 2016 22:32:49 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>
Message-ID: <1455229969.04.0.594716198456.issue26343@psf.upfronthosting.co.za>


Gustavo Goretkin added the comment:

It looks like cpython will check to see if O_CLOEXEC is #defined. 

In my system's /usr/include/sys/fcntl.h

#if __DARWIN_C_LEVEL >= 200809L
#define O_CLOEXEC       0x1000000       /* implicitly set FD_CLOEXEC */
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:39:43 2016
From: report at bugs.python.org (Wolfgang Richter)
Date: Thu, 11 Feb 2016 22:39:43 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
Message-ID: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>


New submission from Wolfgang Richter:

My understanding of `sys.meta_path` is that it is supposed to allow customized loading of Python modules and packages.

In fact the `importlib` machinery appears to have support for identifying packages with `__init__` files with non-standard suffixes:

https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap_external.py#L645

https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap_external.py#L1233

However, I find that when I `import wolftest` inside a folder with structure:

./
    /wolftest
        /__init__.wolf
        /something.wolf

None of my sys.meta_path finders are called at all, and instead a namespace is returned.

I was wondering why the `import` statement appears to short-circuit and not check with `sys.meta_path` handlers in this case?

----------
components: Library (Lib)
files: PyMetaPath.tar.gz
messages: 260138
nosy: Wolfgang Richter
priority: normal
severity: normal
status: open
title: `sys.meta_path` Skipped for Packages with Non-Standard Suffixed `__init__` Files
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41902/PyMetaPath.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:41:25 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 11 Feb 2016 22:41:25 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455230485.69.0.66872870016.issue26344@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +brett.cannon, eric.smith, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:43:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 22:43:52 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>
Message-ID: <1455230632.05.0.93880022726.issue26343@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI Python creates non-inheritable file descriptors by default since Python 3.4: PEP 446.

See also the PEP 433 which has more information on OS support, especially:
https://www.python.org/dev/peps/pep-0433/#atomic-flags

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:44:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 22:44:24 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>
Message-ID: <1455230664.53.0.403209159296.issue26343@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is __DARWIN_C_LEVEL? Are we supposed to define it directly? Or is it defined from other #define in features.h?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Thu Feb 11 17:50:54 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Feb 2016 22:50:54 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455230664.53.0.403209159296.issue26343@psf.upfronthosting.co.za>
Message-ID: <F52353FF-9DA5-48C0-9BA8-10970FE94A40@mac.com>


Ronald Oussoren added the comment:

The lack of o_cloexec could be caused by the SDK used to build the binary installer. AFAIK _DARWIN_C_LEVEL is set automatically based on the deployment target. 

Ronald

Sent from my iPad

> On 11 feb. 2016, at 23:44, STINNER Victor <report at bugs.python.org> wrote:
> 
> 
> STINNER Victor added the comment:
> 
> What is __DARWIN_C_LEVEL? Are we supposed to define it directly? Or is it defined from other #define in features.h?
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26343>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:01:22 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Feb 2016 23:01:22 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455231682.98.0.972495621775.issue26344@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm at work and so I don't have access to tar on this machine ATM, so I can't look at your code example. But sys.meta_path might be one level above what you want; you might be looking for sys.path_hooks since https://docs.python.org/3/library/importlib.html#importlib.machinery.PathFinder is what searches entries on sys.path. This also means that if you don't put your finder on sys.meta_path before importlib.machinery.PathFinder then it will never pick up a directory since any directory will always be viewed as a namespace package by that meta path finder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:07:53 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 11 Feb 2016 23:07:53 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455232073.56.0.0547308997321.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Please take a look at the attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file41903/issue26323.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:11:08 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 11 Feb 2016 23:11:08 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455232268.04.0.734515291858.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Fixed the test name

----------
Added file: http://bugs.python.org/file41904/issue26323.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:17:41 2016
From: report at bugs.python.org (Wolfgang Richter)
Date: Thu, 11 Feb 2016 23:17:41 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455232661.84.0.654905723763.issue26344@psf.upfronthosting.co.za>


Wolfgang Richter added the comment:

Brett thanks for the very quick response.

I've inserted my finder as the first element in sys.meta_path.

I also overrode the @classmethod find_loader, but it doesn't appear that it's being called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:26:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Feb 2016 23:26:07 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455233167.99.0.441638625661.issue26344@psf.upfronthosting.co.za>


Brett Cannon added the comment:

As I said, I can't look at your code unless you upload the file separately so I don't know how much help I can be. Did you check sys.modules to make sure the directory had not already been imported or sys.path_importer_cache to make sure the directory didn't already have a finder associated with it? I know sys.meta_path isn't bypassed as that's how the builtin and frozen importer work.

And have you tried this in a newer version of Python? 3.4 is no longer receiving bugfixes so even if there is a problem there it won't be changed. And you should try and use https://docs.python.org/3/library/importlib.html#importlib.util.find_spec instead of find_loader().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:43:40 2016
From: report at bugs.python.org (Wolfgang Richter)
Date: Thu, 11 Feb 2016 23:43:40 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455234220.98.0.511744974766.issue26344@psf.upfronthosting.co.za>


Wolfgang Richter added the comment:

Sure Brett I'll upload the code separately in an hour or two.

I've overridden all the publicly exposed functions (including find_spec).

I wanted to initially see if anything was passing through my finder in the first position of the meta_path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:48:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Feb 2016 23:48:25 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455234505.97.0.580196705365.issue24165@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I ran perf.py on long_fl.patch of issue #26341. It looks slower and has no impact on such macro benchmark.

~/bin/taskset_isolated.py time python3 -u perf.py --rigorous ../default/python.orig ../default/python_long_fl

# python rev 37bacf3fa1f5

Report on Linux smithers 4.3.4-300.fc23.x86_64 #1 SMP Mon Jan 25 13:39:23 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### chameleon_v2 ###
Min: 5.660445 -> 5.809548: 1.03x slower
Avg: 5.707313 -> 5.851431: 1.03x slower
Significant (t=-31.76)
Stddev: 0.03655 -> 0.02690: 1.3585x smaller

### json_dump_v2 ###
Min: 2.745682 -> 2.819627: 1.03x slower
Avg: 2.769530 -> 2.838116: 1.02x slower
Significant (t=-42.78)
Stddev: 0.01019 -> 0.01238: 1.2147x larger

### regex_v8 ###
Min: 0.041680 -> 0.041081: 1.01x faster
Avg: 0.042383 -> 0.041265: 1.03x faster
Significant (t=6.49)
Stddev: 0.00122 -> 0.00121: 1.0077x smaller

The following not significant results are hidden, use -v to show them:
2to3, django_v3, fastpickle, fastunpickle, json_load, nbody, tornado_http.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 18:58:44 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 11 Feb 2016 23:58:44 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455235124.64.0.851593670412.issue24165@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I also ran benchmarks.  For me, django was 1% faster, telco 5% slower, and the rest were the same.  telco is a decimal benchmarks (ints aren't used there), and django/chameleon are unicode concatenation benchmarks.

I can see improvements in micro benchmarks, but even more importantly, Serhiy's patch reduces memory fragmentations.  99% of all long allocations are coming from freelist when it's there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Feb 11 19:46:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Feb 2016 00:46:44 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455238004.88.0.376165469251.issue15873@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also #12006 for ISO 8601: "The datetime.strftime() and date.strftime() methods now support ISO 8601 date directives %G, %u and %V. (Contributed by Ashley Anderson in issue 12006.)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 11 19:47:52 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2016 00:47:52 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>
Message-ID: <1455238072.44.0.348433365419.issue26343@psf.upfronthosting.co.za>


Ned Deily added the comment:

Ronald is correct.  Apple added O_CLOEXEC to OS X in 10.7.  For compatibility reasons, the python.org 64-bit installers for OS X currently are built to be compatible with OS X 10.6 on up and do not do runtime checks for OS features only available on newer releases.  If you need O_CLOEXEC support, you could use a Python from another distributor, such as Homebrew or MacPorts, or you could build it from source yourself.


https://developer.apple.com/library/mac/releasenotes/General/MacOSXLionAPIDiffs/Kernel.html

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Thu Feb 11 19:51:08 2016
From: report at bugs.python.org (Wolfgang Richter)
Date: Fri, 12 Feb 2016 00:51:08 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455238268.46.0.897684983093.issue26344@psf.upfronthosting.co.za>


Wolfgang Richter added the comment:

Here's the file, before I experimented with find_loader.

If you take out all my print's, it's quite short.

----------
Added file: http://bugs.python.org/file41905/main.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 19:52:54 2016
From: report at bugs.python.org (Wolfgang Richter)
Date: Fri, 12 Feb 2016 00:52:54 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455238374.73.0.0289748369433.issue26344@psf.upfronthosting.co.za>


Changes by Wolfgang Richter <wolfgang.richter at gmail.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 20:06:05 2016
From: report at bugs.python.org (Egor Tensin)
Date: Fri, 12 Feb 2016 01:06:05 +0000
Subject: [issue26345] Extra newline appended to UTF-8 strings on Windows
Message-ID: <1455239165.25.0.227087852631.issue26345@psf.upfronthosting.co.za>


New submission from Egor Tensin:

I've come across an issue of Python 3.5.1 appending an extra newline when print()ing non-ASCII strings on Windows.

This only happens when the active "code page" is set UTF-8 in cmd.exe:

    >chcp
    Active code page: 65001

Now, if I try to print an ASCII character (e.g. LATIN CAPITAL LETTER A), everything works fine:

    >python -c "print(chr(0x41))"
    A

    >

But if I try to print something a little less common (GREEK CAPITAL LETTER ALPHA), something weird happens:

    >python -c "print(chr(0x391))"
    ?


    >

For another example, let's try to print CYRILLIC CAPITAL LETTER A:

    >python -c "print(chr(0x410))"
    ?


    >

This only happens if the current code page is UTF-8 though.
If I change it to something that can represent those characters, everything seems to be working fine.
For example, the Greek letter:

    >chcp 1252
    Active code page: 1253

    >python -c "print(chr(0x391))"
    ?

    >

And the Cyrillic letter:

    >chcp 1251
    Active code page: 1251

    >python -c "print(chr(0x410))"
    ?

    >

This also happens if one tries to print a string with a funny character somewhere in it. Sometimes it's even worse:

    >python -c "print('??????!')"
    ??????!
    ??!


    >

Look, guys, I know what a mess Unicode handling on Windows is, and I'm not even sure it's Python's fault, I just wanted to make sure I'm not delusional and not making stuff up.
Can somebody at least confirm this? Thank you.

I'm using x86-64 version of Python 3.5.1 on Windows 8.1.

----------
components: Unicode, Windows
messages: 260153
nosy: Egor Tensin, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Extra newline appended to UTF-8 strings on Windows
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26345>
_______________________________________

From report at bugs.python.org  Thu Feb 11 21:12:33 2016
From: report at bugs.python.org (Anthony Tuininga)
Date: Fri, 12 Feb 2016 02:12:33 +0000
Subject: [issue26346] PySequenceMethods documentation missing sq_slice and
 sq_ass_slice
Message-ID: <1455243153.76.0.688486976715.issue26346@psf.upfronthosting.co.za>


New submission from Anthony Tuininga:

These methods are completely missing from the documentation found here:

https://docs.python.org/3/c-api/typeobj.html

----------
assignee: docs at python
components: Documentation
messages: 260154
nosy: atuining, docs at python
priority: normal
severity: normal
status: open
title: PySequenceMethods documentation missing sq_slice and sq_ass_slice
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26346>
_______________________________________

From report at bugs.python.org  Thu Feb 11 21:55:33 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 12 Feb 2016 02:55:33 +0000
Subject: [issue19543] Add -3 warnings for codec convenience method changes
In-Reply-To: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za>
Message-ID: <1455245733.72.0.825424121411.issue19543@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think so - if anyone spots another place a Py3k warning could be usefully emitted, it can be handled as a new issue.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19543>
_______________________________________

From report at bugs.python.org  Thu Feb 11 22:23:14 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Feb 2016 03:23:14 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455247394.56.0.560633724485.issue26344@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I found the problem: you have a bug in your code at line 45 (the first line of WolfPathFinder.find_spec()). When you try and import a top-level package the path will always be None since __path__ doesn't exist for a top-level package. You only end up with a `path` value when there is a __path__ in the parent package. If you put your print() call before the None check it will print out that you actually did have the method called.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Thu Feb 11 22:33:09 2016
From: report at bugs.python.org (Frederick Wagner)
Date: Fri, 12 Feb 2016 03:33:09 +0000
Subject: [issue26347] BoundArguments.apply_defaults doesn't handle empty
 arguments
Message-ID: <1455247989.9.0.159596346531.issue26347@psf.upfronthosting.co.za>


New submission from Frederick Wagner:

[First-time contributor, feedback appreciated.]

Found and fixed some unexpected behavior in inspect.BoundArguments.apply_defaults. Simplest explanation is the following test that I added:

        # Make sure a no-args binding still acquires proper defaults.
        def foo(a='spam'): pass
        sig = inspect.signature(foo)
        ba = sig.bind()
        ba.apply_defaults()
        self.assertEqual(list(ba.arguments.items()), [('a', 'spam')])

I've included the patch file; is there anything else I can do?

----------
components: Library (Lib), Tests
files: 0001-Make-apply_defaults-work-for-empty-arguments.patch
keywords: patch
messages: 260157
nosy: Frederick Wagner
priority: normal
severity: normal
status: open
title: BoundArguments.apply_defaults doesn't handle empty arguments
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41906/0001-Make-apply_defaults-work-for-empty-arguments.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26347>
_______________________________________

From report at bugs.python.org  Thu Feb 11 22:45:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 12 Feb 2016 03:45:38 +0000
Subject: [issue26339] Python rk0.3b1 KeyError: 'config_argparse_rel_path'
In-Reply-To: <1455202921.22.0.411034223357.issue26339@psf.upfronthosting.co.za>
Message-ID: <1455248738.36.0.564899923425.issue26339@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but both rk and configobj are not part of the Python standard library. Please use their issue tracker to report your problem.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26339>
_______________________________________

From report at bugs.python.org  Thu Feb 11 22:58:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2016 03:58:30 +0000
Subject: [issue26180] multiprocessing.util._afterfork_registry leak in
 threaded environment
In-Reply-To: <1453476286.88.0.329468896089.issue26180@psf.upfronthosting.co.za>
Message-ID: <1455249509.99.0.196286157279.issue26180@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26180>
_______________________________________

From report at bugs.python.org  Thu Feb 11 23:05:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Feb 2016 04:05:54 +0000
Subject: [issue26347] BoundArguments.apply_defaults doesn't handle empty
 arguments
In-Reply-To: <1455247989.9.0.159596346531.issue26347@psf.upfronthosting.co.za>
Message-ID: <1455249954.66.0.524593206192.issue26347@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks good to me

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26347>
_______________________________________

From report at bugs.python.org  Thu Feb 11 23:16:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Feb 2016 04:16:25 +0000
Subject: [issue26346] PySequenceMethods documentation missing sq_slice and
 sq_ass_slice
In-Reply-To: <1455243153.76.0.688486976715.issue26346@psf.upfronthosting.co.za>
Message-ID: <1455250585.17.0.228348149206.issue26346@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe they are missing because they don?t exist in Python 3 :) <https://hg.python.org/cpython/file/v3.5.1/Include/object.h#l291>

Perhaps what is needed instead is a list of the actual fields in order, since I assume Python supports compilers that can?t use the designated initializer (PySequenceMethods){.sq_contains=...} syntax.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26346>
_______________________________________

From report at bugs.python.org  Thu Feb 11 23:31:13 2016
From: report at bugs.python.org (Anthony Tuininga)
Date: Fri, 12 Feb 2016 04:31:13 +0000
Subject: [issue26346] PySequenceMethods documentation missing sq_slice and
 sq_ass_slice
In-Reply-To: <1455243153.76.0.688486976715.issue26346@psf.upfronthosting.co.za>
Message-ID: <1455251473.2.0.574290948164.issue26346@psf.upfronthosting.co.za>


Anthony Tuininga added the comment:

Ah yes. The fields are still there, though, just marked as not used. Interestingly enough they aren't documented in the Python 2 documentation either....and they are in the Python 2.7 headers I have (not marked as unused either).

Your suggestion makes sense. The reason I ran into it is I followed an example found in the core code for Python 3.5.1....which referenced sq_slice and sq_ass_slice in the order they are defined in the structure...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26346>
_______________________________________

From report at bugs.python.org  Thu Feb 11 23:45:53 2016
From: report at bugs.python.org (Robert P Fischer)
Date: Fri, 12 Feb 2016 04:45:53 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1455206705.88.0.63317003714.issue26317@psf.upfronthosting.co.za>
Message-ID: <CAC_jL3wFqoXBhq6ziKBWUizf+=U5tcMYc8o2QDrqfC7AJwZ+_A@mail.gmail.com>


Robert P Fischer added the comment:

> The makefiles use CC throughout and don't look at and OBJC variable. Is
> that variable a standard way to specify an ObjC compiler in makefiles?

I believe that OBJC and OBJCFLAGS are standard for Autoconf/Automake:

https://www.gnu.org/software/automake/manual/html_node/Objective-C-Support.html

https://www.gnu.org/software/autoconf/manual/autoconf-2.61/html_node/Output-Variable-Index.html#Output-Variable-Index

https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=using%20objective%20c%20with%20autoconf%20automake

I wouldn't be opposed to a patch that makes it possible to specify an ObjC
> compiler, could you write such a patch?  BTW. The patch should also update
> the autoconf script (use AC_PROG_OBJC).

Sorry, I don't do Autotools --- a software package that came to us directly
from the seventh level of Hell.  CMake's main claim to fame is it's not as
bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Thu Feb 11 23:48:19 2016
From: report at bugs.python.org (Gustavo Goretkin)
Date: Fri, 12 Feb 2016 04:48:19 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>
Message-ID: <1455252499.97.0.611559954453.issue26343@psf.upfronthosting.co.za>


Gustavo Goretkin added the comment:

Can the documentation be updated accordingly? Currently the documentation (roughly) says that this is available.

If not separately noted, all functions that claim ?Availability: Unix? are supported on Mac OS X, which builds on a Unix core.

....
os.O_EXLOCK
os.O_CLOEXEC

    These constants are only available on Unix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Thu Feb 11 23:49:38 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2016 04:49:38 +0000
Subject: [issue26253] tarfile in stream mode always set zlib compression level
 to 9
In-Reply-To: <1454288123.43.0.462874591937.issue26253@psf.upfronthosting.co.za>
Message-ID: <1455252578.09.0.895167583219.issue26253@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26253>
_______________________________________

From report at bugs.python.org  Fri Feb 12 00:01:54 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2016 05:01:54 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>
Message-ID: <1455253314.62.0.448176050206.issue26343@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is only one example of many cases of calls and options that are exposed by the os module but are not available on specific platforms or platform releases.  It would be a huge documentation effort to try to identify and keep them all up-to-date.  The fourth bullet at the beginning of the "os" module doc page is intended to cover this:

"An ?Availability: Unix? note means that this function is commonly found on Unix systems. It does not make any claims about its existence on a specific operating system."

https://docs.python.org/3/library/os.html#module-os

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Fri Feb 12 00:19:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2016 05:19:15 +0000
Subject: [issue26279] time.strptime does not properly convert out-of-bounds
 values
In-Reply-To: <1454515371.52.0.00863631935711.issue26279@psf.upfronthosting.co.za>
Message-ID: <1455254355.63.0.420631769209.issue26279@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report.  Closing this issue as a duplicate of Issue23719.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> PEP 475: port test_eintr to Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26279>
_______________________________________

From report at bugs.python.org  Fri Feb 12 00:21:10 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2016 05:21:10 +0000
Subject: [issue26279] time.strptime does not properly convert out-of-bounds
 values
In-Reply-To: <1454515371.52.0.00863631935711.issue26279@psf.upfronthosting.co.za>
Message-ID: <1455254470.92.0.248512477638.issue26279@psf.upfronthosting.co.za>


Ned Deily added the comment:

Make that Issue23718

----------
superseder: PEP 475: port test_eintr to Windows -> strptime() can produce invalid date with negative year day

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26279>
_______________________________________

From report at bugs.python.org  Fri Feb 12 00:21:45 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2016 05:21:45 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
In-Reply-To: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>
Message-ID: <1455254505.31.0.698364034326.issue23718@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +iaslan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23718>
_______________________________________

From report at bugs.python.org  Fri Feb 12 04:54:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Feb 2016 09:54:01 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455270841.94.0.754402291729.issue24165@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I ran again the benchmark on long_fl.patch of issue #26341 with -b all. The problem is that I don't know what to think about the benchmark, to me all these number only look like noise :-/ If we ignore changes smaller than 1.05 (positive or negative), the patch has no impact on performance on such macro benchmark.

I didn't say that the patches are useless :-) We may focus on micro-benchmark?

$ ~/bin/taskset_isolated.py time python3 -u perf.py --rigorous ../default/python.orig ../default/python_long_fl -b all

Report on Linux smithers 4.3.4-300.fc23.x86_64 #1 SMP Mon Jan 25 13:39:23 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### call_method ###
Min: 0.316851 -> 0.308606: 1.03x faster
Avg: 0.317870 -> 0.309778: 1.03x faster
Significant (t=480.37)
Stddev: 0.00014 -> 0.00026: 1.8165x larger

### etree_parse ###
Min: 0.266148 -> 0.255969: 1.04x faster
Avg: 0.267591 -> 0.257492: 1.04x faster
Significant (t=67.72)
Stddev: 0.00108 -> 0.00103: 1.0478x smaller

### etree_process ###
Min: 0.218512 -> 0.225462: 1.03x slower
Avg: 0.220441 -> 0.227143: 1.03x slower
Significant (t=-37.15)
Stddev: 0.00128 -> 0.00127: 1.0035x smaller

### fannkuch ###
Min: 0.962323 -> 0.984226: 1.02x slower
Avg: 0.965782 -> 0.985413: 1.02x slower
Significant (t=-73.63)
Stddev: 0.00213 -> 0.00160: 1.3276x smaller

### float ###
Min: 0.252470 -> 0.257536: 1.02x slower
Avg: 0.259895 -> 0.265731: 1.02x slower
Significant (t=-9.15)
Stddev: 0.00426 -> 0.00474: 1.1125x larger

### json_dump_v2 ###
Min: 2.717022 -> 2.814488: 1.04x slower
Avg: 2.743981 -> 2.835444: 1.03x slower
Significant (t=-46.41)
Stddev: 0.01375 -> 0.01411: 1.0264x larger

### mako_v2 ###
Min: 0.039410 -> 0.037304: 1.06x faster
Avg: 0.040038 -> 0.038094: 1.05x faster
Significant (t=138.56)
Stddev: 0.00024 -> 0.00037: 1.5234x larger

### meteor_contest ###
Min: 0.182787 -> 0.191944: 1.05x slower
Avg: 0.183526 -> 0.193532: 1.05x slower
Significant (t=-147.53)
Stddev: 0.00031 -> 0.00060: 1.9114x larger

### nbody ###
Min: 0.232746 -> 0.221279: 1.05x faster
Avg: 0.233580 -> 0.222623: 1.05x faster
Significant (t=67.66)
Stddev: 0.00052 -> 0.00153: 2.9467x larger

### nqueens ###
Min: 0.254579 -> 0.263282: 1.03x slower
Avg: 0.256874 -> 0.264082: 1.03x slower
Significant (t=-57.86)
Stddev: 0.00110 -> 0.00059: 1.8689x smaller

### pickle_dict ###
Min: 0.502160 -> 0.490473: 1.02x faster
Avg: 0.502456 -> 0.490759: 1.02x faster
Significant (t=654.42)
Stddev: 0.00014 -> 0.00011: 1.1950x smaller

### raytrace ###
Min: 1.271059 -> 1.309407: 1.03x slower
Avg: 1.274115 -> 1.313171: 1.03x slower
Significant (t=-206.50)
Stddev: 0.00123 -> 0.00144: 1.1698x larger

### richards ###
Min: 0.162761 -> 0.158441: 1.03x faster
Avg: 0.164611 -> 0.160229: 1.03x faster
Significant (t=30.03)
Stddev: 0.00107 -> 0.00099: 1.0761x smaller

### simple_logging ###
Min: 0.279392 -> 0.286003: 1.02x slower
Avg: 0.280746 -> 0.287228: 1.02x slower
Significant (t=-59.16)
Stddev: 0.00075 -> 0.00080: 1.0760x larger

### telco ###   
Min: 0.012419 -> 0.011853: 1.05x faster
Avg: 0.012500 -> 0.011968: 1.04x faster
Significant (t=93.79)
Stddev: 0.00003 -> 0.00005: 1.3307x larger

The following not significant results are hidden, use -v to show them:
2to3, call_method_slots, call_method_unknown, call_simple, chameleon_v2, chaos, django_v3, etree_generate, etree_iterparse, fastpickle, fastunpickle, formatted_logging, go, hexiom2, json_load, normal_startup, pathlib, pickle_list, pidigits, regex_compile, regex_effbot, regex_v8, silent_logging, spectral_norm, startup_nosite, tornado_http, unpack_sequence, unpickle_list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Fri Feb 12 05:01:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Feb 2016 10:01:05 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
In-Reply-To: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>
Message-ID: <1455271265.95.0.367830198943.issue23718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please add tests?

----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23718>
_______________________________________

From report at bugs.python.org  Fri Feb 12 05:25:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Feb 2016 10:25:22 +0000
Subject: [issue26343] os.O_CLOEXEC not available on OS X
In-Reply-To: <1455228683.06.0.527873241791.issue26343@psf.upfronthosting.co.za>
Message-ID: <1455272722.87.0.338840699.issue26343@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> FYI Python creates non-inheritable file descriptors by default since Python 3.4: PEP 446.

You didn't reply why you need O_CLOEXEC?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26343>
_______________________________________

From report at bugs.python.org  Fri Feb 12 05:27:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Feb 2016 10:27:39 +0000
Subject: [issue26345] Extra newline appended to UTF-8 strings on Windows
In-Reply-To: <1455239165.25.0.227087852631.issue26345@psf.upfronthosting.co.za>
Message-ID: <1455272859.46.0.574481035985.issue26345@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I guess that it's yet another example of the bug #1602: "windows console doesn't print or input Unicode".

Don't use the Windows console, but use a better console which has a better Unicode support. For example, you can play with IDLE :-) (Maybe PowerShell or ConEmu ?)
https://conemu.github.io/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26345>
_______________________________________

From report at bugs.python.org  Fri Feb 12 05:34:57 2016
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 12 Feb 2016 10:34:57 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455273297.07.0.282962363355.issue24165@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I like Serhiy's patch, too, but it feels like the single-digit case should be enough. I found this comment by Yury a good argument:

"""
I can see improvements in micro benchmarks, but even more importantly, Serhiy's patch reduces memory fragmentations.  99% of all long allocations are coming from freelist when it's there.
"""

Did that comment come from a benchmark suite run? (i.e. actual applications and not micro benchmarks?) And, does it show a difference between the single- and multi-digit cases?

----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Fri Feb 12 05:41:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Feb 2016 10:41:19 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <1455273679.57.0.0327412583804.issue25709@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

b9c8f1c80f47 added a new head. Should we merge 3.3 -> 3.4 -> 3.5 -> default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Fri Feb 12 05:42:03 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Feb 2016 10:42:03 +0000
Subject: [issue26345] Extra newline appended to UTF-8 strings on Windows
In-Reply-To: <1455239165.25.0.227087852631.issue26345@psf.upfronthosting.co.za>
Message-ID: <1455273723.78.0.312972739479.issue26345@psf.upfronthosting.co.za>


Eryk Sun added the comment:

This a third-party problem due to bugs in the console's support for codepage 65001. For the general problem of Unicode in the console, see issue 1602. The best way to resolve this problem is by using the wide-character APIs, WriteConsoleW and ReadConsoleW. I suggest that you try the win_unicode_console package.

> But if I try to print something a little less common
> (GREEK CAPITAL LETTER ALPHA), something weird happens:
>
>    >python -c "print(chr(0x391))"
>    ?
>
>
>    >

In versions of Windows that use the legacy console, WriteFile to a console screen mistakenly returns the number of UTF-16 codes written instead of the number of bytes written. 

For example, '\u0391\r\n' gets encoded as a four-byte buffer, b'\xce\x91\r\n'. Here's the result of writing this buffer to the legacy console, using codepage 65001:

    >>> sys.stdout.buffer.raw.write(b'\xce\x91\r\n')
    ?
    3

Four bytes were written, but the console returns that it wrote three UTF-16 codes. Python's BufferedWriter (i.e. sys.stdout.buffer) sees this as an incomplete write. So it writes the last byte again. That's why you see an extra newline. The problem can be far worse if the UTF-8 buffer contains many non-ASCII characters, especially if it includes codes greater than U+07FF that get encoded as three bytes. 

This particular problem is fixed in the new version of the console that comes with Windows 10. For the legacy console, you can work around the problem by hooking WriteConsoleA and WriteFile via DLL injection. For example, ANSICON and ConEmu do this.

That said, there's a far worse problem with using codepage 65001 in the console, which still exists in Windows 10. Due to this bug Python's interactive REPL will quit whenever you try to enter non-ASCII characters, and built-in input() will raise EOFError. For example:

    >>> input()
    ?
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    EOFError

To read the console's wide-character (UTF-16) input buffer via ReadFile, it has to first get encoded to the current codepage. The console does the conversion via WideCharToMultiByte with a buffer size that assumes each UTF-16 value will be encoded as a single byte. But that's wrong for UTF-8, in which one UTF-16 code can map to as many as three bytes. So WideCharToMultiByte fails, but does the console try to increase the buffer size? No. Does it fail the call? No. It actually returns back that it 'successfully' read 0 bytes. To the REPL and built-in input() that signals EOF (end of file).

If you only need to input text in your system locale, you can try to have the best of both worlds. Use chcp.com to set the command prompt to the codepage you need for input. Then in your Python script (e.g. in sitecustomize.py) you can use ctypes to change just the output codepage and rebind sys.stdout. For example:

    >>> import os, sys, ctypes
    >>> ctypes.WinDLL('kernel32').SetConsoleOutputCP(65001)
    1
    >>> sys.stdout = open(os.dup(sys.__stdout__.fileno()), 'w', encoding='cp65001')

    >>> sys.stdin.encoding
    'cp1252'
    >>> input()
    ?
    '?'
    >>> print('\u0391')
    ?

Another minor bug is that the console doesn't keep an overlapping window in case a UTF-8 sequence gets split across multiple writes (typically due to buffering). For example:

    >>> exec(r'''
    ... sys.stdout.buffer.raw.write(b'\xce')
    ... sys.stdout.buffer.raw.write(b'\x91')
    ... ''')
    ??>>>

Since UTF-8 uses up to four bytes per code, the console would have to keep a three-byte buffer to handle the case of a split write.

> Look, guys, I know what a mess Unicode handling on Windows is,
> and I'm not even sure it's Python's fault 

Unicode handling is only a mess in the Windows API if you think Unicode is synonymous with UTF-8. Windows NT is Unicode down to the lowest levels of the kernel, but it's UTF-16 using 16-bit wide characters. Part of the problem is that the C and POSIX APIs that are preferred by cross-platform applications are byte oriented (e.g. null-terminated char strings), so Unicode support becomes synonymous with UTF-8. On Windows this leaves you stuck using the ANSI codepage, which unfortunately cannot be set to codepage 65001. Microsoft would have to rewrite a lot of code to support UTF-8 in the ANSI API, and they have no incentive to pay for that given that they're heavily invested in UTF-16.

----------
nosy: +eryksun
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26345>
_______________________________________

From report at bugs.python.org  Fri Feb 12 06:04:13 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Fri, 12 Feb 2016 11:04:13 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455275053.53.0.952479228318.issue15873@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Fri Feb 12 06:51:47 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Feb 2016 11:51:47 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <1455277907.11.0.048747707845.issue25709@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Don't bother. I can do that once 3.3.7 is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Fri Feb 12 08:08:59 2016
From: report at bugs.python.org (Dan McCombs)
Date: Fri, 12 Feb 2016 13:08:59 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
Message-ID: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>


New submission from Dan McCombs:

Currently, the activate.fish VENV script sets fish's prompt to be prepended with a literal "__VENV_PROMPT__" rather than the contents of the $__VENV_PROMPT__ variable as intended.

The attached patch simply adds the missing "$" to the variable in the conditional test and it's usage, so it's only being set if the variable is non-zero, rather than testing if the string "__VENV_PROMPT__" is non-zero like it is doing right now.

The results in the prompt being correctly prepended by "(my_actual_venv_name)".

----------
components: Library (Lib)
files: activate-fish.patch
keywords: patch
messages: 260175
nosy: Dan McCombs
priority: normal
severity: normal
status: open
title: activate.fish sets VENV prompt incorrectly
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41907/activate-fish.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Fri Feb 12 08:27:33 2016
From: report at bugs.python.org (=?utf-8?q?Thomas_F=C3=BChringer?=)
Date: Fri, 12 Feb 2016 13:27:33 +0000
Subject: [issue26349] Ship python35.lib with the embedded distribution, please
Message-ID: <1455283653.75.0.831667056004.issue26349@psf.upfronthosting.co.za>


New submission from Thomas F?hringer:

I would like to use the new embedded distribution and load-time link to python35.dll. It would make things a lot easier if you could also include python35.lib in the file python-3.5.1-embed-win32.zip.

----------
components: Installation
messages: 260176
nosy: Thomas F?hringer
priority: normal
severity: normal
status: open
title: Ship python35.lib with the embedded distribution, please
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26349>
_______________________________________

From report at bugs.python.org  Fri Feb 12 08:53:24 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 12 Feb 2016 13:53:24 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1455285204.8.0.0672113107652.issue26182@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Thank you Brett, the problem was the missed exec(). With the patch in attachment the tests pass, but it does not seem to me a good solution. Infact, changing the filter at runtime has no effect: 

$ cat foo.py 
import warnings

warnings.simplefilter("always")
async = 33
await = 33

$ ./python foo.py 
$

Does this happen because, putting the PyErr_WarnEx() in Python/ast.c, the warning is issued before the runtime?

Furthermore, if I set the filter from the CL, then the warning is properly triggered, but the file name and line number are wrong: 

$ ./python -Wd foo.py 
sys:1: DeprecationWarning: 'async' will become a reserved keyword in Python 3.7
sys:1: DeprecationWarning: 'await' will become a reserved keyword in Python 3.7

----------
keywords: +patch
Added file: http://bugs.python.org/file41908/async_await.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26182>
_______________________________________

From report at bugs.python.org  Fri Feb 12 08:59:25 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 12 Feb 2016 13:59:25 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455285565.68.0.317977864419.issue24165@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Did that comment come from a benchmark suite run? (i.e. actual applications and not micro benchmarks?) And, does it show a difference between the single- and multi-digit cases?

Yes, more details here: http://bugs.python.org/issue26341#msg260124

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:01:43 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 12 Feb 2016 14:01:43 +0000
Subject: [issue26350] Windoes: signal doc should state certains signals can't
 be registered
Message-ID: <1455285703.05.0.44078516142.issue26350@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

I'm not sure whether this is a bug with signal.signal doc or with the function itself, anyway, here goes. On UNIX I'm able to register a signal handler for SIGTERM which is executed when the signal is received. On Windows I'm able to register it but it will never be executed:


import os, signal

def foo(*args):
    print("foo")  # this never gets printed on Windows

signal.signal(signal.SIGTERM, foo)
os.kill(os.getpid(), signal.SIGTERM)


I think signal module doc should be more clear about this. In details, if it is possible to execute a function on SIGTERM if should explain how. If not (and AFAIK it's not possible) it should state that "signal.signal(signal.SIGTERM, foo)" on Windows is a NOOP.

Note: I'm probably missing something but the same thing applies for SIGINT and possibly (all) other signals, so I'm not sure why Windows has signal.signal in the first place. What's its use case on Windows?

----------
messages: 260179
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: Windoes: signal doc should state certains signals can't be registered

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26350>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:02:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Feb 2016 14:02:43 +0000
Subject: [issue26350] Windoes: signal doc should state certains signals can't
 be registered
In-Reply-To: <1455285703.05.0.44078516142.issue26350@psf.upfronthosting.co.za>
Message-ID: <1455285763.71.0.716700063539.issue26350@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26350>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:03:18 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 12 Feb 2016 14:03:18 +0000
Subject: [issue26347] BoundArguments.apply_defaults doesn't handle empty
 arguments
In-Reply-To: <1455247989.9.0.159596346531.issue26347@psf.upfronthosting.co.za>
Message-ID: <1455285798.22.0.0438024320682.issue26347@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Hi Frederick, the patch looks good.  Thanks for reporting this!  Could you please sign the contributor agreement so that I can commit your patch?

----------
assignee:  -> yselivanov
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26347>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:03:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Feb 2016 14:03:19 +0000
Subject: [issue26350] Windoes: signal doc should state certains signals can't
 be registered
In-Reply-To: <1455285703.05.0.44078516142.issue26350@psf.upfronthosting.co.za>
Message-ID: <1455285799.34.0.512627125058.issue26350@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #23948.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26350>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:09:33 2016
From: report at bugs.python.org (Wolfgang Richter)
Date: Fri, 12 Feb 2016 14:09:33 +0000
Subject: [issue26344] `sys.meta_path` Skipped for Packages with Non-Standard
 Suffixed `__init__` Files
In-Reply-To: <1455230383.33.0.948611163745.issue26344@psf.upfronthosting.co.za>
Message-ID: <1455286173.78.0.597739602685.issue26344@psf.upfronthosting.co.za>


Wolfgang Richter added the comment:

Ah, sorry Brett!

Thanks for spotting this.

The import machinery is *really* awesome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26344>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:16:44 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 12 Feb 2016 14:16:44 +0000
Subject: [issue23948] Deprecate os.kill() on Windows
In-Reply-To: <1429025061.32.0.415018485708.issue23948@psf.upfronthosting.co.za>
Message-ID: <1455286604.3.0.658646241184.issue23948@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

See also #26350.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23948>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:18:59 2016
From: report at bugs.python.org (shakur shams Mullick)
Date: Fri, 12 Feb 2016 14:18:59 +0000
Subject: [issue21130] equivalent functools.partial instances should compare
 equal
In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za>
Message-ID: <1455286739.79.0.280201594056.issue21130@psf.upfronthosting.co.za>


Changes by shakur shams Mullick <shakursmullick at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file41909/issue21130.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21130>
_______________________________________

From report at bugs.python.org  Fri Feb 12 09:21:06 2016
From: report at bugs.python.org (shakur shams Mullick)
Date: Fri, 12 Feb 2016 14:21:06 +0000
Subject: [issue21130] equivalent functools.partial instances should compare
 equal
In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za>
Message-ID: <1455286866.38.0.0348157076168.issue21130@psf.upfronthosting.co.za>


shakur shams Mullick added the comment:

I have submitted a patch for the issue. Please review and give feedback.

----------
nosy: +shakur shams Mullick

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21130>
_______________________________________

From report at bugs.python.org  Fri Feb 12 10:05:46 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 12 Feb 2016 15:05:46 +0000
Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming
 a one-to-one Pid -> process mapping.
In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za>
Message-ID: <1455289546.79.0.833561747525.issue24303@psf.upfronthosting.co.za>


Davin Potts added the comment:

@neologix: I second your proposed patch -- looks like a winner to me.  Apologies for not following up earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24303>
_______________________________________

From report at bugs.python.org  Fri Feb 12 10:12:44 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 12 Feb 2016 15:12:44 +0000
Subject: [issue8690] multiprocessing.dummy.Queue does not expose same
 interface as multiprocessing.Queue
In-Reply-To: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za>
Message-ID: <1455289964.92.0.134408610063.issue8690@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8690>
_______________________________________

From report at bugs.python.org  Fri Feb 12 10:13:50 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 12 Feb 2016 15:13:50 +0000
Subject: [issue26333] Multiprocessing imap hangs when generator input errors
In-Reply-To: <1455131025.64.0.640942257663.issue26333@psf.upfronthosting.co.za>
Message-ID: <1455290030.88.0.0395342001104.issue26333@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26333>
_______________________________________

From report at bugs.python.org  Fri Feb 12 10:16:07 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 12 Feb 2016 15:16:07 +0000
Subject: [issue25931] os.fork() command distributed in windows Python27 (in
 SocketServer module)
In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za>
Message-ID: <1455290167.83.0.256972902791.issue25931@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25931>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:18:36 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 12 Feb 2016 17:18:36 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1455297516.12.0.691991073399.issue26182@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26182>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:38:26 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 12 Feb 2016 17:38:26 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455298706.23.0.198396182888.issue26318@psf.upfronthosting.co.za>


???? ????????? added the comment:

1. nasty bugs not in my code!
2. It is not documented that name may be an int, so if applications rely on undocumented stuff are definitely broken, so if IMHO we CAN change that.
3. It will be much stricter to delattr('name') instead of setting as None. This will automatically cure issue21996 and issue22208.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26318>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:40:45 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 12 Feb 2016 17:40:45 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455298845.48.0.81299833015.issue26318@psf.upfronthosting.co.za>


???? ????????? added the comment:

oops, issue22208 is not related issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26318>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:42:47 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 12 Feb 2016 17:42:47 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455298967.03.0.5322671644.issue26318@psf.upfronthosting.co.za>


???? ????????? added the comment:

The main idea: if wile does not have a name, it should not have it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26318>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:47:32 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 12 Feb 2016 17:47:32 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
Message-ID: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

There are a few operations such as summing or unpacking infinite iterators where the interpreter can become unresponsive and ignore Ctrl-C KeyboardInterrupt. Guido suggests that such places should occasionally check for signals:

https://mail.python.org/pipermail/python-ideas/2016-February/038426.html

----------
components: Interpreter Core
messages: 260189
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Occasionally check for Ctrl-C in long-running operations like sum
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:48:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Feb 2016 17:48:32 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455299312.31.0.956108481081.issue26351@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:48:49 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 12 Feb 2016 17:48:49 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
In-Reply-To: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>
Message-ID: <1455299329.71.0.796430995469.issue26342@psf.upfronthosting.co.za>


???? ????????? added the comment:

You should add a tests. especially for edge cases, for negative values for example.

----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Fri Feb 12 12:54:28 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 12 Feb 2016 17:54:28 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
In-Reply-To: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>
Message-ID: <1455299668.7.0.143042369975.issue26342@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> You should add a tests. especially for edge cases, for negative values for example.

There are many binop tests in test_long.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Fri Feb 12 13:15:12 2016
From: report at bugs.python.org (Anish Shah)
Date: Fri, 12 Feb 2016 18:15:12 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1455300912.26.0.365373950697.issue26282@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy:  -anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26282>
_______________________________________

From report at bugs.python.org  Fri Feb 12 13:48:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Feb 2016 18:48:23 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
In-Reply-To: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>
Message-ID: <1455302903.52.0.494513522277.issue26342@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does this patch have effect with results over 8 bits? Does it have effect after applying patches from 24165?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:01:49 2016
From: report at bugs.python.org (Anish Shah)
Date: Fri, 12 Feb 2016 19:01:49 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1455303709.79.0.325013095591.issue26209@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26209>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:21:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 19:21:30 +0000
Subject: [issue26306] Can't create abstract tuple
In-Reply-To: <1454934113.76.0.551150355835.issue26306@psf.upfronthosting.co.za>
Message-ID: <1455304890.72.0.977987540095.issue26306@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

3.2 to 3.4 only get security fixes

----------
components: +Library (Lib)
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 3.6 -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26306>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:21:43 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 19:21:43 +0000
Subject: [issue26306] Can't create abstract tuple
In-Reply-To: <1454934113.76.0.551150355835.issue26306@psf.upfronthosting.co.za>
Message-ID: <1455304903.77.0.264709412557.issue26306@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26306>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:30:11 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 19:30:11 +0000
Subject: [issue26316] Probable typo in Arg Clinic's linear_format()
In-Reply-To: <1454985153.85.0.932055658559.issue26316@psf.upfronthosting.co.za>
Message-ID: <1455305411.02.0.608744248319.issue26316@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Probable typo in Arg Clinic?s linear_format() -> Probable typo in Arg Clinic's linear_format()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26316>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:34:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 19:34:30 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1455305670.41.0.967349592515.issue26317@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

3.4 only gets security fixes

----------
nosy: +terry.reedy
stage:  -> needs patch
type:  -> compile error
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:35:16 2016
From: report at bugs.python.org (Julian Mehnle)
Date: Fri, 12 Feb 2016 19:35:16 +0000
Subject: [issue24961] shell stdout broken after exiting interactive python
 prompt
In-Reply-To: <1440881960.56.0.727538503995.issue24961@psf.upfronthosting.co.za>
Message-ID: <1455305716.52.0.689171973118.issue24961@psf.upfronthosting.co.za>


Changes by Julian Mehnle <julian at mehnle.net>:


----------
nosy: +jmehnle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24961>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:40:22 2016
From: report at bugs.python.org (Robert P Fischer)
Date: Fri, 12 Feb 2016 19:40:22 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1455305670.41.0.967349592515.issue26317@psf.upfronthosting.co.za>
Message-ID: <CAC_jL3zGPBVu4vTbiJ2phrwRBCvLSWPKME4AWCMB+m1QrEHoSQ@mail.gmail.com>


Robert P Fischer added the comment:

Could this be fixed on 3.5 and 3.6?

On Fri, Feb 12, 2016 at 2:34 PM, Terry J. Reedy <report at bugs.python.org>
wrote:

>
> Terry J. Reedy added the comment:
>
> 3.4 only gets security fixes
>
> ----------
> nosy: +terry.reedy
> stage:  -> needs patch
> type:  -> compile error
> versions: +Python 3.5, Python 3.6 -Python 3.4
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26317>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:40:29 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 12 Feb 2016 19:40:29 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
In-Reply-To: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>
Message-ID: <1455306029.66.0.985973467411.issue26342@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Does this patch have effect with results over 8 bits? 

-m timeit -s "x=2**40" "x&2;x&2;x&2;x&333;x&3;x&3;x&4444;x&4"
with patch: 0.404usec      without patch: 0.41


> Does it have effect after applying patches from 24165?

I'm not sure how it's related, but let's modify the test to stress the mem allocation:

-m timeit -s "x=21827623" "(x+x)&2;(x+x)&2;(x+x)&2;(x+x)&333;(x+x)&3;x&3;(x+x)&4444;(x+x)&4"

this patch+freelist: 0.337usec       only freelist: 0.496

In any case, bit operations are often used for bit-flags logic, where numbers are usually aren't too big (it's rare to see more than 30 bit flags on one field).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Fri Feb 12 14:42:49 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 12 Feb 2016 19:42:49 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
In-Reply-To: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>
Message-ID: <1455306169.73.0.62730655043.issue26342@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> with patch: 0.404usec      without patch: 0.41

Sorry, I made a typo: these results should be flipped -- 0.41-0.404 is the overhead of the fastpath's 'if' check.  I'd say it's a pretty small overhead -- we already optimize all other long ops, including bit inversion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Fri Feb 12 15:03:52 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 20:03:52 +0000
Subject: [issue26318] `io.open(fd,
 ...).name` returns numeric fd instead of None
In-Reply-To: <1454999424.95.0.397759883327.issue26318@psf.upfronthosting.co.za>
Message-ID: <1455307432.94.0.743906310337.issue26318@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

3.4 only gets security fixes.  3.5 only gets bug fixes.  Feature changes ('enhancements') are limited to future versions.

This is not a behavior issue because the code and doc match.  https://docs.python.org/3/library/io.html#io.FileIO.name says (as Martin paraphrased) 

"name
    The file name. This is the file descriptor of the file when no name is given in the constructor."

As I remember, this was discussed when io was designed.  The alternatives to name = fd: no name attribute, name = '', name = None.  All are about equally easy to test, as long as the decision is documented, which is clearly is, contrary to the claim otherwise.  I believe the deciding factor is that fd has more information than nothing, even if redundant or useless.

In the absence of sufficient reason to break existing code that follows the doc, which we are generally loathe to do, the design change should be rejected.

----------
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26318>
_______________________________________

From report at bugs.python.org  Fri Feb 12 15:35:48 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 20:35:48 +0000
Subject: [issue26319] Check recData size before unpack in zipfile
In-Reply-To: <1455014276.42.0.95606517598.issue26319@psf.upfronthosting.co.za>
Message-ID: <1455309348.21.0.538392777503.issue26319@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The bug was not noticing the length mismatch caused by a corrupt zip file.  It is already fixed.  The last link in your message opens https://hg.python.org/cpython/file/2.7/Lib/zipfile.py#l238.  A few lines further, the code now has an added guard.

        recData = data[start:start+sizeEndCentDir]
        if len(recData) != sizeEndCentDir:
            # Zip file is corrupted.
            return None
        endrec = list(struct.unpack(structEndArchive, recData))

When reporting a bug, please test on the currect release (ie, 2.7.11).  If this is not possible, and you have the specific traceback as here, one could look at the current code online.  Go to hg.python.org/cpython, select version in the sidebar, select 'Browse' in the sidebar, and then, in this case, /Lib and zipfile.py.

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26319>
_______________________________________

From report at bugs.python.org  Fri Feb 12 15:39:02 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 20:39:02 +0000
Subject: [issue26326] Named entity "vertical line" missed in 2.7
 htmlentitydefs.py
In-Reply-To: <56BB13AF.2030906@online.de>
Message-ID: <1455309542.7.0.453792765456.issue26326@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26326>
_______________________________________

From report at bugs.python.org  Fri Feb 12 15:58:41 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Fri, 12 Feb 2016 20:58:41 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1455310721.13.0.94084928603.issue25887@psf.upfronthosting.co.za>


Andr? Caron added the comment:

Hi there!

I've just stumbled upon this behavior and I was also surprised by the fact that the second await simply returns None.

After fiddling around for a while, I noticed that if I wrap the coroutine object using asyncio.ensure_future() or asyncio.get_event_loop().create_task(), the same result/exception is returned by multiple await expressions.

I haven't looked at the patch, but the intent to make the 2nd await raise a RuntimeError seems strange for several reasons:
- it's inconsistent with the Future/Task interface;
- it's quite common to await a 2nd time to get the coroutine result after calling asyncio.wait(...) using ALL_COMPLETED or FIRST_EXCEPTION;
- as mentioned in the mailing list the await keyword in C#/Hack/JS which inspired the await keyword (as per PEP492) returns the result/exception multiple times.

I put up a Gist that shows the inconsistency: https://gist.github.com/AndreLouisCaron/db2965aae095f5c85dd5

Here's an example of asyncio.wait() I was referencing:

async def main()
    f1 = foo()
    f2 = bar()
    asyncio.wait([f1, f2], return_when=asyncio.FIRST_EXCEPTION)
    print('1:', await f1)
    print('2:', await f2)

I also noticed that there seems to be some intent to avoid making a distinction between a normal function returning a future and a coroutine function from the point of view of the caller.

If the patch is merged as is, I will always need to use asyncio.ensure_future() on all coroutine calls before asyncio.wait() because the result is inconsistent depending on the implementation of foo() and bar(): if they return futures, I'm OK, but if any of them is a proper coroutine function, I might get RuntimeError exceptions.

Any chance you can consider changing the patch to make awaiting a coroutine's result multiple times a valid pattern?

----------
nosy: +Andr? Caron

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25887>
_______________________________________

From report at bugs.python.org  Fri Feb 12 16:01:57 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Feb 2016 21:01:57 +0000
Subject: [issue26350] Windoes: signal doc should state certains signals can't
 be registered
In-Reply-To: <1455285703.05.0.44078516142.issue26350@psf.upfronthosting.co.za>
Message-ID: <1455310917.39.0.157336611357.issue26350@psf.upfronthosting.co.za>


Eryk Sun added the comment:

All of the implemented signals can be registered, and the associated handler can at least be executed by calling the C raise() function. However, for pure-Python code only SIGINT and SIGBREAK are really useful.

FYI, Windows doesn't implement POSIX signals at the system level. The closest analog is an asynchronous procedure call (APC). You can queue a user-mode APC to a thread via QueueUserAPC. It executes when the thread enters an alertable wait (e.g. WaitForSingleObjectEx or SleepEx with bAlertable as TRUE). Kernel-mode APCs get dispatched immediately (when the IRQL is below APC_LEVEL). They're typically used by the I/O manager to complete asynchronous I/O Request Packets (e.g. copying data to a user-mode buffer). 

In principle, NT could implement POSIX-like signals using APCs, but in practice Windows uses other means for the same ends, such as exceptions and structured exception handling (e.g. __try, __except, __finally, __leave, RaiseException, AddVectoredExceptionHandler), dispatch objects (e.g. SetEvent and SetWaitableTimer, which queues an APC), and window messages (e.g. WM_QUIT, WM_TIMER). 

On Windows, the C runtime implements the six signals that are required by standard C: SIGINT, SIGABRT, SIGTERM, SIGSEGV, SIGILL, and SIGFPE. 

SIGABRT and SIGTERM are implemented just for the current process. You can call the handler via C raise(). 

    >>> import signal, ctypes
    >>> ucrtbase = ctypes.CDLL('ucrtbase')
    >>> c_raise = ucrtbase['raise']
    >>> foo = lambda *a: print('foo')
    >>> signal.signal(signal.SIGTERM, foo)
    <Handlers.SIG_DFL: 0>
    >>> c_raise(signal.SIGTERM)
    foo
    0

SIGTERM is useless. 

You also can't do much with SIGABRT using the signal module because the abort() function kills the process once the handler returns, which happens immediately when using the signal module's internal handler (it trips a flag for the Python callable to be called later). Instead use the faulthandler module. Or call the CRT's signal() function via ctypes to set a ctypes callback as the handler.

The CRT implements SIGSEGV, SIGILL, and SIGFPE by setting a Windows structured exception handler (SEH) for the corresponding Windows exceptions:

    STATUS_ACCESS_VIOLATION          SIGSEGV
    STATUS_ILLEGAL_INSTRUCTION       SIGILL
    STATUS_PRIVILEGED_INSTRUCTION    SIGILL
    STATUS_FLOAT_DENORMAL_OPERAND    SIGFPE
    STATUS_FLOAT_DIVIDE_BY_ZERO      SIGFPE
    STATUS_FLOAT_INEXACT_RESULT      SIGFPE
    STATUS_FLOAT_INVALID_OPERATION   SIGFPE
    STATUS_FLOAT_OVERFLOW            SIGFPE
    STATUS_FLOAT_STACK_CHECK         SIGFPE
    STATUS_FLOAT_UNDERFLOW           SIGFPE
    STATUS_FLOAT_MULTIPLE_FAULTS     SIGFPE
    STATUS_FLOAT_MULTIPLE_TRAPS      SIGFPE

Use the faulthandler module for these exception-based signals. The way they're implemented is incompatible with Python's signal handler. The exception filter calls the registered handler and then returns EXCEPTION_CONTINUE_EXECUTION. Python's handler only trips a flag for the interpreter to call the registered Python callable at a later time. So the code that triggered the exception will trigger again, and so on in an endless loop. 

That leaves SIGINT, to which Windows adds the non-standard SIGBREAK. Both console and non-console processes can raise() one of these signals, but only a console process can receive them from another process. 

The CRT sets a console control event handler via SetConsoleCtrlHandler. When the console sends the process a CTRL_C_EVENT or CTRL_BREAK_EVENT, the CRT's handler calls the associated SIGINT or SIGBREAK handler. 

Note that this is implemented by creating a new thread in the process that begins executing at kernel32!CtrlRoutine. Unlike SIGINT on POSIX, the handler does not execute on the main thread (hijacking a thread is taboo in Windows). This can lead to synchronization problems that Python 3 attempts to work around by using a Windows event object.

You can send a control event to all processes attached to the current console via GenerateConsoleCtrlEvent. You can target a subset of processes that belong to a process group, or send the event to all processes by targeting process group 0. 

What the console does when the target ID isn't a process group ID is undefined. It basically acts like the target is group 0, but that shouldn't be relied on. (It's most likely a bug.) It can also mess up the console's list of attached processes (i.e. GetConsoleProcessList) by adding non-console processes. 

The docs for os.kill clearly state that you can only send signal.CTRL_C_EVENT and signal.CTRL_BREAK_EVENT on Windows. Any other value is passed to TerminateProcess as the exit code, which kills the process without notice (like POSIX SIGKILL). 

It also states that "[t]he Windows version of kill() additionally takes process handles to be killed", which I don't think was ever true. That line needs to be removed.

It also fails to clarify that the target has to be a process group ID, and what that is. Every process in a Windows session belongs to a process group, even if it's just the wininit.exe group (services session) or winlogon.exe group (interactive session). A new group is created by passing the creation flag CREATE_NEW_PROCESS_GROUP when creating a new process. The group ID is the process ID of the created process. AFAIK, the console is the only system that uses the process group, and that's just for GenerateConsoleCtrlEvent. 

Don't rely on being able to send CTRL_C_EVENT to anything but group 0, since it's initially disabled in a new process group. It's not impossible to send this event to a new group, but the target process first has to enable CTRL_C_EVENT by calling SetConsoleCtrlHandler(NULL, FALSE).

CTRL_BREAK_EVENT is all you can depend on since it can't be disabled. Sending this event is a simple way to gracefully kill a child process that was started with CREATE_NEW_PROCESS_GROUP, assuming it has a Windows CTRL_BREAK_EVENT or C SIGBREAK handler. If not, the default handler will terminate the process, setting the exit code to STATUS_CTRL_C_EXIT. For example:

    >>> import os, signal, subprocess
    >>> p = subprocess.Popen('python.exe',
    ...         stdin=subprocess.PIPE,
    ...         creationflags=subprocess.CREATE_NEW_PROCESS_GROUP)
    >>> os.kill(p.pid, signal.CTRL_BREAK_EVENT)
    >>> STATUS_CONTROL_C_EXIT = 0xC000013A
    >>> p.wait() == STATUS_CONTROL_C_EXIT
    True

Notice that CTRL_BREAK_EVENT wasn't sent to the current process, because I targeted the process group of the child process (including all of its child processes that are attached to the console, and so on). If I had used group 0, the current process would have been killed as well since I didn't define a SIGBREAK handler. Let's try that, but with a handler set:

    >>> c_break = lambda *a: print('^BREAK')
    >>> signal.signal(signal.SIGBREAK, c_break)
    <Handlers.SIG_DFL: 0>
    >>> os.kill(0, signal.CTRL_BREAK_EVENT)
    ^BREAK

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26350>
_______________________________________

From report at bugs.python.org  Fri Feb 12 16:10:50 2016
From: report at bugs.python.org (Matt Hooks)
Date: Fri, 12 Feb 2016 21:10:50 +0000
Subject: [issue26352] getpass incorrectly displays password prompt on stderr
 on fallback
Message-ID: <1455311450.52.0.299309264077.issue26352@psf.upfronthosting.co.za>


New submission from Matt Hooks:

When calling getpass.getpass(), certain circumstances cause it to fallback to getpass.fallback_getpass, such as when swapping out sys.stdin for another object in a unit test.

In such a circumstance, fallback_getpass may be called with stream=None when getpass itself was called without a stream.  fallback_getpass needs a stream to write the "Warning: Password input may be echoed" warning to, and reasonably chooses stderr.  However, this choice persists down into getpass._raw_input, where the user is then shown the password prompt on stderr as well.  Instead of on stderr, the user should get the password prompt on stdout.

tl;dr: Some calls to getpass.getpass result in a password prompt on stderr.

Bad behavior: password prompt displayed over stderr.
Expected behavior: password prompt should be on stdout.

Found in 3.4, looks like it's the same in 3.5.

I will attach a patch in a few moments, after I get my dev environment sorted out.

----------
components: Library (Lib)
messages: 260202
nosy: Matt Hooks
priority: normal
severity: normal
status: open
title: getpass incorrectly displays password prompt on stderr on fallback
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26352>
_______________________________________

From report at bugs.python.org  Fri Feb 12 16:12:01 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 12 Feb 2016 21:12:01 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1455311521.61.0.346349844063.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I haven't looked at the patch, but the intent to make the 2nd 
> await raise a RuntimeError seems strange for several reasons:
> - it's inconsistent with the Future/Task interface;

Well, coroutines are much more lower level than Future/Tasks.


> - it's quite common to await a 2nd time to get the coroutine 
> result after calling asyncio.wait(...) using ALL_COMPLETED or 
> FIRST_EXCEPTION;

I believe you're not using the asyncio.task() function correctly.  
>From the docs:

"""Wait for the Futures and coroutine objects given by the sequence 
futures to complete. Coroutines will be wrapped in Tasks. Returns 
two sets of Future: (done, pending)."""


> - as mentioned in the mailing list the await keyword in 
> C#/Hack/JS which inspired the await keyword (as per PEP492) 
> returns the result/exception multiple times.

Yes, this was discussed at length on the mailing list.  There are
many reasons as to why we don't want coroutines to be awaitable
many times.  One of them is that we don't want low-level coroutine
objects to hold references to return values.  Coroutines in Python
are exhaustible resources (like generators).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25887>
_______________________________________

From report at bugs.python.org  Fri Feb 12 16:38:01 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 12 Feb 2016 21:38:01 +0000
Subject: [issue26352] getpass incorrectly displays password prompt on stderr
 on fallback
In-Reply-To: <1455311450.52.0.299309264077.issue26352@psf.upfronthosting.co.za>
Message-ID: <1455313081.46.0.46842116575.issue26352@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26352>
_______________________________________

From report at bugs.python.org  Fri Feb 12 16:46:53 2016
From: report at bugs.python.org (Matt Hooks)
Date: Fri, 12 Feb 2016 21:46:53 +0000
Subject: [issue26352] getpass incorrectly displays password prompt on stderr
 on fallback
In-Reply-To: <1455311450.52.0.299309264077.issue26352@psf.upfronthosting.co.za>
Message-ID: <1455313613.56.0.667340456795.issue26352@psf.upfronthosting.co.za>


Matt Hooks added the comment:

Patch attached.

I'm unsure whether forcing the warning message to stderr is the right choice here, but it seems unlikely that users would want their warning and password prompt on the same stream.  The alternative here would be a second kwarg, but that seems overkill.

----------
keywords: +patch
Added file: http://bugs.python.org/file41910/26352_avoid_prompt_on_stderr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26352>
_______________________________________

From report at bugs.python.org  Fri Feb 12 16:48:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Feb 2016 21:48:24 +0000
Subject: [issue26350] Windows: signal doc should state certains signals can't
 be registered
In-Reply-To: <1455285703.05.0.44078516142.issue26350@psf.upfronthosting.co.za>
Message-ID: <1455313704.19.0.00548457797219.issue26350@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
title: Windoes: signal doc should state certains signals can't be registered -> Windows: signal doc should state certains signals can't be registered

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26350>
_______________________________________

From report at bugs.python.org  Fri Feb 12 17:08:12 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 22:08:12 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
Message-ID: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

When one saves the IDLE Shell window, at least when the cursor is at the prompt, \n is added, so that

>>> |

changes to

>>>
|

This seems wrong.  It does not happen in editor windows.  I should check Output Windows.

----------
messages: 260205
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Saving Shell should not add \n
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Fri Feb 12 17:12:04 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 22:12:04 +0000
Subject: [issue26327] IDLE: File > Save in 2.7 Shell with non-ascii fails
In-Reply-To: <1455109189.98.0.269293952823.issue26327@psf.upfronthosting.co.za>
Message-ID: <1455315124.02.0.572355010921.issue26327@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You raised three issues.

1. If you run IDLE from a console (Command Prompt or Powershell) you will see the no-save cause.

C:\Users\Terry>py -m idlelib.idle
Exception in Tkinter callback
...
  File "C:\Programs\Python27\lib\idlelib\IOBinding.py", line 433, in encode
    config_encoding = idleConf.GetOption("main","EditorWindow",
NameError: global name 'idleConf' is not defined

This a bug I introduced into 2.7.11 and have already fixed in the repository (hence 'out of date').  The line above is only executed when there are non-ascii chars, which is why saving worked before you added the non-ascii char.

To get the fix now, in your copy of IOBinding.py, move the line

    from idlelib.configHandler import idleConf

in "def _io_binding" near the bottom of the file to the end of the imports near the top.  Remove the indent before saving.


2. #21140 is about making the default for mixed code and text files .txt instead of .py.


3. The insertion of /n into the Shell text widget when saving it seems like a bug.  I opened #26353 for this.

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
title: File > Save in IDLE shell window not working -> IDLE: File > Save in 2.7 Shell with non-ascii fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26327>
_______________________________________

From report at bugs.python.org  Fri Feb 12 17:28:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 22:28:51 +0000
Subject: [issue21140] Idle: saving Shell or an OutputWindow should default to
 .txt
In-Reply-To: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za>
Message-ID: <1455316131.69.0.684264170003.issue21140@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In #11830 I suggested that Shell should be added to this issue. #26327 does the same, as the prompt and output are not code.

At least in 3.x, these mixed code and text files should be encoded utf-8 (which is the same as ascii for all ascii files), as code files are (at least by default).  The encoding search and determination in IDBinding.py is a bit baroque.  The local encoding should not ever be used for 3.x code.

If we do something with #11838 (save runnable code from Shell), the default should then revert to .py.  I don't want a patch here to make this excessively difficult.

----------
title: Idle: saving an OutputWindow should default to .txt -> Idle: saving Shell or an OutputWindow should default to .txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21140>
_______________________________________

From report at bugs.python.org  Fri Feb 12 17:39:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Feb 2016 22:39:34 +0000
Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming
 a one-to-one Pid -> process mapping.
In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za>
Message-ID: <20160212223931.5772.33416@psf.io>


Roundup Robot added the comment:

New changeset d3662c088db8 by Charles-Fran?ois Natali in branch '2.7':
Issue #24303: Fix random EEXIST upon multiprocessing semaphores creation with
https://hg.python.org/cpython/rev/d3662c088db8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24303>
_______________________________________

From report at bugs.python.org  Fri Feb 12 17:56:42 2016
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 12 Feb 2016 22:56:42 +0000
Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon
 exception
In-Reply-To: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za>
Message-ID: <1455317802.24.0.485231839284.issue23992@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23992>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:06:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Feb 2016 23:06:31 +0000
Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch
 exiting exceptions
In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za>
Message-ID: <1455318391.01.0.604827806727.issue23430@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is an updated version for 3.6. I also wrote an entry for What?s New. It seems my change could help people trying to make a single-threaded server quit the server loop (Issue 13749).

----------
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file41911/socketserver-exit.v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23430>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:16:53 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:16:53 +0000
Subject: [issue26333] Multiprocessing imap hangs when generator input errors
In-Reply-To: <1455131025.64.0.640942257663.issue26333@psf.upfronthosting.co.za>
Message-ID: <1455319013.63.0.382743574906.issue26333@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If you add the "if __name__ == '__main__':" guard after defining the target function, as specified in the multiprocessing doc, you will get a traceback much as you expect:

Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 12, in <module>
    for new_val in pool.imap(add_one, value_iter):
  File "C:\Programs\Python35\lib\multiprocessing\pool.py", line 695, in next
    raise value
  File "C:\Programs\Python35\lib\multiprocessing\pool.py", line 380, in _handle_tasks
    for i, task in enumerate(taskseq):
  File "C:\Programs\Python35\lib\multiprocessing\pool.py", line 286, in <genexpr>
    self._taskqueue.put((((result._job, i, func, (x,), {})
  File "F:\Python\mypy\tem.py", line 10, in <genexpr>
    value_iter = (int(v) for v in values)
ValueError: invalid literal for int() with base 10: 'foo'

I have seem this bug of omission multiple times on Stackoverflow.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26333>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:22:20 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:22:20 +0000
Subject: [issue26334] bytes.translate() doesn't take keyword arguments;
 docs suggests it does
In-Reply-To: <1455133964.48.0.745384045329.issue26334@psf.upfronthosting.co.za>
Message-ID: <1455319340.11.0.882713491479.issue26334@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is a known, generic issue with c-coded functions.  Some C functions have been converted, especially those with boolean parameters, and especially those with multiple boolean parameters.

I think, but an not sure, that / is sometimes used to signal that the preceding are position only, and that this may have something to do with ArgumentClinic.  I also would like a consistent indication.  But this may be a duplicate issue.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26334>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:23:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:23:45 +0000
Subject: [issue26335] Make mmap.write return the number of bytes written like
 other write methods
In-Reply-To: <1455144937.95.0.515520937166.issue26335@psf.upfronthosting.co.za>
Message-ID: <1455319425.44.0.552411999224.issue26335@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26335>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:34:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Feb 2016 23:34:11 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1455320051.7.0.616985266852.issue13501@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the review Ned. I haven?t looked too closely but your comments sound reasonable in general. I don?t have a personal need to update this patch (Editline doesn?t work well for me on Linux), but I can try to update it if there is demand for this.

Regarding the leftover #ifdef __APPLE__ bits, I would have to double-check, but I presume I didn?t need to enable those for my version of Editline, so I presumed they were Apple-specific bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:34:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:34:21 +0000
Subject: [issue26340] modal dialog with transient method;
 parent window fails to iconify
In-Reply-To: <1455210342.9.0.230352859774.issue26340@psf.upfronthosting.co.za>
Message-ID: <1455320061.54.0.293623404139.issue26340@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I changed 'Tkinter' to 'tkinter' and added 'root' to the Toplevel call and got the same behavior running from IDLE on Win10.  I am not sure this is a python bug, as opposed to a change in behavior.  Modal dialogs tend to disable everything else and tk and or Windows might have changed from 2.7.3.

----------
nosy: +serhiy.storchaka, terry.reedy
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26340>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:38:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:38:26 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1455320306.99.0.170319221283.issue26348@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +vinay.sajip
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:39:35 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:39:35 +0000
Subject: [issue26349] Ship python35.lib with the embedded distribution, please
In-Reply-To: <1455283653.75.0.831667056004.issue26349@psf.upfronthosting.co.za>
Message-ID: <1455320375.93.0.712152527367.issue26349@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +steve.dower
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26349>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:41:53 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Fri, 12 Feb 2016 23:41:53 +0000
Subject: [issue26334] bytes.translate() doesn't take keyword arguments;
 docs suggests it does
In-Reply-To: <1455133964.48.0.745384045329.issue26334@psf.upfronthosting.co.za>
Message-ID: <1455320513.54.0.812402746254.issue26334@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Yep, you're right. I'm just understanding now that we have lots of methods defined in C which have signatures like this.

Is there an umbrella issue, perhaps, that covers adding support for keyword-based arguments to functions defined in C, like `translate()`?

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26334>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:47:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:47:16 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1455320836.61.0.494569144013.issue26317@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

When you reply by email to an email, please snip off the quote, except for possible a line that you are responding to.  The disposition of this issue for 3.5+ is up to Ned or Ronald.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:47:31 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Feb 2016 23:47:31 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1455320851.14.0.077632355228.issue26317@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:19:24 2016
From: report at bugs.python.org (Magesh Kumar)
Date: Sat, 13 Feb 2016 00:19:24 +0000
Subject: [issue26354] re.I does not work as expected
Message-ID: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>


New submission from Magesh Kumar:

I am in the process of re.sub the tag <item type="dict"> </item> with empty string from a xml output line.

If "re.I" is used, I am not able to remove the complete tag. 

========================================================================
>>> a
'ype="str">false</latency_statistics_enabled><name type="str">Default</name><aggregates type="list"><item type="dict"><aggregate type="list"><item type="dict"><type type="str">MulticastClient</item><is'

>>> b = re.sub('\<\/?item(\s+type="dict")?\>', '', a, re.I)
>>> b
'ype="str">false</latency_statistics_enabled><name type="str">Default</name><aggregates type="list"><aggregate type="list"><type type="str">MulticastClient</item><is'
>>> b = re.sub('\<\/?item(\s+type="dict")?\>', '', a)
>>> b
'ype="str">false</latency_statistics_enabled><name type="str">Default</name><aggregates type="list"><aggregate type="list"><type type="str">MulticastClient<is'

========================================================================

----------
components: Regular Expressions
messages: 260216
nosy: Magesh Kumar, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.I does not work as expected
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:30:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Feb 2016 00:30:36 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1455323436.0.0.0949336219565.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 6: updated to the new code_transformer() API, it now takes a code object as input and must return a new code object.

Sadly, it looks like there are reference leaks (try: ./python -m test -R 3:3 test_import).

----------
Added file: http://bugs.python.org/file41912/transformers-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26145>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:33:13 2016
From: report at bugs.python.org (TarotRedhand)
Date: Sat, 13 Feb 2016 00:33:13 +0000
Subject: [issue26155] 3.5.1 installer issue on Win 7 32 bit
In-Reply-To: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>
Message-ID: <1455323593.59.0.590535463563.issue26155@psf.upfronthosting.co.za>


TarotRedhand added the comment:

The precise location it was installed to was C:\Users\Nigel\Python35-32. It was supposed to install to my F:\ (labelled DATA) drive. After all this time I don't remember the actual folder it was supposed to use. Incidentally, I have 3 physical HDs. F:\ is a 2tb drive whereas C & D are both 500gb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26155>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:43:02 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Feb 2016 00:43:02 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455324181.99.0.436615893736.issue26354@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

The 4th argument of re.sub is the count, not the flags.

Not a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:44:14 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Feb 2016 00:44:14 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455324254.44.0.233288821808.issue26354@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See #11957

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
superseder:  -> re.sub confusion between count and flags args

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:47:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Feb 2016 00:47:02 +0000
Subject: [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <20160213004659.18364.9231@psf.io>


Roundup Robot added the comment:

New changeset f4d7de7d18c0 by Martin Panter in branch 'default':
Issue #25179: Documentation for formatted string literals aka f-strings
https://hg.python.org/cpython/rev/f4d7de7d18c0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Fri Feb 12 20:07:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Feb 2016 01:07:16 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1455325636.24.0.139322095554.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

TODO: implement a fast-path for PyCode_Optimize() avoiding completly the "expensive" code transformer API, before the first call to sys.set_code_transformer().

It would avoid list <=> tuple conversions for code constants, and the need of creating two code objects.

In practice, this fast-path should be taken in most cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26145>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:10:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Feb 2016 03:10:46 +0000
Subject: [issue25709] Problem with string concatenation and utf-8 cache.
In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za>
Message-ID: <1455333046.89.0.0998558109671.issue25709@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25709>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:14:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 13 Feb 2016 03:14:42 +0000
Subject: [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1455333282.89.0.373486170298.issue25179@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hopefully that did it. Let me know if I missed anything.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:32:00 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Feb 2016 03:32:00 +0000
Subject: [issue25713] Setuptools included with 64-bit Windows installer is
 outdated
In-Reply-To: <1448301960.52.0.82472871794.issue25713@psf.upfronthosting.co.za>
Message-ID: <1455334320.26.0.87887529142.issue25713@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report but, since 3.5.1 has subsequently been released, I don't think there is any reason to keep this open.  The distributions vendored with ensurepip - like pip, setuptools, and their dependencies - will typically become out-of-date after any Python release, since they are all on independent release cycles.  The main function of ensurepip is to ensure that you have a known working environment to install distributions from PyPI and elsewhere, including updates to pip and setuptools themselves.  FWIW, the bundled versions of pip and setuptools have already been updated in the 3.5 branch for the next maintenance release of 3.5.

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25713>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:54:12 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Feb 2016 03:54:12 +0000
Subject: [issue25726] sys.setprofile / sys.getprofile asymetry
In-Reply-To: <1448406267.14.0.484592445826.issue25726@psf.upfronthosting.co.za>
Message-ID: <1455335652.27.0.0153890493171.issue25726@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25726>
_______________________________________

From report at bugs.python.org  Fri Feb 12 23:03:38 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 13 Feb 2016 04:03:38 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1455336218.41.0.109909582461.issue26348@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Fri Feb 12 23:10:45 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Feb 2016 04:10:45 +0000
Subject: [issue25796] Running test_multiprocessing_spawn is slow (more than 8
 minutes)
In-Reply-To: <1449229917.91.0.185617519884.issue25796@psf.upfronthosting.co.za>
Message-ID: <1455336645.7.0.135328212528.issue25796@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +davin, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25796>
_______________________________________

From report at bugs.python.org  Fri Feb 12 23:19:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 13 Feb 2016 04:19:07 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords in Python 3.6
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1455337147.45.0.846629747446.issue26182@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Because parsing is done before execution you can't flip on warnings during runtime in the file you to be affected.

As for the line number, that's because it's raise in C code that doesn't have a trigger in Python code. Try importing the code and you should get the line number of the import. Otherwise you will have to check if there is some function to specify a syntax warning that lets you set the line number explicitly (I don't think there is).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26182>
_______________________________________

From report at bugs.python.org  Fri Feb 12 23:51:33 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Feb 2016 04:51:33 +0000
Subject: [issue25829] Mixing multiprocessing pool and subprocess may create
 zombie process, and cause program to hang.
In-Reply-To: <1449655474.19.0.730082771595.issue25829@psf.upfronthosting.co.za>
Message-ID: <1455339093.79.0.916355292836.issue25829@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25829>
_______________________________________

From report at bugs.python.org  Fri Feb 12 23:54:36 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Feb 2016 04:54:36 +0000
Subject: [issue25833] pyvenv: venvs cannot be moved because activate scripts
 hard-code paths
In-Reply-To: <1449760528.92.0.724215878047.issue25833@psf.upfronthosting.co.za>
Message-ID: <1455339276.8.0.697987377243.issue25833@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25833>
_______________________________________

From report at bugs.python.org  Sat Feb 13 02:44:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Feb 2016 07:44:25 +0000
Subject: [issue26340] modal dialog with transient method;
 parent window fails to iconify
In-Reply-To: <1455210342.9.0.230352859774.issue26340@psf.upfronthosting.co.za>
Message-ID: <1455349465.42.0.266332621639.issue26340@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an equivalent code on Tcl. It behaves as expected on Linux with Tk 8.6 and 8.4. The parent window responds to minimize, maximize, and close events. The modal dialog window iconifies and closes together with the parent window.

Could you test it on Windows?

----------
Added file: http://bugs.python.org/file41913/issue26340.tcl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26340>
_______________________________________

From report at bugs.python.org  Sat Feb 13 03:52:19 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 13 Feb 2016 08:52:19 +0000
Subject: [issue26355] Emit major version based canonical URLs for docs
Message-ID: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Based on a recent comment on one of the mailing lists, I spent a bit of time looking into canonical URLs and their implications for how search engines treat versioned documentation.

The most relevant resource for that in relation to the CPython docs appears to be this page on ReadTheDocs: http://docs.readthedocs.org/en/latest/canonical.html

I sometimes encounter direct links to particular 3.x versions in search results, so I'm wondering if it might be desirable to set up the Python 3 docs to report their canonical URL as "/3/<path>", and the Python 2 docs as "/2/<path>".

----------
messages: 260227
nosy: georg.brandl, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Emit major version based canonical URLs for docs
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26355>
_______________________________________

From report at bugs.python.org  Sat Feb 13 03:52:32 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 13 Feb 2016 08:52:32 +0000
Subject: [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1455353552.99.0.130154106751.issue26355@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26355>
_______________________________________

From report at bugs.python.org  Sat Feb 13 04:47:36 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 13 Feb 2016 09:47:36 +0000
Subject: [issue25833] pyvenv: venvs cannot be moved because activate scripts
 hard-code paths
In-Reply-To: <1449760528.92.0.724215878047.issue25833@psf.upfronthosting.co.za>
Message-ID: <1455356856.21.0.419718426797.issue25833@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Indeed, and in fact *all* scripts written to a venv's bin directory hard-code the path to that venv's interpreter. This confers the benefit that such scripts never need the venv to be explicitly activated - you can e.g. point crontab entries to them directly.

You're better off making the Jenkins job build the environment in its workspace before using it - venvs are intended to be reproducible and, consequently, disposable.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25833>
_______________________________________

From report at bugs.python.org  Sat Feb 13 04:54:23 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 13 Feb 2016 09:54:23 +0000
Subject: [issue11361] suggestion for os.kill(pid,CTRL_C_EVENT) in tests
In-Reply-To: <1298986221.06.0.20392871991.issue11361@psf.upfronthosting.co.za>
Message-ID: <1455357263.27.0.324405496883.issue11361@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11361>
_______________________________________

From report at bugs.python.org  Sat Feb 13 05:24:40 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Feb 2016 10:24:40 +0000
Subject: [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1455359080.9.0.297820996132.issue26355@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26355>
_______________________________________

From report at bugs.python.org  Sat Feb 13 05:27:52 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 13 Feb 2016 10:27:52 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455359272.03.0.413376232386.issue26331@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I like the feature for literals, but I'm not sure about conversions from string. It slows down the conversion for (IMO) a very small benefit.

Other languages allow it, but I've never attempted to use the feature:

$ ocaml
        OCaml version 4.02.1

# float_of_string "__1____2____.___e___101_";;
- : float = 1.2e+102

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 06:21:19 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Feb 2016 11:21:19 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455362479.16.0.624792957512.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It's mostly for consistency. For example, ``int(x, 0)`` is defined by the docs as "interpret x as in a literal".  Other bases have special cases as well, e.g. "0x" is accepted by base 16.

In the current version of the conversions, the string is scanned for "_" before doing the more expensive allocation+copy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 06:39:09 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 13 Feb 2016 11:39:09 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455363549.56.0.0184831422904.issue26331@psf.upfronthosting.co.za>


Stefan Krah added the comment:

If the string conversions stay, may I suggest two functions:

  1) PyUnicode_NumericAsAscii()
  2) PyUnicode_NumericAsAsciiWS()

The first one eliminates only underscores, the second one both
underscores and leading/trailing whitespace.

Decimal must support both:

  https://hg.python.org/cpython/file/default/Modules/_decimal/_decimal.c#l1890

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 06:40:36 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 13 Feb 2016 11:40:36 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455363636.9.0.502366328925.issue26331@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Correction: The explanation of the functions should be reversed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 06:47:46 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Feb 2016 11:47:46 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455364066.13.0.865014191285.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks, I hadn't looked at cdecimal yet - I was planning to ask you to do the necessary changes there :)

But there are a few versions of this (e.g. converting unicode digits to ASCII) scattered throughout the codebase, it would make sense to consolidate on this occasion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 06:58:36 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Feb 2016 11:58:36 +0000
Subject: [issue25726] sys.setprofile / sys.getprofile asymetry
In-Reply-To: <1448406267.14.0.484592445826.issue25726@psf.upfronthosting.co.za>
Message-ID: <1455364716.81.0.100558622619.issue25726@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Ok, this is because internally, sys.setprofile (or to be exact, PyEval_SetProfile) sets two things: a C function, and a "profileobj", which is the argument to setprofile().

sys.setprofile sets the C function to the "profile_trampoline", which supports calling Python profile functions.  The profileobj is the Python profile function.

The C profiler sets the C function to a different callback, and uses the profileobj for storing the reference to the Profiler object.

sys.getprofile just returns the profileobj, which means that you can't save/restore the profiler state with the two functions when using cProfile.

There is not much we can do here except for explicitly documenting this.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25726>
_______________________________________

From report at bugs.python.org  Sat Feb 13 06:59:30 2016
From: report at bugs.python.org (irdb)
Date: Sat, 13 Feb 2016 11:59:30 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1455364770.57.0.0696398753465.issue5150@psf.upfronthosting.co.za>


Changes by irdb <electro.nnn at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:00:55 2016
From: report at bugs.python.org (irdb)
Date: Sat, 13 Feb 2016 12:00:55 +0000
Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal
 interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1455364855.19.0.459535698087.issue2704@psf.upfronthosting.co.za>


Changes by irdb <electro.nnn at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2704>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:03:17 2016
From: report at bugs.python.org (irdb)
Date: Sat, 13 Feb 2016 12:03:17 +0000
Subject: [issue694339] IDLE: Dedenting with Shift+Tab
Message-ID: <1455364997.46.0.917880189353.issue694339@psf.upfronthosting.co.za>


Changes by irdb <electro.nnn at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue694339>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:05:06 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 13 Feb 2016 12:05:06 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455364066.13.0.865014191285.issue26331@psf.upfronthosting.co.za>
Message-ID: <20160213120453.GA3967@bytereef.org>


Stefan Krah added the comment:

> Georg Brandl added the comment:
> 
> Thanks, I hadn't looked at cdecimal yet - I was planning to ask you to do the necessary changes there :)

Oh, well. :)

> But there are a few versions of this (e.g. converting unicode digits to ASCII) scattered throughout the codebase, it would make sense to consolidate on this occasion.

Yes, actually I have to look at the _decimal version again, it contains
some optimizations that may only work for _decimal:

  https://hg.python.org/cpython/file/default/Modules/_decimal/_decimal.c#l1943

I *did* optimize it for speed at the time, I hope general functions won't be
slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:09:28 2016
From: report at bugs.python.org (irdb)
Date: Sat, 13 Feb 2016 12:09:28 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1455365368.97.0.904978385067.issue13504@psf.upfronthosting.co.za>


Changes by irdb <electro.nnn at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:11:43 2016
From: report at bugs.python.org (Irmen de Jong)
Date: Sat, 13 Feb 2016 12:11:43 +0000
Subject: [issue11620] winsound.PlaySound() with SND_MEMORY should accept bytes
 instead of strings
In-Reply-To: <1300667681.04.0.269037633009.issue11620@psf.upfronthosting.co.za>
Message-ID: <1455365503.58.0.324157955547.issue11620@psf.upfronthosting.co.za>


Irmen de Jong added the comment:

Ran into this today when trying to provide a fallback sound output on windows when the user hasn't got pyaudio installed.
It seems that this module has been forgotten and didn't get fixed when the str/bytes change happened in Python 3.0?

----------
nosy: +irmen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11620>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:12:28 2016
From: report at bugs.python.org (Irmen de Jong)
Date: Sat, 13 Feb 2016 12:12:28 +0000
Subject: [issue11620] winsound.PlaySound() with SND_MEMORY should accept bytes
 instead of strings
In-Reply-To: <1300667681.04.0.269037633009.issue11620@psf.upfronthosting.co.za>
Message-ID: <1455365548.74.0.431351789491.issue11620@psf.upfronthosting.co.za>


Changes by Irmen de Jong <irmen at razorvine.net>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11620>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:13:49 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Feb 2016 12:13:49 +0000
Subject: [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1455365629.25.0.900814702943.issue26355@psf.upfronthosting.co.za>


Georg Brandl added the comment:

So we'd have to add a <link> tag? Should be easy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26355>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:41:11 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 13 Feb 2016 12:41:11 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455367271.12.0.298587446631.issue26351@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

At least list() and potentially other container constructors are also affected.

While it's mentioned in the thread, I'll explicitly note here that the problem is specifically with iterators implemented in C, like itertools.count().

Iterators implemented in Python already evaluate Python code on each iteration, which means Ctrl-C gets detected and converted to KeyboardInterrupt.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:56:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Feb 2016 12:56:58 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455368218.01.0.507959250823.issue26351@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Sat Feb 13 08:28:33 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 13 Feb 2016 13:28:33 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455370113.14.0.710797943271.issue26331@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I still wonder about the complexity of all this for decimal. We now have two grammars on top of each other, this being the actual one for decimal:

  http://speleotrove.com/decimal/daconvs.html


For string conversions I'd prefer a lax way (similar to OCaml) that would somehow be specified in terms of preprocessing, same as the leading/trailing whitespace removal. Short of "ignore all underscores" it isn't easy though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 08:52:48 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Feb 2016 13:52:48 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455371568.83.0.775924984687.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Hm. On the one hand there is a spec, so it can be argued that underscores don't belong to Decimal.

On the other hand, if we get Decimal literals at one point, there will be a strong argument for allowing underscores in them as in all other number literals.

Although supporting them in strings can also be added at that time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 08:53:30 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Feb 2016 13:53:30 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1455371610.78.0.587240155956.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Raymond, you've also worked on Decimal - do you have an opinion on allowing underscores in Decimal(string) conversions?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat Feb 13 11:09:34 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sat, 13 Feb 2016 16:09:34 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1455379774.79.0.899478990965.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

I think we have consensus for "try 2". I'm not a core dev, would one of you please merge 25924-getaddrinfo-is-thread-safe-2.patch? Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25924>
_______________________________________

From report at bugs.python.org  Sat Feb 13 11:27:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Feb 2016 16:27:41 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <20160213162735.61229.839@psf.io>


Roundup Robot added the comment:

New changeset cfc66e37eb8e by Vinay Sajip in branch '3.5':
Fixes #26348: Corrected typos in activate.fish script.
https://hg.python.org/cpython/rev/cfc66e37eb8e

New changeset 0f1ac94d2f98 by Vinay Sajip in branch 'default':
Fixes #26348: Merged fix from 3.5.
https://hg.python.org/cpython/rev/0f1ac94d2f98

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Sat Feb 13 11:30:42 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 13 Feb 2016 16:30:42 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1455381042.76.0.101754641425.issue26348@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Sat Feb 13 12:19:57 2016
From: report at bugs.python.org (Ralf Gommers)
Date: Sat, 13 Feb 2016 17:19:57 +0000
Subject: [issue23102] distutils: isinstance checks fail with
 setuptools-monkeypatched Extension/Distribution
In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za>
Message-ID: <1455383997.1.0.774029622249.issue23102@psf.upfronthosting.co.za>


Changes by Ralf Gommers <ralf.gommers at gmail.com>:


----------
nosy: +ralf.gommers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23102>
_______________________________________

From report at bugs.python.org  Sat Feb 13 12:20:57 2016
From: report at bugs.python.org (Ralf Gommers)
Date: Sat, 13 Feb 2016 17:20:57 +0000
Subject: [issue23114] "dist must be a Distribution instance" check fails with
 setuptools
In-Reply-To: <1419589855.59.0.704259891528.issue23114@psf.upfronthosting.co.za>
Message-ID: <1455384057.66.0.0800846912387.issue23114@psf.upfronthosting.co.za>


Changes by Ralf Gommers <ralf.gommers at gmail.com>:


----------
nosy: +ralf.gommers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23114>
_______________________________________

From report at bugs.python.org  Sat Feb 13 12:32:22 2016
From: report at bugs.python.org (Ralf Gommers)
Date: Sat, 13 Feb 2016 17:32:22 +0000
Subject: [issue23102] distutils: isinstance checks fail with
 setuptools-monkeypatched Extension/Distribution
In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za>
Message-ID: <1455384742.21.0.707271988559.issue23102@psf.upfronthosting.co.za>


Ralf Gommers added the comment:

Any chance to get this merged?

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23102>
_______________________________________

From report at bugs.python.org  Sat Feb 13 13:01:55 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 13 Feb 2016 18:01:55 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1455386515.34.0.278166702941.issue26209@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy:  -anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26209>
_______________________________________

From report at bugs.python.org  Sat Feb 13 13:21:05 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 13 Feb 2016 18:21:05 +0000
Subject: [issue26349] Ship python35.lib with the embedded distribution, please
In-Reply-To: <1455283653.75.0.831667056004.issue26349@psf.upfronthosting.co.za>
Message-ID: <1455387665.72.0.758850703649.issue26349@psf.upfronthosting.co.za>


Steve Dower added the comment:

It shouldn't make any difference as the lib file is not needed at runtime.

While developing your app, you should use a regular installation to make sure you have all the header files you need. The embeddable distro is for runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26349>
_______________________________________

From report at bugs.python.org  Sat Feb 13 14:55:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Feb 2016 19:55:59 +0000
Subject: [issue26340] modal dialog with transient method;
 parent window fails to iconify
In-Reply-To: <1455210342.9.0.230352859774.issue26340@psf.upfronthosting.co.za>
Message-ID: <1455393359.81.0.513739238335.issue26340@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

How do I run it?  "tcl is not recognized ..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26340>
_______________________________________

From report at bugs.python.org  Sat Feb 13 15:15:08 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Feb 2016 20:15:08 +0000
Subject: [issue26340] modal dialog with transient method;
 parent window fails to iconify
In-Reply-To: <1455210342.9.0.230352859774.issue26340@psf.upfronthosting.co.za>
Message-ID: <1455394508.24.0.411289610584.issue26340@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As near as I can tell, the Windows installer installs tcl/tk libraries but no executable. Perhaps your example could be converted to root.tk.call(? ? ?) form, but I do not know how to do do.  Passing the entire tcl program as one python string argument does not work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26340>
_______________________________________

From report at bugs.python.org  Sat Feb 13 15:21:24 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Sat, 13 Feb 2016 20:21:24 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1455394884.24.0.135751285394.issue25887@psf.upfronthosting.co.za>


Andr? Caron added the comment:

> I believe you're not using the asyncio.task() function correctly.

I assume you meant asyncio.wait().

I just updated my gist with a variant of my example that uses the (done, pending) pair returned by asyncio.wait() as you suggested.

The set of done futures that is returned does not help in this case because you need to test objects by set membership using something like "if f1 in done:", which will never be true because f1 is a coroutine object and the set contains a wrapper returned by asyncio.ensure_future().

So we're back to square 1.  Because you cannot await multiple times on a coroutine object (in contrast to futures), you will need to explicitly call asyncio.ensure_future() on everything you pass to asyncio.wait() if you care about the future's result -- which is more often than not in my experience.

> There are many reasons as to why we don't want coroutines to be awaitable
many times.  One of them is that we don't want low-level coroutine
objects to hold references to return values.  Coroutines in Python
are exhaustible resources (like generators).

I understand concerns for efficiency and management of scarce resources.

However, I don't understand your comment.  Maybe this has something to do with CPython/asyncio internals, which I know nothing about.  If my code keeps a reference to the coroutine object, it can't be released right?  I don't see how adding a reference to the return value or wrapping the coroutine object in a Task wrapper (in order to recover the return value) will affect the allocation of coroutine resources.

> Well, coroutines are much more lower level than Future/Tasks.

>From an implementer's point of view, maybe.  From a user's point of vue, the value of having an "awaitable" concept is that I can use different objects in the same way.  If the semantics of await expressions vary depending on the awaitable's type, then the value of the abstraction is reduced.

If we go back to the core of the issue, the real problem here is the fact that the current behaviour of multiple awaits on a coroutine object is surprising: nobody expects it to return None the 2nd time around.

Raising a RuntimeError instead of returning None is still surprising behaviour IMO.

In addition to that, the error message that was agreed upon in this issue suggests a programming error (you're not _supposed_ to await twice), but what I'm getting to here with my example is that asyncio.wait() is a common/legitimate use case of this.

Anyways, if you insist on considering this a programming error, you should probably reject coroutine objects in calls to asyncio.wait() since there will be effectively no way of recovering the return value after the call to asyncio.wait().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25887>
_______________________________________

From report at bugs.python.org  Sat Feb 13 15:49:20 2016
From: report at bugs.python.org (Haroun Rauni)
Date: Sat, 13 Feb 2016 20:49:20 +0000
Subject: [issue26356] Registration
Message-ID: <CAOnJCMz_EHbTYdXj_8kCVCUFBhgSVpcJBLkC3Ehx_3tJaiePJg@mail.gmail.com>


New submission from Haroun Rauni:

Yes

----------
messages: 260249
nosy: harounrauni
priority: normal
severity: normal
status: open
title: Registration

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26356>
_______________________________________

From report at bugs.python.org  Sat Feb 13 16:17:53 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Sat, 13 Feb 2016 21:17:53 +0000
Subject: [issue26357] asyncio.wait loses coroutine return value
Message-ID: <1455398273.27.0.148553648829.issue26357@psf.upfronthosting.co.za>


New submission from Andr? Caron:

When the asyncio.wait() function with coroutine objects as inputs, it is impossbible to extract the results reliably.

This issue arises because asyncio.wait() returns an unordered set of futures against which membership tests of coroutine objects always fail.

The issue is made even worse by the fact that coroutine objects cannot be awaited multiple times (see https://bugs.python.org/issue25887).  Any await expression on the coroutine object after the call to asyncio.wait() returns None, regardless of the coroutine's return value.

  (See attached `asyncio-wait-coroutine.py` for an example of both these issues.)

In the worst case, multiple inputs are coroutine objects and the set of returned futures contains return values but there is no way to determine which result corresponds to which coroutine call.

To work around this issue, callers need to explicitly use asyncio.ensure_future() on coroutine objects before calling asyncio.wait().

  (See comment in `asyncio-wait-coroutine.py` for an example "fix").

Note that, in general, it is not possible to know ahead of time whether all inputs to asyncio.wait() are coroutines or futures.  Furthermore, the fact that a given third-party library function is implemented as a regular function that returns a Future or a proper coroutine is an implementation decision which may not be part of the public interface.  Even if it is, the inputs to asyncio.wait() may come from complex code paths and it may be difficult to verify that all of them end up producing a Future.

As a consequence, the only reliable way to recover all results from asyncio.wait() is to explicitly call asyncio.ensure_future() on each of the inputs.

When doing so, both the membership test against the `done` set and the await expressions work as expected.

Quickly, there are several possible solutions:
- allow programs to await coroutine multiple times;
- make the set membership test of a coroutine object succeed; or
- change support for coroutine objects as inputs to asyncio.wait():
** update documentation for asyncio.wait() to explain this limitation; or
** explicitly reject coroutine objects; or
** warn when passing coroutine objects as inputs -- unless wrapped.

Related issue: https://bugs.python.org/issue25887 proposes a patch to change the behaviour of awaiting a coroutine object multiple times in order to produce a RuntimeError on all awaits after the 1st.  While that change in behaviour would make it easier to diagnose the loss of the return value, it does not fix this issue.

----------
components: asyncio
files: asyncio-wait-coroutine.py
messages: 260250
nosy: Andr? Caron, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.wait loses coroutine return value
versions: Python 3.5
Added file: http://bugs.python.org/file41914/asyncio-wait-coroutine.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26357>
_______________________________________

From report at bugs.python.org  Sat Feb 13 16:21:51 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Sat, 13 Feb 2016 21:21:51 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1455398511.73.0.0805537908264.issue25887@psf.upfronthosting.co.za>


Andr? Caron added the comment:

After thinking about this some more, I think my problem with asyncio.wait() is a bit bigger than the simple fact that coroutine objects cannot be awaited multiple times.  It seems to me like asyncio.wait() is completely broken for coroutine objects as inputs and that multiple awaits on coroutine objects only make that problem worse.

While I still think there is a major benefit API-wise to have await expressions produce the same behaviour for both Futures and coroutine objects, I'm moving that discussion to issue #26357.

http://bugs.python.org/issue26357

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25887>
_______________________________________

From report at bugs.python.org  Sat Feb 13 16:22:34 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 13 Feb 2016 21:22:34 +0000
Subject: [issue26349] Ship python35.lib with the embedded distribution, please
In-Reply-To: <1455283653.75.0.831667056004.issue26349@psf.upfronthosting.co.za>
Message-ID: <1455398554.4.0.0774426109034.issue26349@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26349>
_______________________________________

From report at bugs.python.org  Sat Feb 13 16:22:49 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 13 Feb 2016 21:22:49 +0000
Subject: [issue26349] Ship python35.lib with the embedded distribution, please
In-Reply-To: <1455283653.75.0.831667056004.issue26349@psf.upfronthosting.co.za>
Message-ID: <1455398569.82.0.319229576075.issue26349@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution: not a bug -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26349>
_______________________________________

From report at bugs.python.org  Sat Feb 13 16:43:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Feb 2016 21:43:15 +0000
Subject: [issue26340] modal dialog with transient method;
 parent window fails to iconify
In-Reply-To: <1455210342.9.0.230352859774.issue26340@psf.upfronthosting.co.za>
Message-ID: <1455399795.36.0.0173415372647.issue26340@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You need to install Tcl/Tk separately (e.g. ActiveTcl) and use the "wish" command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26340>
_______________________________________

From report at bugs.python.org  Sat Feb 13 16:49:46 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 13 Feb 2016 21:49:46 +0000
Subject: [issue26356] Registration
In-Reply-To: <CAOnJCMz_EHbTYdXj_8kCVCUFBhgSVpcJBLkC3Ehx_3tJaiePJg@mail.gmail.com>
Message-ID: <1455400186.13.0.436076523525.issue26356@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26356>
_______________________________________

From report at bugs.python.org  Sat Feb 13 17:48:09 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 13 Feb 2016 22:48:09 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1455403689.76.0.742268338169.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> After thinking about this some more, I think my problem with asyncio.wait() is a bit bigger than the simple fact that coroutine objects cannot be awaited multiple times.  It seems to me like asyncio.wait() is completely broken for coroutine objects as inputs and that multiple awaits on coroutine objects only make that problem worse.

> While I still think there is a major benefit API-wise to have await expressions produce the same behaviour for both Futures and coroutine objects, I'm moving that discussion to issue #26357.

Looks like your problem can solved if you wrap coroutine objects in Tasks and then pass them to asyncio.wait().  In any case, it's good that you've opened #26357 to discuss that.  

I'm going to commit the patch for this issue now, since the current behaviour of coroutines returning None on second await is wrong.  Allowing multiple awaits for coroutine objects also seems very wrong to me, but please feel free to discuss that on python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25887>
_______________________________________

From report at bugs.python.org  Sat Feb 13 18:00:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Feb 2016 23:00:48 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <20160213230042.31077.73858@psf.io>


Roundup Robot added the comment:

New changeset c2a2685ab89b by Yury Selivanov in branch '3.5':
Issue #25887: Raise a RuntimeError when a coroutine is awaited more than once.
https://hg.python.org/cpython/rev/c2a2685ab89b

New changeset 23297d5bbd29 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #25887)
https://hg.python.org/cpython/rev/23297d5bbd29

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25887>
_______________________________________

From report at bugs.python.org  Sat Feb 13 18:01:11 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 13 Feb 2016 23:01:11 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1455404471.51.0.511833993934.issue25887@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25887>
_______________________________________

From report at bugs.python.org  Sat Feb 13 18:25:06 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Feb 2016 23:25:06 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455405906.9.0.602525878047.issue26351@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, this doesn't seem to be solving any real life problems, only contrived examples.  If any changes are made, they should be very restricted in scope, taking care to not wreck the performance of tools designed for speed and not to add useless crud to otherwise clean code.

I think thought needs to be given to the question of whether there is a general purpose means of interrupting C code.  The real world problems I see occurring aren't trivial examples like sum(itertools.count()) -- what people routinely bump into is IDLE's use of Tkinter becoming unresponsive, numpy being asked to apply a high algorithmic complexity transformation to too large of matrix, mistakes during development with ctypes, etc.  In other words, we should collect a list of real problems that cause a spinning wheel of death, rather than cases where the user specifically asked for an infinite summation.

If there are patches aimed at the toy examples, I think the emphasis should be on the consumer side (min, max, sum, list, sorted, etc) rather than on the producer side (i.e. itertools).  One reason to focus on the consumer side is that we control more of those (the world is full of third-party C extension producers).  Another reason is the lazy-evaluation style of functional programming puts the termination responsibility with consumers to provide the most flexibility in grouping the tools (see http://worrydream.com/refs/Hughes-WhyFunctionalProgrammingMatters.pdf ).  Lastly, the focus on the consumer is suggested by itertools programming patterns (i.e. chains of nested iterators driven by a single consumer of mapping/zipping together infinite iterators with a single finite iterator such as map(somefunc, count(), repeat(somearg), repeat(otherarg))).  In those cases, focusing on the many producers would result in many repeated checks per iterator; whereas, focusing on the consumer would give only one check per iteration.

In thinking about the real world issues I've seen, ISTM we should worry instead about unbounded consumption of memory resources without demanding that a user realize what is going on and making them jump in with a Cntl-C before something bad happens.  If you run list(range(100000000000)), memory will fill, then thrash your SSD with swaps, and make your CPU melt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Sat Feb 13 18:27:22 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Feb 2016 23:27:22 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1455406042.4.0.884394037855.issue5150@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

One other thought, it would be nice if there were an option (on by default) to automatically strip trailing whitespace when a file is saved.  That would be much nicer than making the user remember to do periodic clean-ups as they edit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:20:10 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 14 Feb 2016 00:20:10 +0000
Subject: [issue26357] asyncio.wait loses coroutine return value
In-Reply-To: <1455398273.27.0.148553648829.issue26357@psf.upfronthosting.co.za>
Message-ID: <1455409210.79.0.794058564961.issue26357@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I wonder if the right solution isn't to insist that the arguments to await() are Futures, not coroutines. While in many cases (e.g. gather(), wait_for()) it's a useful convention to support either coroutines or Futures, for wait() it does seem pretty useless. Mapping the Futures back to coroutines isn't a good solution either, since you can't get the result out of just the coroutine.

The question is whether we can just change this or whether we should issue some kind of deprecation warning, since it's at least conceivable that someone relies on the current behavior and doesn't care about mapping results back to coroutines (e.g. if the results are self-identifying).

The same issue applies to as_completed(), I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26357>
_______________________________________

From report at bugs.python.org  Sat Feb 13 21:55:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Feb 2016 02:55:06 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1455418506.96.0.173067068481.issue21042@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the new regular expression will still find the wrong library in my libm example above. In 32-bit mode, it will be only looking to match \(libc6.*\). Since my example has the 64-bit line first, that one will match first. (I haven?t actually tested this, but I think I compiled 32-bit Python once before just by specifying CC="gcc -m32". Sorry to keep poking holes in your regular expression :)

Do you know if there is documentation for the ?ldconfig -p? output format, or do we just have to go on what we see? If so, I would change it to ensure the ABI type string is either followed by a comma and space ", " or a closing bracket ")". A comma on its own, or other letters, is not a match.

I did a search for ?find_library?, and the most likely place is /Lib/ctypes/test/test_find.py. You could probably get away with just adding a new method like Test_OpenGL_libs.test_path(). On my computer I have the GL and GLU libraries (but not gle), so I guess that these libraries are fairly common (plus it already has Windows and OS X versions to test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Sat Feb 13 21:55:16 2016
From: report at bugs.python.org (Stephan Sokolow)
Date: Sun, 14 Feb 2016 02:55:16 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1455418516.66.0.835735272527.issue12806@psf.upfronthosting.co.za>


Stephan Sokolow added the comment:

@GraylinKim:

In the interest of people like myself who wander in here via Google, would you mind stating, for the record, what license argparse_formatter.py is under?

----------
nosy: +ssokolow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Sat Feb 13 22:25:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Feb 2016 03:25:47 +0000
Subject: [issue26316] Probable typo in Arg Clinic's linear_format()
In-Reply-To: <1454985153.85.0.932055658559.issue26316@psf.upfronthosting.co.za>
Message-ID: <20160214032543.5770.9243@psf.io>


Roundup Robot added the comment:

New changeset aec2eae8933e by Martin Panter in branch '3.5':
Issue #26316: Fix variable name typo in Argument Clinic
https://hg.python.org/cpython/rev/aec2eae8933e

New changeset 6c122e4e1cb2 by Martin Panter in branch 'default':
Issue #26316: Merge Arg Clinic fix from 3.5
https://hg.python.org/cpython/rev/6c122e4e1cb2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26316>
_______________________________________

From report at bugs.python.org  Sat Feb 13 22:37:46 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sun, 14 Feb 2016 03:37:46 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
Message-ID: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>


New submission from Antti Haapala:

Just noticed when answering a question on StackOverflow (http://stackoverflow.com/q/35387843/918959) that on Python 3 iterating over a mmap object yields individual bytes as bytes objects, even though iterating over slices, indexing and so on gives ints

Example:

    import mmap

    with open('test.dat', 'rb') as f:
        mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
        for b in mm:
            print(b)
            # prints for example b'A' instead of 65
        mm.close()

I believe this should be fixed for the sake of completeness - the documentation says that "Memory-mapped file objects behave like both bytearray and like file objects." - however the current behaviour is neither like a bytearray nor like a file object, and quite confusing.

Similarly the `in` operator seems to be broken; one could search for space using `32 in bytesobj`, which would work for slices but not for the whole mmap object.

----------
messages: 260261
nosy: ztane
priority: normal
severity: normal
status: open
title: mmap.mmap.__iter__ is broken (yields bytes instead of ints)
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Sat Feb 13 23:13:54 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Feb 2016 04:13:54 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455423234.03.0.0585615752375.issue26351@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: http://bugs.python.org/msg260255

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Sat Feb 13 23:35:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Feb 2016 04:35:14 +0000
Subject: [issue26316] Probable typo in Arg Clinic's linear_format()
In-Reply-To: <1454985153.85.0.932055658559.issue26316@psf.upfronthosting.co.za>
Message-ID: <1455424514.06.0.185008256106.issue26316@psf.upfronthosting.co.za>


Martin Panter added the comment:

I did look into testing, but I gave up. :) The test file doesn?t even import. I got the following error (without exception or traceback), cause by the line that reads ?c = clinic.Clinic(language='C')?:

$ (cd Tools/clinic/ && ../../python clinic_test.py)
Error:
Destination does not exist: 'file'
[Exit 255]

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26316>
_______________________________________

From report at bugs.python.org  Sun Feb 14 00:12:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Feb 2016 05:12:54 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock() don't
 shutdwon request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455426774.19.0.134320605425.issue26309@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the test, but it is a bit confusing to have the shutdown_request() method call finish_request() and actually do normal request handling. Maybe it would be better to not handle the request (and not test that a response is received), and just check that shutdown_request() is called or that the client socket is explicitly closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Sun Feb 14 00:16:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Feb 2016 05:16:03 +0000
Subject: [issue5824] SocketServer.DatagramRequestHandler Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1455426963.67.0.160416130485.issue5824@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also see the three commented-out tests in test_socketserver. I presume the code needs to ensure the client binds to a name, and then the tests will be able to receive something back from the server.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________

From report at bugs.python.org  Sun Feb 14 02:33:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Feb 2016 07:33:11 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1455435191.62.0.787518778585.issue20598@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a more conservative patch. What do you think Paul?

* Keep all the changes to single-item and empty lists
* Revert many of the other changes, except where there are only a few arguments and I feel it would make the section or piece of code too inconsistent

----------
stage: commit review -> patch review
Added file: http://bugs.python.org/file41915/single-arg-list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20598>
_______________________________________

From report at bugs.python.org  Sun Feb 14 03:17:16 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Sun, 14 Feb 2016 08:17:16 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455437836.25.0.608748139239.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

#12006 will unfortunately of no use for this one.

Actually, I realized that the best implementation of parsing rfc 3339 is in django dateparse utils. To me it's the finest, the most elegant, and no other one can claim to be more robust since it's probably the #1 iso parsing functions used in python. Have a look at https://docs.djangoproject.com/en/1.9/_modules/django/utils/dateparse/#parse_datetime

Alexander, I won't start before I have your opinion. What do you think ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 04:41:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Feb 2016 09:41:24 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455442884.86.0.39994543263.issue24165@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> 99% of all long allocations are coming from freelist when it's there.

Detailed statistics from a test suite run see in msg242886. Only a half of ints are single-digit with 15-bit digits, and 3/4 with 30-bit digits. 86% of ints are 32-bit. The majority of ints (about 2/3) are small ints in the range [-5..256]. These patches don't affect them.

That is why the effect of patches is not very significant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:12:07 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Feb 2016 10:12:07 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1455444727.91.0.271017153973.issue24165@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The test suite can't really be representative of common workloads and it isn't meant to be.

The real question is not so much if the freelist helps reduce the number of integer allocations (it's obvious it will), it's whether doing so actually speeds up Python significantly. The small object allocator is quite fast.

If freelisting one-digit integers doesn't bring any tangible benefits, it's unlikely that freelisting two-digit integers will. The general distribution of integers probably follows some kind of power law (which is why small integers are interned).

And since most installs are probably 64-bit nowadays, single-digit integers go up to 2**30, which covers the immense majority of uses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:19:37 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 14 Feb 2016 10:19:37 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1455445177.3.0.141081565329.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I've added a fix for the PGO builds after a issue pointed out in #26307. Thank you Christos for your observation!

----------
Added file: http://bugs.python.org/file41916/pgofix-cpython2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:19:45 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 14 Feb 2016 10:19:45 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1455445185.5.0.564310956623.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file41917/pgofix-cpython3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:20:14 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 14 Feb 2016 10:20:14 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1455445214.3.0.835859264048.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:21:13 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 14 Feb 2016 10:21:13 +0000
Subject: [issue26307] no PGO for built-in modules with `make profile-opt`
In-Reply-To: <1454938106.72.0.648611247693.issue26307@psf.upfronthosting.co.za>
Message-ID: <1455445273.46.0.712871204501.issue26307@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I've added a fix for the PGO builds after the issue pointed out by you. Can you please test it also?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26307>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:28:13 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 14 Feb 2016 10:28:13 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
Message-ID: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>


New submission from Alecsandru Patrascu:

Hello,

This is Alecsandru from the Dynamic Scripting Languages Optimization Team at Intel Corporation. I would like to submit a patch as a response to the discussion thread opened in Python-Dev (https://mail.python.org/pipermail/python-dev/2016-February/143215.html), regarding the way CPython is built, mainly the options that are available to the programmers. Analyzing the CPython ecosystem we can see that there are a lot of users that just download the sources and hit the commands "./configure", "make" and "make install" once and then continue using it with their Python scripts. One of the problems with this workflow it that the users do not benefit from the entire optimization features that are existing in the build system, such as PGO and LTO.

Therefore, I propose a workflow, like the following. Assume some work has to be done into the CPython interpreter, a developer can do the following steps:
A. Implementation and debugging phase. 
    1. The command "./configure PYDIST=debug" is ran once. It will enable the Py_DEBUG, -O0 and -g flags
    2. The command "make" is ran once or multiple times
    
B. Testing the implementation from step A, in a pre-release environment
    1. The command "./configure PYDIST=devel" is ran once. It will disable the Py_DEBUG flags and will enable the -O3 and -g flags, and it is just like the current implementation in CPython
    2. The command "make" is ran once or multiple times

C. For any other CPython usage, for example distributing the interpreter, installing it inside an operating system, or just the majority of users who are not CPython developers and only want to compile it once and use it as-is:
    1. The command "./configure" is ran once. Alternatively, the command  "./configure PYDIST=release" can be used. It will disable all debugging functionality, enable the -O3 flag and will enable PGO and LTO.
    2. The command "make" is ran once
    
Thank you,
Alecsandru

----------
components: Build
files: cpython2_pgo_default-v01.patch
keywords: patch
messages: 260271
nosy: alecsandru.patrascu
priority: normal
severity: normal
status: open
title: CPython build options for out-of-the box performance
type: performance
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41918/cpython2_pgo_default-v01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:28:23 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 14 Feb 2016 10:28:23 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1455445703.41.0.793433734251.issue26359@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file41919/cpython3_pgo_default-v02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Sun Feb 14 05:51:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Feb 2016 10:51:23 +0000
Subject: [issue26334] bytes.translate() doesn't take keyword arguments;
 docs suggests it does
In-Reply-To: <1455133964.48.0.745384045329.issue26334@psf.upfronthosting.co.za>
Message-ID: <1455447083.46.0.702857413433.issue26334@psf.upfronthosting.co.za>


Martin Panter added the comment:

Nicholas, there is Issue 8706 about converting functions and methods to accept keywords in general.

There is also the slash ?/? indicator proposed by PEP 457, which is used for some functions in pydoc; bytes.replace() for instance. In Issue 23738 I was trying to get some consensus on using this slash notation in the main documentation, in which case bytes.translate() could look like

bytes.translate(table, delete=b"", /)

And there is Issue 21314 about where to document the slash notation that is already used in pydoc.

----------
nosy: +martin.panter
superseder:  -> accept keyword arguments on most base type methods and builtins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26334>
_______________________________________

From report at bugs.python.org  Sun Feb 14 06:38:46 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2016 11:38:46 +0000
Subject: [issue26360] Deadlock in thread.join
Message-ID: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

On OS X (10.9.5), I'm getting an apparent deadlock in the following simple Python script:

#--------------------------------------------------------
import itertools
import threading

def is_prime(n):
    return n >= 2 and all(n % d for d in xrange(2, n))

def count_primes_in_range(start, stop):
    return sum(is_prime(n) for n in xrange(start, stop))

def main():
    threads = [
        threading.Thread(
            target=count_primes_in_range,
            args=(12500*i, 12500*(i+1))
        )
        for i in xrange(8)
    ]
    for thread in threads:
        thread.start()
    for thread in threads:
        thread.join()


if __name__ == '__main__':
    for i in itertools.count():
        print "Iteration: ", i
        main()
#--------------------------------------------------------

Each iteration takes around 60 seconds, and I typically get a deadlock within the first 5 iterations. It looks as though the deadlock happens during the "thread.join", at a stage where some of the threads have already completed and been joined. The code hangs with no CPU activity, and a backtrace (attached) shows that all the background threads are waiting for the GIL, while the main thread is in a blocking `thread.join` call.

I've attached a gdb-generated stack trace.

I was unable to reproduce this with a debug build of Python. I *have* reproduced with a normal build of Python, and on various Python 2.7 executables from 3rd party sources (Apple, Macports, Enthought Canopy).

I've also not yet managed to reproduce on Python 3, but I haven't tried that hard. I suspect it's a Python 2-only problem, though.

(And yes, this is horrible code that doesn't make much sense. It's actually a cut-down example from a "how not to do it" part of a course on concurrency. Nevertheless, it shouldn't be deadlocking.)

----------
components: Interpreter Core
files: hang_backtrace.txt
messages: 260273
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Deadlock in thread.join
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41920/hang_backtrace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 06:39:23 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2016 11:39:23 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455449963.23.0.828639874929.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Here's the hanging code as an attached file.

----------
Added file: http://bugs.python.org/file41921/threading_hang.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 06:44:47 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2016 11:44:47 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455450287.22.0.243840892296.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Build details: this was a version of Python built with a simple `./configure && make` from commit 32893d8a52a9.

taniyama:cpython mdickinson$ ./python.exe
Python 2.7.10+ (2.7:32893d8a52a9, Feb 14 2016, 11:08:14) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 06:50:04 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Sun, 14 Feb 2016 11:50:04 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455450604.18.0.449480008315.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

Here is the PoC with code taken from django.utils.parse_datetime and adapted for the datetime module (I didn't ask for their agreement yet). Of course tests pass. For me it's the most elegant solution.

(I think date and time also need their "fromisotimestamp" counterpart).

----------
Added file: http://bugs.python.org/file41922/fromisoformat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 06:57:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Feb 2016 11:57:10 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455451030.01.0.405914200362.issue26360@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 07:16:13 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2016 12:16:13 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455452173.37.0.135444693828.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

One thing that looks a bit odd to my eyes is the different values for `lock` in the PyThread_acquire_lock calls (see below). All of threads 2-5 should be waiting on the GIL, so I'd expect to see the same value for `lock` in all those calls. Instead, threads 2 and 5 seem to be waiting on the same lock, but threads 3 and 4 seem to have their own lock. But I don't know this code well enough to know whether it's supposed to be this way.

Thread 5 (Thread 0x1903 of process 14075):
#2  0x00000001000e7e21 in PyThread_acquire_lock (lock=0xed3ed500, waitflag=<optimized out>) at Python/thread_pthread.h:429

Thread 4 (Thread 0x1803 of process 14075):
#2  0x00000001000e7e21 in PyThread_acquire_lock (lock=0xed3ed300, waitflag=<optimized out>) at Python/thread_pthread.h:429

Thread 3 (Thread 0x1703 of process 14075):
#2  0x00000001000e7e21 in PyThread_acquire_lock (lock=0xed3ed600, waitflag=<optimized out>) at Python/thread_pthread.h:429

Thread 2 (Thread 0x1603 of process 14075):
#2  0x00000001000e7e21 in PyThread_acquire_lock (lock=0xed3ed300, waitflag=<optimized out>) at Python/thread_pthread.h:429

Thread 1 (Thread 0x1503 of process 14075):
#2  0x00000001000e7e21 in PyThread_acquire_lock (lock=0x0, waitflag=<optimized out>) at Python/thread_pthread.h:429

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 07:17:08 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2016 12:17:08 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455452228.48.0.89579094478.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> threads 2 and 5

Sorry, that should have said "threads 2 and 4".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 07:22:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Feb 2016 12:22:01 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455452521.51.0.52876133634.issue26360@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

lock=0x0 looks suspicious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 07:30:27 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Sun, 14 Feb 2016 12:30:27 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455453027.22.0.373361631364.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

(slightly improved version, better use of timedelta)

----------
Added file: http://bugs.python.org/file41923/fromisoformat2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 07:43:15 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2016 12:43:15 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455453795.3.0.137731621528.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> lock=0x0 looks suspicious.

Agreed. I think that *could* possibly be a consequence of the earlier multiple GILs, though I haven't figured out exactly how yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 08:57:44 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 14 Feb 2016 13:57:44 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1455458264.69.0.897891640381.issue12806@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Sun Feb 14 09:17:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 14 Feb 2016 14:17:33 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1455453027.22.0.373361631364.issue15873@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbGwMGQE+PxynnNqzvejEiN5HVsZfxHdfNy6L9y5dSEMw@mail.gmail.com>


STINNER Victor added the comment:

Is the django license compatible with the Python license?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 09:32:14 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2016 14:32:14 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455460334.16.0.722518331997.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Update: I *have* been able to reproduce in a debug build. Here's the stack trace.

----------
Added file: http://bugs.python.org/file41924/debug-build-stacktrace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Feb 14 13:01:41 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Sun, 14 Feb 2016 18:01:41 +0000
Subject: [issue8706] accept keyword arguments on most base type methods and
 builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1455472901.8.0.712170174335.issue8706@psf.upfronthosting.co.za>


Changes by Nicholas Chammas <nicholas.chammas at gmail.com>:


----------
nosy: +Nicholas Chammas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Sun Feb 14 13:04:36 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 14 Feb 2016 18:04:36 +0000
Subject: [issue25351] pyvenv activate script failure with specific bash option
In-Reply-To: <1444375437.08.0.147131311455.issue25351@psf.upfronthosting.co.za>
Message-ID: <1455473076.31.0.563282266239.issue25351@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Can you try the attached script in place of the current activate script and see if it meets the requirements?

----------
Added file: http://bugs.python.org/file41925/activate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25351>
_______________________________________

From report at bugs.python.org  Sun Feb 14 13:32:41 2016
From: report at bugs.python.org (yuriy_levchenko)
Date: Sun, 14 Feb 2016 18:32:41 +0000
Subject: [issue26215] Make GC_Head a compile-time option
In-Reply-To: <1453892927.49.0.620193472963.issue26215@psf.upfronthosting.co.za>
Message-ID: <1455474761.17.0.359464044871.issue26215@psf.upfronthosting.co.za>


yuriy_levchenko added the comment:

I'm going to do this under define, as an option. In my application it consumes several mBs + it's some performance for handling  this structure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26215>
_______________________________________

From report at bugs.python.org  Sun Feb 14 16:52:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 14 Feb 2016 21:52:35 +0000
Subject: [issue19841] ConfigParser PEP issues
In-Reply-To: <1385817419.05.0.067066998342.issue19841@psf.upfronthosting.co.za>
Message-ID: <1455486755.27.0.904393451207.issue19841@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Ivailo.

The following changes are going to break the public API:

    -    def get(self, section, option, raw=False, vars=None):
    +    def get(self, section, option, raw=False, vvars=None):

    -    def items(self, section, raw=False, vars=None):
    +    def items(self, section, raw=False, vvars=None):

Also,

    -class RawConfigParser:
    +class RawConfigParser(object):

There are a few differences between old-style and new-style classes. RawConfigParser implements collections.abs.MutableMapping so this isn't a problem in Python 3.

Closing this as "won't fix".

----------
nosy: +berker.peksag
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19841>
_______________________________________

From report at bugs.python.org  Sun Feb 14 18:09:13 2016
From: report at bugs.python.org (Samuel Ainsworth)
Date: Sun, 14 Feb 2016 23:09:13 +0000
Subject: [issue26361] lambda in dict comprehension is broken
Message-ID: <1455491353.47.0.497218626994.issue26361@psf.upfronthosting.co.za>


New submission from Samuel Ainsworth:

If we construct a dict as follows,

x = {t: lambda x: x * t for t in range(5)}

then `x[0](1)` evaluates to 4! Tested on 2.7 and 3.5.

----------
messages: 260287
nosy: Samuel.Ainsworth
priority: normal
severity: normal
status: open
title: lambda in dict comprehension is broken
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26361>
_______________________________________

From report at bugs.python.org  Sun Feb 14 18:14:51 2016
From: report at bugs.python.org (Samuel Ainsworth)
Date: Sun, 14 Feb 2016 23:14:51 +0000
Subject: [issue26361] lambda in dict comprehension is broken
In-Reply-To: <1455491353.47.0.497218626994.issue26361@psf.upfronthosting.co.za>
Message-ID: <1455491691.87.0.263680447691.issue26361@psf.upfronthosting.co.za>


Samuel Ainsworth added the comment:

Also applies to list comprehensions. For example, 

lst = [(lambda x: x * t) for t in range(5)]
lst[0](1)   # => 4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26361>
_______________________________________

From report at bugs.python.org  Sun Feb 14 19:17:25 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 15 Feb 2016 00:17:25 +0000
Subject: [issue26361] lambda in dict comprehension is broken
In-Reply-To: <1455491353.47.0.497218626994.issue26361@psf.upfronthosting.co.za>
Message-ID: <1455495445.13.0.820550062486.issue26361@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

This is the standard behaviour of closures in Python. It's annoying, and often not what you expect, but it's not a bug.

Effectively, your dict or list contains five functions, each of which refer to the same variable "t". By the time the loop finishes, that variable has the value 4, so naturally all five functions see the same value for t.

The standard work-around is to use the default-argument trick to take a snapshot of the current value of the variable at the moment the function is created:

[(lambda x, t=t: x * t) for t in range(5)]

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26361>
_______________________________________

From report at bugs.python.org  Sun Feb 14 20:43:46 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Feb 2016 01:43:46 +0000
Subject: [issue26361] lambda in dict comprehension is broken
In-Reply-To: <1455491353.47.0.497218626994.issue26361@psf.upfronthosting.co.za>
Message-ID: <1455500626.09.0.89892735427.issue26361@psf.upfronthosting.co.za>


Eryk Sun added the comment:

For Python 3 you can also make it a keyword-only argument by adding a bare '*' to the parameter list:

    funcs = [(lambda x, *, t=t: x * t) for t in range(5)]

Code that accidentally calls funcs[0](3, 'silent bug ') will raise a TypeError because "t" can only be passed as a keyword argument.

An alternative is to use another lambda instead of using a default argument:

    funcs = [(lambda y: (lambda x:  x * y))(t) for t in range(5)]

This lets you continue to use a closure (now over the temporary scope of the outer call) and keep the function signature free of extra arguments. However, using a keyword-only argument is obviously less obfuscated.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26361>
_______________________________________

From report at bugs.python.org  Sun Feb 14 21:11:11 2016
From: report at bugs.python.org (Ben Finney)
Date: Mon, 15 Feb 2016 02:11:11 +0000
Subject: [issue26362] Approved API for creating a temporary file path
Message-ID: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>


New submission from Ben Finney:

The security issues of `tempfile.mktemp` are clear when the return value is used to create a filesystem entry. The documentation and docstrings (and even some comments on past issues) are correct o deprecate its use for that purpose.

The function has a use which doers not have security implications: generating test data. When a test case wants to generate unpredictable, unique, valid filesystem paths ? and *never access those paths* on the filesystem ? the `tempfile.mktemp` function is right there and is very useful.

The `tempfile._RandomNameSequence` class would also be useful, but its name also makes clear that it is not part of the library public API.

Please make that functionality available for the purpose of *only* generating filesystem paths as `tempfile._RandomNameSequence` does, in a public, supported, non-deprecated API.

----------
components: Library (Lib)
messages: 260291
nosy: bignose
priority: normal
severity: normal
status: open
title: Approved API for creating a temporary file path
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Sun Feb 14 21:35:28 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 15 Feb 2016 02:35:28 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455503728.2.0.47444134089.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

I don't know. The taken code is really little, modified, and is nothing much that an implementation you had seen a while ago, and recoded by memory not remembering where you saw it in the first place. Do you think that's really an issue ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 21:54:18 2016
From: report at bugs.python.org (karl)
Date: Mon, 15 Feb 2016 02:54:18 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455504858.4.0.256768036015.issue15873@psf.upfronthosting.co.za>


karl added the comment:

>From https://www.djangoproject.com/foundation/cla/faq/

> Am I giving away the copyright to my contributions?
> 
> No. This is a pure license agreement, not a copyright assignment. You 
> still maintain the full copyright for your contributions. You are 
> only providing a license to the DSF to distribute your code without 
> further restrictions. This is not the case for all CLA's, but it is 
> the case for the one we are using.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 22:00:02 2016
From: report at bugs.python.org (karl)
Date: Mon, 15 Feb 2016 03:00:02 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455505202.83.0.0826422118706.issue15873@psf.upfronthosting.co.za>


karl added the comment:

About

> Actually, I realized that the best implementation of parsing rfc 3339 
> is in django dateparse utils. To me it's the finest, the most 
> elegant, and no other one can claim to be more robust since it's 
> probably the #1 iso parsing functions used in python. Have a look at 
> https://docs.djangoproject.com/en/1.9/_modules/django/utils/dateparse/#parse_datetime

How does it parse this date: 

2016-02-15T11:59:46.16588638674+09:00

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 23:02:31 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 15 Feb 2016 04:02:31 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1455505202.83.0.0826422118706.issue15873@psf.upfronthosting.co.za>
Message-ID: <CAKJVQ8_JpWgExWYCwdgUCjQ0cpOBZ+cAO8M3tUPRJu-tVJR7Hw@mail.gmail.com>


Mathieu Dupuy added the comment:

discarding the microseconds digits after the 6th.

2016-02-15 13:30 GMT+10:30 karl <report at bugs.python.org>:

>
> karl added the comment:
>
> About
>
> > Actually, I realized that the best implementation of parsing rfc 3339
> > is in django dateparse utils. To me it's the finest, the most
> > elegant, and no other one can claim to be more robust since it's
> > probably the #1 iso parsing functions used in python. Have a look at
> >
> https://docs.djangoproject.com/en/1.9/_modules/django/utils/dateparse/#parse_datetime
>
> How does it parse this date:
>
> 2016-02-15T11:59:46.16588638674+09:00
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15873>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 14 23:25:21 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 15 Feb 2016 04:25:21 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1455510321.99.0.748891714633.issue26362@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 15 00:47:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Feb 2016 05:47:49 +0000
Subject: [issue26268] Update python.org installers to use OpenSSL 1.0.2f
In-Reply-To: <1454441057.55.0.0354413518189.issue26268@psf.upfronthosting.co.za>
Message-ID: <20160215054745.56714.76196@psf.io>


Roundup Robot added the comment:

New changeset 1ceb431e1876 by Ned Deily in branch '2.7':
Issue #26268: Update OS X 10.5+ installer build to use OpenSSL 1.0.2f.
https://hg.python.org/cpython/rev/1ceb431e1876

New changeset 3c3eae72dd04 by Ned Deily in branch '3.5':
Issue #26268: Update OS X 10.5+ installer build to use OpenSSL 1.0.2f.
https://hg.python.org/cpython/rev/3c3eae72dd04

New changeset 6759581f9fd3 by Ned Deily in branch 'default':
Issue #26268: merge from 3.5
https://hg.python.org/cpython/rev/6759581f9fd3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26268>
_______________________________________

From report at bugs.python.org  Mon Feb 15 00:58:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Feb 2016 05:58:08 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <20160215055805.18338.3033@psf.io>


Roundup Robot added the comment:

New changeset 58ebfa7c1361 by Ned Deily in branch '2.7':
Issue #25924: Avoid unnecessary serialization of getaddrinfo(3) calls on OS X
https://hg.python.org/cpython/rev/58ebfa7c1361

New changeset 86ddb4d747f8 by Ned Deily in branch '3.5':
Issue #25924: Avoid unnecessary serialization of getaddrinfo(3) calls on OS X
https://hg.python.org/cpython/rev/86ddb4d747f8

New changeset caca2b354773 by Ned Deily in branch 'default':
Issue #25924: merge with 3.5
https://hg.python.org/cpython/rev/caca2b354773

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25924>
_______________________________________

From report at bugs.python.org  Mon Feb 15 01:35:53 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 15 Feb 2016 06:35:53 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455518153.03.0.571574161231.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

slightly improved + addresses issues stated here : https://bugs.python.org/review/15873/diff/16581/Lib/datetime.py#newcode1418Lib/datetime.py:1418

----------
Added file: http://bugs.python.org/file41926/fromisoformat3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 01:37:31 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Feb 2016 06:37:31 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1455518251.65.0.446535614283.issue25924@psf.upfronthosting.co.za>


Ned Deily added the comment:

I've committed a revised version of the "try 2" patch for release in 2.7.12, 3.5.2, and 3.6.0.  The revisions were to better follow the somewhat arcane conventions of Apple's availability macros, in particular, to take into account the value of MACOSX_DEPLOYMENT_TARGET.  I didn't have an opportunity to test building it on an actual 10.4 (or 10.3 :) system but I did test with various settings of MACOSX_DEPLOYMENT_TARGET.  Thanks very much, Jesse, for the research and the patch and to everyone else for the reviews and comments.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25924>
_______________________________________

From report at bugs.python.org  Mon Feb 15 02:33:12 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 15 Feb 2016 07:33:12 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1455521592.64.0.330017537359.issue26249@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
nosy: +alecsandru.patrascu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Mon Feb 15 03:34:35 2016
From: report at bugs.python.org (Michel Desmoulin)
Date: Mon, 15 Feb 2016 08:34:35 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1455525275.07.0.0887253878658.issue4806@psf.upfronthosting.co.za>


Michel Desmoulin added the comment:

It gets even weirder with coroutines involved:



>>> f = (coro() for coro in l) 
>>> asyncio.gather(*f) # TypeError: asyncio.gather() argument after * must be a sequence, not generator
>>> asyncio.gather(*[*f]) # ok

Because coroutines are executed later, the last gather() doesn't show the error message. So it tricked you into thinking that the second version is ok while the first one is not.

But of course, both are ok, the problem lies in a bug deeper in your coroutine triggering the TypeError.

----------
nosy: +Michel Desmoulin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Mon Feb 15 03:37:47 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Feb 2016 08:37:47 +0000
Subject: [issue26265] build errors on OS X 10.11 with --enable-universalsdk
In-Reply-To: <1454425969.86.0.641229022171.issue26265@psf.upfronthosting.co.za>
Message-ID: <1455525467.51.0.807812462881.issue26265@psf.upfronthosting.co.za>


Ned Deily added the comment:

Upon further investigation, the issues I saw building a universal Python when using a current default Xcode SDK were due to the introduction in Xcode 7 of the new textual stub libraries in SDKs, the problem described in Issue25136. So I'm closing this issue as a duplicate of that one.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python doesn't find Xcode 7 stub libraries

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26265>
_______________________________________

From report at bugs.python.org  Mon Feb 15 04:04:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 15 Feb 2016 09:04:18 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1455527058.93.0.329028298152.issue4806@psf.upfronthosting.co.za>


Martin Panter added the comment:

Michel: I suspect your code doesn?t actually get up to handling any coroutines, and the problem is in your generator expression. What is ?l?, and what are the items in it? The bug should already be fixed ready for the 3.5.2 and 3.6 releases, but I can produce this on 3.5.0:

>>> l = [None]
>>> f = (coro() for coro in l) 
>>> asyncio.gather(*f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: gather() argument after * must be a sequence, not generator

In the current 3.6 code the bug is fixed:

>>> asyncio.gather(*f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <genexpr>
TypeError: 'NoneType' object is not callable

The reason why the second call does nothing interesting is because the generator expression has already die because of the exception, and there is nothing left to iterate:

>>> remaining = [*f]
>>> remaining
[]
>>> asyncio.gather(*remaining)
<Future finished result=[]>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Mon Feb 15 04:42:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Feb 2016 09:42:09 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <CAKJVQ8_JpWgExWYCwdgUCjQ0cpOBZ+cAO8M3tUPRJu-tVJR7Hw@mail.gmail.com>
Message-ID: <CAMpsgwYmnkt89W-JFVQg+67JTOod3GNqVojPrRvNbCrza+RMXg@mail.gmail.com>


STINNER Victor added the comment:

> How does it parse this date:
> 2016-02-15T11:59:46.16588638674+09:00

Mathieu Dupuy added the comment:
> discarding the microseconds digits after the 6th.

Hum, you should use the same rounding method than
datetime.datetime.fromtimestamp(): ROUND_HALF_UP, as round().

In practice, you can for example pass a floating point number as
microseconds to datetime.datetime constructor.

Since datetime is implemented in C, I'm not sure that using the re is
the best choice. Since the regex looks simple enough, we may parse the
string without the re module. Well, maybe only for the C
implementation.

What is the behaviour is there are spaces before/after the string?
What if there are other characters like letters before/after? You
should add an unit test for that. I expect an error when parsing
"t=2012-04-23T09:15:00" for example.

Your regex ends with $ but doesn't start with ^. Using re.match(), ^
and $ are probably not needed, but I'm not confident when I use regex
:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 04:42:11 2016
From: report at bugs.python.org (Michel Desmoulin)
Date: Mon, 15 Feb 2016 09:42:11 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1455529331.49.0.872218596701.issue4806@psf.upfronthosting.co.za>


Michel Desmoulin added the comment:

We fixed our bug days ago, but I would have expected [*gen] to have triggered an exception before it even got to gather().

The real code was something like:

>>> l = (ensure_awaitable(callable_obj) for callable_obj in callable_list)
>>> gather(*l)

ensure_awaitable() is just using inspect to turn coroutine functions into coroutines, and wraps non coroutine callables with asyncio.coroutine(callable)().

In the end, ensure_awaitable did raise TypeError if the argument passed was not a callable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Mon Feb 15 05:35:57 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Mon, 15 Feb 2016 10:35:57 +0000
Subject: [issue26363] builtins propagation is misleading described in exec and
 eval documentation
Message-ID: <1455532557.86.0.044307885123.issue26363@psf.upfronthosting.co.za>


Changes by Xavier Combelle <xavier.combelle at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, xcombelle
priority: normal
severity: normal
status: open
title: builtins propagation is misleading described in exec and eval documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26363>
_______________________________________

From report at bugs.python.org  Mon Feb 15 05:37:03 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 15 Feb 2016 10:37:03 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1455532623.98.0.870044549043.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Hi Serhiy, any more comments on the zf.open() patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Mon Feb 15 05:42:15 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Mon, 15 Feb 2016 10:42:15 +0000
Subject: [issue26363] __builtins__ propagation is misleading described in exec
 and eval documentation
Message-ID: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>


New submission from Xavier Combelle:

According to my experiment in code, the current behavior of python3.5 is different that the document says. If I understand well the purpose of this behavior is to propagate the __builtins__ global constant if globals has not one.

In
https://docs.python.org/3.6/library/functions.html#eval

it is written  "If the globals dictionary is present and lacks ?__builtins__?, the current globals are copied into globals before expression is parsed." only the __builtins__ looks copied not all the globals


In
https://docs.python.org/3.6/library/functions.html#exec
It is written:
"If the globals dictionary does not contain a value for the key __builtins__, a reference to the dictionary of the built-in module builtins is inserted under that key." it looks like it is not a reference to the built-in module builtin, but a reference to __builtin__ global

----------
title: builtins propagation is misleading described in exec and eval documentation -> __builtins__ propagation is misleading described in exec and eval documentation
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26363>
_______________________________________

From report at bugs.python.org  Mon Feb 15 05:46:55 2016
From: report at bugs.python.org (Julien)
Date: Mon, 15 Feb 2016 10:46:55 +0000
Subject: [issue26363] __builtins__ propagation is misleading described in exec
 and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1455533215.58.0.120397802615.issue26363@psf.upfronthosting.co.za>


Changes by Julien <python at mandark.fr>:


----------
nosy: +sizeof

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26363>
_______________________________________

From report at bugs.python.org  Mon Feb 15 06:01:54 2016
From: report at bugs.python.org (Barry Scott)
Date: Mon, 15 Feb 2016 11:01:54 +0000
Subject: [issue26364] pip uses colour in messages that does not work on white
 terminals
Message-ID: <1455534114.36.0.799410529747.issue26364@psf.upfronthosting.co.za>


New submission from Barry Scott:

pip3 (3.5 on Mac OS X) is outputting a message in yellow that I can barely see on a white background terminal.

"You are using pip version 7.1.2, however version 8.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command."

I suggest that pip only uses text output. But if the pip developers insist on using colour then set both foreground and background colours.

----------
messages: 260307
nosy: barry.scott
priority: normal
severity: normal
status: open
title: pip uses colour in messages that does not work on white terminals
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26364>
_______________________________________

From report at bugs.python.org  Mon Feb 15 06:11:20 2016
From: report at bugs.python.org (Omer Katz)
Date: Mon, 15 Feb 2016 11:11:20 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1455534680.45.0.7674764263.issue21145@psf.upfronthosting.co.za>


Omer Katz added the comment:

Can we make this happen for 3.6?

----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 06:41:07 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 15 Feb 2016 11:41:07 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455536467.31.0.322715991279.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

> Hum, you should use the same rounding method than
datetime.datetime.fromtimestamp(): ROUND_HALF_UP, as round().
In practice, you can for example pass a floating point number as
microseconds to datetime.datetime constructor.

Unfortunately, you're mistaking with the timedelta constructor. Datetime's one only take int :(
But I figured out an elegant manner to cope with (in my opinion)

> Since datetime is implemented in C, I'm not sure that using the re is
the best choice. Since the regex looks simple enough, we may parse the
string without the re module. Well, maybe only for the C
implementation.

No regex available at all in CPython ? Otherwise, yeah, if I have to, I can do it with strptime.

> What is the behaviour is there are spaces before/after the string?
What if there are other characters like letters before/after? You
should add an unit test for that. I expect an error when parsing
"t=2012-04-23T09:15:00" for example.
Your regex ends with $ but doesn't start with ^. Using re.match(), ^
and $ are probably not needed, but I'm not confident when I use regex
:-)

re.match only look at the beginning of the string, so no need for '^'. And therefore, the case
you mention is already handled :)

joined to this mail the last revision of the feature, with correct rounding, more test and one useless
line removed. Maybe the good one :) ?

----------
Added file: http://bugs.python.org/file41927/fromisoformat4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 08:25:05 2016
From: report at bugs.python.org (Ben Kummer)
Date: Mon, 15 Feb 2016 13:25:05 +0000
Subject: [issue26365] ntpath.py Error in Windows
Message-ID: <1455542705.33.0.354690816824.issue26365@psf.upfronthosting.co.za>


New submission from Ben Kummer:

ntpath.py throws an error in Python2.7.11 Windows

Code snippet:
product_dir ="/zope/eggs43"
my_tuple= os.path.split(product_dir)[:-1]
roduct_prefix = os.path.join(my_tuple )

The same code works in python 2.7.11 under Linux

Traceback:
C:\zope\selenium_test>c:\Python27\python.exe python_bug_reproduce.py
Traceback (most recent call last):
  File "python_bug_reproduce.py", line 10, in <module>
    main()
  File "python_bug_reproduce.py", line 7, in main
    product_prefix = os.path.join(my_tuple )
  File "c:\Python27\lib\ntpath.py", line 90, in join
    return result_drive + result_path
TypeError: cannot concatenate 'str' and 'tuple' objects


code to reproduce:

#!/usr/bin/python
import os

def main():
    product_dir ="/zope/eggs43"
    my_tuple= os.path.split(product_dir)[:-1]
    product_prefix = os.path.join(my_tuple )
    
if __name__ == "__main__":
    main()

----------
components: Windows
files: python_bug_reproduce.py
messages: 260310
nosy: ben.kummer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ntpath.py Error in Windows
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41928/python_bug_reproduce.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26365>
_______________________________________

From report at bugs.python.org  Mon Feb 15 08:54:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Feb 2016 13:54:14 +0000
Subject: [issue26365] ntpath.py Error in Windows
In-Reply-To: <1455542705.33.0.354690816824.issue26365@psf.upfronthosting.co.za>
Message-ID: <1455544454.37.0.882851567695.issue26365@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The first argument of os.path.join() (as well as all other) in Python 2.7 must be str or unicode. You pass a tuple.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26365>
_______________________________________

From report at bugs.python.org  Mon Feb 15 08:56:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Feb 2016 13:56:19 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1455544579.8.0.688372124292.issue21145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be. If somebody provide a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 10:49:22 2016
From: report at bugs.python.org (Tony R.)
Date: Mon, 15 Feb 2016 15:49:22 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
Message-ID: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>


New submission from Tony R.:

In the documentation, I noticed several uses of ``.. versionchanged::`` that described things which had been added.  

I love Python, and its documentation, and I wanted to contribute.  So, I figured a low-risk contribution would be to change ``.. versionchanged::`` to ?.. versionadded? where appropriate.  (I also tweaked the descriptions accordingly.  E.g., ?Added the *x* argument? became ?The *x* argument?, because it?s unnecessary to say ?added? in a description under ?.. versionadded?.)

I did also make a few unrelated tweaks along the way--all very minor, and related to phrasing or formatting. 

Please let me know if I can do anything else to get this merged!

----------
assignee: docs at python
components: Documentation
files: _docs-version-markup.patch
keywords: patch
messages: 260313
nosy: Tony R., docs at python
priority: normal
severity: normal
status: open
title: Use ?.. versionadded??over ?.. versionchanged? where appropriate
type: enhancement
Added file: http://bugs.python.org/file41929/_docs-version-markup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:14:32 2016
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 15 Feb 2016 16:14:32 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455552872.93.0.519646126274.issue26366@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Hi Tony,

thanks for the patch, and for the will to contribute.  I'm not sure this patch should be merged though; the original intention was to use "versionadded" where the API item is completely new.  So "The parameter x was added" in a function is using "versionchanged" because only an aspect of the function's signature was changed.

There may be a bit of confusion because many people wrote changes, and not every change is reviewed by the same developers, but this is the original intent that I think we should not change wholesale.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:22:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 15 Feb 2016 16:22:21 +0000
Subject: [issue26364] pip uses colour in messages that does not work on white
 terminals
In-Reply-To: <1455534114.36.0.799410529747.issue26364@psf.upfronthosting.co.za>
Message-ID: <1455553341.14.0.208707073417.issue26364@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but this needs to be reported to the pip issue tracker: https://github.com/pypa/pip/issues

For the record, I found a similar report at https://github.com/pypa/pip/issues/2449

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26364>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:23:14 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Feb 2016 16:23:14 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455553394.44.0.646121361214.issue26366@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I agree with Georg.
I also went to double-check what the devguide says, and at https://docs.python.org/devguide/documenting.html#paragraph-level-markup it shows an example of versionadded for a parameter.
If a versionchanged should be used instead, maybe the devguide should be fixed.

Having versionadded/changed used consistently would also be nice though, especially if we can start exploiting them (together with deprecated/deprecated-removed) to auto-generate sections of the whatsnew page.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:24:37 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Mon, 15 Feb 2016 16:24:37 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock() don't
 shutdwon request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455553477.89.0.438639363318.issue26309@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I changed the test to just check that shutdown_request is called. Hope this is more clear then the previous test.

----------
Added file: http://bugs.python.org/file41930/socketserver-shutdown-if-verify-false4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:31:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Feb 2016 16:31:11 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455553871.93.0.595529322224.issue15873@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> No regex available at all in CPython?

It's not really convenient to use the re module in C.

> Otherwise, yeah, if I have to, I can do it with strptime.

I suggest to parse directly the string with C code, since the format looks quite simple (numbers and a few separators).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:33:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Feb 2016 16:33:55 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1455554035.64.0.589501522702.issue21145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I like the idea of an helper to build a property on-demand, but I dislike the TTL idea, it seems too specific.

If you need TTL, implement your own decorator, or use a regular property and implement your own logic there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:47:28 2016
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 15 Feb 2016 16:47:28 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455554848.32.0.405973473065.issue26366@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The devguide should be updated, yes.

And probably someone should look at the remaining versionadded's...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 15 12:45:16 2016
From: report at bugs.python.org (Omer Katz)
Date: Mon, 15 Feb 2016 17:45:16 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1455554035.64.0.589501522702.issue21145@psf.upfronthosting.co.za>
Message-ID: <CAOZCFcDe3WZWdLBbQsWj76yW+pDd7Uz=UqnDOgvVs9V+YDYftg@mail.gmail.com>


Omer Katz added the comment:

Most implementations these days support TTL because they require it.
The whole point is to remove the need to reimplement such basic
functionality over and over.

??????? ??? ??, 15 ????? 2016 ?-18:33 ??? ?STINNER Victor?? <?
report at bugs.python.org??>:?

>
> STINNER Victor added the comment:
>
> I like the idea of an helper to build a property on-demand, but I dislike
> the TTL idea, it seems too specific.
>
> If you need TTL, implement your own decorator, or use a regular property
> and implement your own logic there.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue21145>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 12:51:49 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Feb 2016 17:51:49 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1455558709.23.0.127992382573.issue21145@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The TTL idea is completely outlandish in a general-purpose library. Let's keep things simple and not try to build a kitchen-sink decorator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 12:53:35 2016
From: report at bugs.python.org (Omer Katz)
Date: Mon, 15 Feb 2016 17:53:35 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1455558709.23.0.127992382573.issue21145@psf.upfronthosting.co.za>
Message-ID: <CAOZCFcCXZ21Hh28DGuwSqMVbJxUv81f=gUp4biQHJVrbkOpOyg@mail.gmail.com>


Omer Katz added the comment:

In that case, most of the users won't use the standard library
@cached_property anyway since they require it.

On Mon, Feb 15, 2016, 19:51 Antoine Pitrou <report at bugs.python.org> wrote:

>
> Antoine Pitrou added the comment:
>
> The TTL idea is completely outlandish in a general-purpose library. Let's
> keep things simple and not try to build a kitchen-sink decorator.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue21145>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 12:54:23 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Feb 2016 17:54:23 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1455558863.87.0.896599061007.issue21145@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm sure many people don't need a TTL on a cached property. Please stop arguing about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 13:03:37 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Mon, 15 Feb 2016 18:03:37 +0000
Subject: [issue26357] asyncio.wait loses coroutine return value
In-Reply-To: <1455398273.27.0.148553648829.issue26357@psf.upfronthosting.co.za>
Message-ID: <1455559417.56.0.173612871727.issue26357@psf.upfronthosting.co.za>


Andr? Caron added the comment:

Hi Guido,

Thanks for the quick reply :-)

AFAICT, there seem to be three possible directions regarding this issue -- for both wait() and as_completed():

1) remove the need for ensure_future(): make the membership test succeed and allow multiple await expressions on the same coroutine;

2) fail fast: reject coroutine objects as inputs to wait() and reject multiple await expressions on coroutine objects (see issue #25887);

3) clarify API usage: deprecate couroutine objects and enhance docs for wait(), as_completed() and ensure_future().

>From a pure API standpoint, #1 makes the API more uniform and less surprising, #2 makes it easier to detect and fix incorrect usage and #3 accelerates troubleshooting when people get bitten by this quirk in the API.

You're right that technically, the case of side-effect-only coroutine invocations is a use case that's currently supported by wait() and that removing this (e.g. by adopting #2) would be a compatibility break.  I personally doubt that this is a common use case as both wait() and as_completed() seem specifically designed to recover the results, but I'm not an asyncio expert either.

Asyncio is still young and is undergoing adoption, so I would like to see this issue resolved without resorting to #3.

Any chance #1 or #2 can be considered?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26357>
_______________________________________

From report at bugs.python.org  Mon Feb 15 13:05:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Feb 2016 18:05:41 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1455559541.01.0.616924331112.issue21145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Most implementations these days support TTL because they require it."

I used this pattern a lot in my old Hachoir project, but I never needed the TTL thing. In my case, data come from the disk and are never invalidated.

Example with the description property:

https://bitbucket.org/haypo/hachoir3/src/9ae394a18d74bb20b5562964e57074e5624132f5/hachoir/field/field.py?at=default&fileviewer=file-view-default#field.py-79

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Mon Feb 15 13:22:43 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 15 Feb 2016 18:22:43 +0000
Subject: [issue26357] asyncio.wait loses coroutine return value
In-Reply-To: <1455398273.27.0.148553648829.issue26357@psf.upfronthosting.co.za>
Message-ID: <1455560563.17.0.325907000589.issue26357@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

TBH I never ever needed to do membership tests on (done, failed) result of asyncio.wait.  If you need to do such tests - just wrap your coroutines into tasks manually.  I honestly don't understand what's the problem and why we need to change anything in asyncio or in Python.  There're tons of code on asyncio now, and this is only a second time someone wants to "fix" await.

Fixing #25887 allows us to enable multiple awaits on coroutines later, but I wouldn't rush that in 3.5 or 3.6.

Restricting asyncio.wait to accept only futures will also cause a lot of pain.  I'd just fix the docs with an explanation of this problem and with a snippet of code showing how to do membership tests if needed.  Alternatively, we can add a wrapper for asyncio.wait (wait_futures?), that will only accept futures/tasks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26357>
_______________________________________

From report at bugs.python.org  Mon Feb 15 14:14:58 2016
From: report at bugs.python.org (Magesh Kumar)
Date: Mon, 15 Feb 2016 19:14:58 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455563698.7.0.9514500632.issue26354@psf.upfronthosting.co.za>


Magesh Kumar added the comment:

Thanks for the inputs, It would be of great help, if someone could help me in explaining the below output :
========================================================================
>>> a 
'ype="str">false</latency_statistics_enabled><name type="str">Default</name><aggregates type="list"><item type="dict"><aggregate type="list"><root><type type="str">MulticastClient</root><is'
>>> b = re.sub('\</?root\>', '', a, re.I)
>>> b
'ype="str">false</latency_statistics_enabled><name type="str">Default</name><aggregates type="list"><item type="dict"><aggregate type="list"><type type="str">MulticastClient<is'
========================================================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Mon Feb 15 14:28:14 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 15 Feb 2016 19:28:14 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455564494.89.0.2341358557.issue26354@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

The pattern '\</?root\>', which is the same as '</?root>', matches the string '<root>', and that is replaced with ''.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Mon Feb 15 14:39:26 2016
From: report at bugs.python.org (Magesh Kumar)
Date: Mon, 15 Feb 2016 19:39:26 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455565166.9.0.742297134129.issue26354@psf.upfronthosting.co.za>


Magesh Kumar added the comment:

:-)
Thanks a lot Matthew for the inputs.

If we compare the first example (<item>) and the <root> example, I am using re.I as the third element. But for the <root> example, still I am not to get the substitution happening correctly.

Could you pls, let me know the reason of change in behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Mon Feb 15 14:40:28 2016
From: report at bugs.python.org (Magesh Kumar)
Date: Mon, 15 Feb 2016 19:40:28 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455565228.73.0.439178085377.issue26354@psf.upfronthosting.co.za>


Magesh Kumar added the comment:

Corrected Message :


If we compare the first example (<item>) and the <root> example, I am using re.I as the third element. But for the <root> example, still I am able to get the substitution happening correctly.

Could you pls, let me know the reason of change in behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Mon Feb 15 15:12:31 2016
From: report at bugs.python.org (Mark Mikofski)
Date: Mon, 15 Feb 2016 20:12:31 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1455567151.15.0.995106227708.issue14597@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

I think I have this issue even after interpreter exits. My setup.py creates a .dll then later loads the dll for testing using ctypes. Subsequent runs of setup.py that would force rebuilding the .dll attempt to delete the old dll first if it exists, but I get permission denied.

Oddly, if I put the load library call inside a function, then, after exiting the interpreter the dll can be deleted.

Windos 7 x64
Python 2.7.10

Sorry if this is by design, a Windows feature, unrelated or the wrong issue. I search SO and these bugs, and only found answers related to unloading dll during script.

----------
nosy: +bwanamarko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Mon Feb 15 16:03:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 15 Feb 2016 21:03:37 +0000
Subject: [issue26224] Add "version added" for documentation of asyncio.timeout
 for documentation of python 3.4, 3.5, 3.6
In-Reply-To: <1453935768.98.0.383268297204.issue26224@psf.upfronthosting.co.za>
Message-ID: <1455570217.74.0.374825038267.issue26224@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26224>
_______________________________________

From report at bugs.python.org  Mon Feb 15 16:12:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 15 Feb 2016 21:12:10 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455570730.26.0.780620935746.issue26366@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you changed existing versionadded notices to versionchanged in similar cases, how would the size of the patch compare? This problem was also recently brought up at <https://bugs.python.org/review/19475/diff/16235/Doc/library/datetime.rst#newcode1180>.

My weak opinion is that a new parameter is a new API item, not just a change in behaviour, so should probably have ?versionadded?. But I hardly think it is a big problem whichever markup is used.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 15 16:13:54 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 15 Feb 2016 21:13:54 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455570834.57.0.694183370027.issue26354@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

The 3rd argument is the count (the maximum number of replacements, although 0 means no limit, not no replacements). You're passing in the flag re.I instead. re.I happens to have the numeric value 2, so you're telling it to do no more than 2 replacements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Mon Feb 15 16:20:04 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 15 Feb 2016 21:20:04 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1455571204.12.0.129733861151.issue26359@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Mon Feb 15 17:11:04 2016
From: report at bugs.python.org (Magesh Kumar)
Date: Mon, 15 Feb 2016 22:11:04 +0000
Subject: [issue26354] re.I does not work as expected
In-Reply-To: <1455322764.68.0.816067707271.issue26354@psf.upfronthosting.co.za>
Message-ID: <1455574264.06.0.740449851077.issue26354@psf.upfronthosting.co.za>


Magesh Kumar added the comment:

Thanks Matthew. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26354>
_______________________________________

From report at bugs.python.org  Mon Feb 15 17:22:18 2016
From: report at bugs.python.org (Ori Avtalion)
Date: Mon, 15 Feb 2016 22:22:18 +0000
Subject: [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <1455574938.89.0.216798791293.issue20169@psf.upfronthosting.co.za>


Changes by Ori Avtalion <ori at avtalion.name>:


----------
nosy: +salty-horse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20169>
_______________________________________

From report at bugs.python.org  Mon Feb 15 17:47:41 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 15 Feb 2016 22:47:41 +0000
Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly
In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za>
Message-ID: <1455576461.36.0.418486916392.issue25738@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

I was looking at this issue, and actually the problem is on a different level.
The function the patch takes place is "send_errror". As its name suggests, it's only used to send error (I checked in the code : it's only used to send 4XX/5XX reply). I'm sure none of this reply forbid to carry a body.
So I think the whole "if code >= 200 and code >= 200 and                   code not in (code not in (HTTPStatus.NO_CONTENT, HTTPStatus.NOT_MODIFIED)):" should just be replaced by a assert 400 <= code < 600.

And more seriously : who could be using this code for a modern real world usage ? Why not delete it ? Isn't it harmful that unwarned might use it ?

----------
nosy: +deronnax

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25738>
_______________________________________

From report at bugs.python.org  Mon Feb 15 17:54:08 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 15 Feb 2016 22:54:08 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455576848.62.0.250942990808.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

> I suggest to parse directly the string with C code, since the format looks quite simple (numbers and a few separators).

But some of them are optional. And I would really like to mimic the same implementation logic in C.

Now I think the python version is fairly ready. What next ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 19:59:01 2016
From: report at bugs.python.org (Manuel Jacob)
Date: Tue, 16 Feb 2016 00:59:01 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
Message-ID: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>


New submission from Manuel Jacob:

Python 3.6.0a0 (default:6c6f7dff597b, Feb 16 2016, 01:24:51) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib
>>> importlib.__import__('array', globals(), locals(), level=1)
<module '.array' from '/home/manu/vcs/cpython/build/lib.linux-x86_64-3.6/array.cpython-36m-x86_64-linux-gnu.so'>
>>> __import__('array', globals(), locals(), level=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: attempted relative import with no known parent package

Instead of failing, importlib.__import__ returns a module with a wrong name.  This happens with both built-in modules and pure python modules.  However it fails when replacing 'array' with 'time' (this seems to be related to whether the module is in Modules/Setup.dist).

----------
messages: 260338
nosy: brett.cannon, eric.snow, mjacob, ncoghlan
priority: normal
severity: normal
status: open
title: importlib.__import__ does not fail for invalid relative import
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Mon Feb 15 20:44:15 2016
From: report at bugs.python.org (Ryan Stuart)
Date: Tue, 16 Feb 2016 01:44:15 +0000
Subject: [issue26368] grammatical error in documentation
Message-ID: <1455587055.9.0.191263906998.issue26368@psf.upfronthosting.co.za>


New submission from Ryan Stuart:

The note for 18.5.5.1. Stream functions is missing a word. It should read "Note The top-level functions in this module are meant **as** convenience wrappers only; there?s really nothing special there, and if they don?t do exactly what you want, feel free to copy their code."

----------
assignee: docs at python
components: Documentation
files: asyncio-stream_docs.patch
keywords: patch
messages: 260339
nosy: Ryan Stuart, docs at python
priority: normal
severity: normal
status: open
title: grammatical error in documentation
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41931/asyncio-stream_docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26368>
_______________________________________

From report at bugs.python.org  Mon Feb 15 21:28:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Feb 2016 02:28:45 +0000
Subject: [issue26368] grammatical error in documentation
In-Reply-To: <1455587055.9.0.191263906998.issue26368@psf.upfronthosting.co.za>
Message-ID: <20160216022841.18358.35548@psf.io>


Roundup Robot added the comment:

New changeset 8ee91cb2e2a4 by Ned Deily in branch '3.5':
Issue #26368: fix typo in asynchio stream doc, reported by Ryan Stuart.
https://hg.python.org/cpython/rev/8ee91cb2e2a4

New changeset 12502327d2c0 by Ned Deily in branch 'default':
Issue #26368: fix typo in asynchio stream doc, reported by Ryan Stuart.
https://hg.python.org/cpython/rev/12502327d2c0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26368>
_______________________________________

From report at bugs.python.org  Mon Feb 15 21:30:14 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 16 Feb 2016 02:30:14 +0000
Subject: [issue26368] grammatical error in asyncio stream documentation
In-Reply-To: <1455587055.9.0.191263906998.issue26368@psf.upfronthosting.co.za>
Message-ID: <1455589814.56.0.0187522270843.issue26368@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report, Ryan!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
title: grammatical error in documentation -> grammatical error in asyncio stream documentation
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26368>
_______________________________________

From report at bugs.python.org  Mon Feb 15 21:52:55 2016
From: report at bugs.python.org (Mike Short)
Date: Tue, 16 Feb 2016 02:52:55 +0000
Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches.
In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za>
Message-ID: <1455591175.47.0.483104131455.issue22062@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file41932/pathlib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22062>
_______________________________________

From report at bugs.python.org  Mon Feb 15 22:03:06 2016
From: report at bugs.python.org (Mike Short)
Date: Tue, 16 Feb 2016 03:03:06 +0000
Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches.
In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za>
Message-ID: <1455591786.68.0.0116693379119.issue22062@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


Added file: http://bugs.python.org/file41933/pathlib.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22062>
_______________________________________

From report at bugs.python.org  Mon Feb 15 22:23:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Feb 2016 03:23:29 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455593009.56.0.910690532139.issue15873@psf.upfronthosting.co.za>


Martin Panter added the comment:

It looks to me like you copied a lot of code, doc strings, tests, etc from <https://github.com/django/django/commit/9b1cb75#diff-4db1d116f25f482278090b122e3b0028> and <https://github.com/django/django/commit/2f59e94>. I wouldn?t call it trivial. There is a BSD license for Django. Or do we have to get the relevant authors to do the Python CLA thing?

The current patch seems to allow a timezone without a colon, or even without minutes (+1100 and +11 as well as the RFC?s +11:00). Is this needed? The colon was made optional in Django in <https://code.djangoproject.com/ticket/18728>; the argument given for this just seems to be ISO 8601 alignment, nothing practical. According to <https://code.djangoproject.com/ticket/22814> Postgre SQL outputs time zones without the minutes field, but I don?t know if Python should go out of its way to support this obscure format.

RFC 3339 does not specify single digits in many places (e.g. 2016-2-1 1:0:0 is not specified). Should we also be stricter, at least for the minutes and seconds fields?

Also, is it necessary to allow the seconds field to be omitted, as in "2016-02-01 01:21"?

It seems that the ?datetime? module does not support leap seconds, so if we mention RFC 3339 we should point out this inconsistency.

Victor: From my limited experiments, datetime.fromtimestamp() seems to use the round-to-even rule (not always rounding half up). Can you confirm? Maybe we should use that for consistency if it is practical. Otherwise, truncation towards zero would be the simplest.

As well as adding datetime.fromisoformat(), I think we should add similar methods to the separate date and time classes. One can parse the RFC?s full-date format fairly easily with strptime(), but not so for partial-time because of the fractional seconds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 23:23:15 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Feb 2016 04:23:15 +0000
Subject: [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <1455596595.26.0.549945012859.issue20169@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20169>
_______________________________________

From report at bugs.python.org  Mon Feb 15 23:26:58 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Tue, 16 Feb 2016 04:26:58 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455596818.72.0.961713561019.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

The real question is : should we accept whatever iso8601 format is common to be found on the internet, or just be able to consume back the string issued by isoformat. From that results the answers to the questions you're asking: don't accept single digits, neither second-less datetime, ...
I don't really mind what the answer is. I'm OK for a stricter acceptance. I would like to ask ourselves : does a simpler, stricter implementation fulfill people needs ? If it's OK for you, it's OK for me.

By taking the Django version, I deviated the bit from the author's original need which was just being able to parse back datetime isoformat. The limitations he raises for not using strptime are gone now (strptime understand timezone), but it still can't understand microseconds nor optional parts (T or space for separator, optional microseconds). Even for a much simpler, stricter implementation, I'd like to stick with regex.

I'll do a date & time version, I just wait that we fall agree on the whole datetime thing.

Wether we change to a simpler code or keep it this way, I can rewrite tests & docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 23:37:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Feb 2016 04:37:46 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455597466.73.0.135129098945.issue15873@psf.upfronthosting.co.za>


Martin Panter added the comment:

The regular expression r"\d" matches any digit in Unicode I think, not just ASCII digits 0-9. Perhaps we should limit it to ASCII digits. Or is it intended to allow non-ASCII digits like in "????-??-?? ??:??:??"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 15 23:41:42 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Tue, 16 Feb 2016 04:41:42 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1455597466.73.0.135129098945.issue15873@psf.upfronthosting.co.za>
Message-ID: <CAKJVQ89YgpzQErZR4NS2vv2eZyv2fL8eU5afBV5N1WniTEMayQ@mail.gmail.com>


Mathieu Dupuy added the comment:

Oh my god you're right. Thanks there is the re.ASCII flag.

2016-02-16 15:07 GMT+10:30 Martin Panter <report at bugs.python.org>:

>
> Martin Panter added the comment:
>
> The regular expression r"\d" matches any digit in Unicode I think, not
> just ASCII digits 0-9. Perhaps we should limit it to ASCII digits. Or is it
> intended to allow non-ASCII digits like in "????-??-?? ??:??:??"?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15873>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Tue Feb 16 00:00:41 2016
From: report at bugs.python.org (Ben Finney)
Date: Tue, 16 Feb 2016 05:00:41 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1455598841.55.0.140080274599.issue26362@psf.upfronthosting.co.za>


Ben Finney added the comment:

It has been pointed out that `tempfile.mktemp` does in fact access the filesystem, to query whether the entry exists.

So this request would be best met by exposing a simple ?get a new return value from the `tempfile._RandomNameSequence` instance? function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Tue Feb 16 00:32:30 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Tue, 16 Feb 2016 05:32:30 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455600750.97.0.168892862624.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

simpler version using a simpler, stricter regex

----------
Added file: http://bugs.python.org/file41934/simplerfromisoformat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Tue Feb 16 00:38:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Feb 2016 05:38:50 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock()
 doesn't shutdown request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455601130.37.0.0420506884782.issue26309@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes this patch looks pretty good, thanks

----------
title: socketserver.BaseServer._handle_request_noblock() don't shutdwon request if verify_request is False -> socketserver.BaseServer._handle_request_noblock() doesn't shutdown request if verify_request is False

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Tue Feb 16 00:53:53 2016
From: report at bugs.python.org (Ben Finney)
Date: Tue, 16 Feb 2016 05:53:53 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1455602033.68.0.493197345296.issue26362@psf.upfronthosting.co.za>


Ben Finney added the comment:

An example::

    import io
    import tempfile
    names = tempfile._get_candidate_names()

    def test_frobnicates_configured_spungfile():
        """ ?foo? should frobnicate the configured spungfile. """

        fake_file_path = os.path.join(tempfile.gettempdir(), names.next())
        fake_file = io.BytesIO("Lorem ipsum, dolor sit amet".encode("utf-8"))

        patch_builtins_open(
                when_accessing_path=fake_file_path,
                provide_file=fake_file)

        system_under_test.config.spungfile_path = fake_file_path
        system_under_test.foo()
        assert_correctly_frobnicated(fake_file)

With a supported standard library API for this ? ?tempfile.makepath?
for example ? the generation of the filesystem path would change from
four separate function calls::

    names = tempfile._get_candidate_names()
    fake_file_path = os.path.join(tempfile.gettempdir(), names.next())

to a simple function call::

    fake_file_path = tempfile.makepath()

and have the benefit of not reaching in to a private API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Tue Feb 16 02:38:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Feb 2016 07:38:00 +0000
Subject: [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <1455608280.6.0.514825898183.issue20169@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +georg.brandl
priority: low -> normal
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20169>
_______________________________________

From report at bugs.python.org  Tue Feb 16 02:44:12 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Tue, 16 Feb 2016 07:44:12 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455608652.66.0.862366706977.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

(OK, I said a stupidity:  datetime's strptime handle microseconds. But time's one doesn't)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Tue Feb 16 02:50:45 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Tue, 16 Feb 2016 07:50:45 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
In-Reply-To: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>
Message-ID: <1455609045.03.0.523815940967.issue23718@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

Actually there are already test cases, but they test for the wrong behaviour. The very same example is tested there, but the test gives the expected result, so tm_yday = -3. My implementation returns 362, which looks more reasonable. So currently with my patch the test fails.

See the tests here: https://github.com/python/cpython/blob/master/Lib/test/test_strptime.py#L523

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23718>
_______________________________________

From report at bugs.python.org  Tue Feb 16 03:09:42 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Feb 2016 08:09:42 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1455610182.98.0.496275276625.issue14597@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> My setup.py creates a .dll then later loads the dll for testing 
> using ctypes. Subsequent runs of setup.py that would force 
> rebuilding the .dll attempt to delete the old dll first if it 
> exists, but I get permission denied.
>
> Oddly, if I put the load library call inside a function, then, 
> after exiting the interpreter the dll can be deleted.

I'm having trouble imagining what the problem could be here. Can you attach a minimal example script that reproduces the problem?

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Tue Feb 16 04:02:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Feb 2016 09:02:50 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
In-Reply-To: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>
Message-ID: <1455613370.03.0.00794908424999.issue23718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide a patch? See also my comment on Rietveld (the "review" link).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23718>
_______________________________________

From report at bugs.python.org  Tue Feb 16 04:05:54 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Feb 2016 09:05:54 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1455613554.92.0.791058918113.issue14597@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The _ctypes extension module provides dlclose on POSIX and FreeLibrary on Windows. For the reasons already stated in this issue, ctypes should not automatically call these functions, but maybe they should be documented and imported to the ctypes module instead of being buried in the private _ctypes extension module. You could also implement them with ctypes itself, but the existing functions in the _ctypes module already set a proper exception if the call fails and properly use pointers (an HMODULE is a pointer).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Tue Feb 16 04:07:29 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Feb 2016 09:07:29 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1455613649.71.0.611182853258.issue14597@psf.upfronthosting.co.za>


Eryk Sun added the comment:

As to not being able to delete a loaded DLL on Windows, a workaround that may help in some instances is to rename it to a temporary name on the same volume. This is useful for upgrading in place. If you have admin privileges you can even flag the renamed DLL to be deleted when the system reboots:

    MoveFileExW(renamed_dll_path, NULL, MOVEFILE_DELAY_UNTIL_REBOOT)

Renaming a loaded DLL succeeds because the system opens the file with delete sharing, which allows renaming (i.e. relinking) an open file. 

To verify this, let's check the associated file object that's used by the mapping for python35.dll. We can see this in a local kernel debugging session. The following is in 64-bit Windows 7.

Attach to the Python process address space:

    lkd> .tlist python.exe
     0n2296 python.exe
    lkd> !process 0n2296 0
    Searching for Process with Cid == 8f8
    Cid handle table at fffff8a003506000 with 951 entries in use

    PROCESS fffffa800712fb10
        SessionId: 0  Cid: 08f8    Peb: 7fffffdf000  ParentCid: 02b8
        DirBase: 20780d000  ObjectTable: fffff8a0189fe1a0  HandleCount:  67.
        Image: python.exe

    lkd> .process /p /r 0xfffffa800712fb10 
    Implicit process is now fffffa80`0712fb10
    Loading User Symbols
    ...................................

Get the base address for python35.dll.

    lkd> lm m python35
    start             end                 module name
    00000000`66fb0000 00000000`67393000   python35   (deferred)

Get the associated Virtual Address Descriptor (VAD).

    lkd> !vad 66fb0000
    VAD             level  start  end    commit
    fffffa800855f230 (-1)  66fb0  67392  151 Mapped  Exe
                                         EXECUTE_WRITECOPY
                                         \Program Files\Python35\python35.dll

Get the File object reference from the associated control area.

    lkd> ?? ((nt!_MMVAD *)0xfffffa800855f230)->Subsection->ControlArea->FilePointer
    struct _EX_FAST_REF
       +0x000 Object           : 0xfffffa80`093f1503 Void
       +0x000 RefCnt           : 0y0011
       +0x000 Value            : 0xfffffa80`093f1503

The low nibble in the above address is information that needs to be masked out, so the address is actually 0xfffffa80`093f1500. Verify we have the correct file object by checking the filename.
       
    lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->FileName
    struct _UNICODE_STRING
     "\Program Files\Python35\python35.dll"
       +0x000 Length           : 0x48
       +0x002 MaximumLength    : 0x78
       +0x008 Buffer           : 0xfffff8a0`04b23690
                                 "\Program Files\Python35\python35.dll"

Finally, check the sharing mode. We see below that the file for a DLL mapping is loaded with read and delete sharing, but not write sharing.

    lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->SharedRead
    unsigned char 0x01 ''
    lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->SharedDelete
    unsigned char 0x01 ''
    lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->SharedWrite
    unsigned char 0x00 ''

Thus when deleting a DLL fails, it's not due to ERROR_SHARING_VIOLATION (32). The sharing mode would actually permit deleting the file. Instead the error is ERROR_ACCESS_DENIED (5), which results from the system call NtSetInformationFile returning STATUS_CANNOT_DELETE (0xC0000121), because the file currently has a mapped image or data section. But that doesn't stop us from renaming it to get it out of the way of an in-place upgrade.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Tue Feb 16 06:24:06 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Tue, 16 Feb 2016 11:24:06 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455621846.64.0.586285757271.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

OK, I know I post a lot, but this one should be the good one:
* recoded from scratch. Apart the algorithm, nothing come from Django anymore.
* help me fill the docstring, I'm not inspired
* datetime has few tests since it use the implementation of time._parse_time, which is heavily tested in time unittests.
* I now handle lowercase T and Z. (I know I could do "if tzinfo[0] in ('Z', 'z')", but to me it feel like imposing a micro performance penalty to implementation correctly sending an uppercase Z)

I'm impatient to receive your feedback.

----------
Added file: http://bugs.python.org/file41935/fromisoformat_new.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Tue Feb 16 06:48:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 16 Feb 2016 11:48:52 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455623332.14.0.638159999326.issue26366@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I agree with Georg and Ezio. We should update the devguide.

Tony, would you like to propose a patch? The repo is at https://hg.python.org/devguide

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Tue Feb 16 06:53:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 16 Feb 2016 11:53:11 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1455623591.92.0.928219306242.issue24911@psf.upfronthosting.co.za>


Berker Peksag added the comment:

socket-context.patch looks good to me. There is no need to add a NEWS entry for this.

----------
nosy: +berker.peksag
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Tue Feb 16 06:58:58 2016
From: report at bugs.python.org (Ben Spiller)
Date: Tue, 16 Feb 2016 11:58:58 +0000
Subject: [issue26369] doc for unicode.decode and str.encode is unnecessarily
 confusing
Message-ID: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>


New submission from Ben Spiller:

It's well known that lots of people struggle writing correct programs using non-ascii strings in python 2.x, but I think one of the main reasons for this could be very easily fixed with a small addition to the documentation for str.encode and unicode.decode, which is currently quite vague. 

The decode/encode methods really make most sense when called on a unicode string i.e. unicode.encode() to produce a byte string, or on a byte string e.g. str.decode() to produce a unicode object from a byte string. 

However, the additional presence of the opposite methods str.encode() and unicode.decode() is quite confusing, and a frequent source of errors - e.g. calling str.encode('utf-8') first DECODES the str object (which might already be in utf8) to a unicode string **using the default encoding of "ascii"** (!) before ENCODING to a utf-8 byte str as requested, which of course will fail at the first stage with the classic error "UnicodeDecodeError: 'ascii' codec can't decode byte" if there are any non-ascii chars present. It's unfortunate that this initial decode/encode stage ignores both the "encoding" argument (used only for the subsequent encode/decode) and the "errors" argument (commonly used when the programmer is happy with a best-effort conversion e.g. for logging purposes).

Anyway, given this behaviour, a lot of time would be saved by a simple sentence on the doc for str.encode()/unicode.decode() essentially warning people that those methods aren't that useful and they probably really intended to use str.decode()/unicode.encode() - the current doc gives absolutely no clue about this extra stage which ignores the input arguments and sues 'ascii' and 'strict'. It might also be worth stating in the documentation that the pattern (u.encode(encoding) if isinstance(u, unicode) else u) can be helpful for cases where you unavoidably have to deal with both kinds of input, string calling str.encode is such a bad idea. 

In an ideal world I'd love to see the implementation of str.encode/unicode.decode changed to be more useful (i.e. instead of using ascii, it would be more logical and useful to use the passed-in encoding to perform the initial decode/encode, and the apss-in 'errors' value). I wasn't sure if that change would be accepted so for now I'm proposing better documentation of the existing behaviour as a second-best.

----------
assignee: docs at python
components: Documentation
messages: 260359
nosy: benspiller, docs at python
priority: normal
severity: normal
status: open
title: doc for unicode.decode and str.encode is unnecessarily confusing
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Tue Feb 16 07:11:47 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Tue, 16 Feb 2016 12:11:47 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
In-Reply-To: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>
Message-ID: <1455624707.43.0.0998622655806.issue23718@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

I've added a new patch, it uses an other way to calculate the number of days in a given year. I updated the tests, so now it doesn't fail, I also added some extra test cases to test leap years.

----------
Added file: http://bugs.python.org/file41936/julian_date_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23718>
_______________________________________

From report at bugs.python.org  Tue Feb 16 08:01:38 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 16 Feb 2016 13:01:38 +0000
Subject: [issue26369] doc for unicode.decode and str.encode is unnecessarily
 confusing
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1455627698.41.0.52547652524.issue26369@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Perhaps you could suggest a specific change to the docstrings for str.encode and unicode.decode?

(BTW, I presume you are aware that the equivalent of (bytes)str.encode and unicode.decode are gone in Python 3?)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Tue Feb 16 08:32:03 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Feb 2016 13:32:03 +0000
Subject: [issue26369] doc for unicode.decode and str.encode is unnecessarily
 confusing
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1455629523.23.0.488829935348.issue26369@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Tue Feb 16 09:02:05 2016
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 16 Feb 2016 14:02:05 +0000
Subject: [issue26370] shelve filename inconsistent between platforms
Message-ID: <1455631325.94.0.590014562337.issue26370@psf.upfronthosting.co.za>


New submission from Dima Tisnek:

shelve.open("foo.db") creates "foo.db" on Linux and "foo.db.db" on OSX.


Something to that extent is even documented:
"""d = shelve.open(filename) # open, with (g)dbm filename -- no suffix"""
and
"""As a side-effect, an extension may be added to the filename and more than one file may be created."""


Still, it's super-quirky, it's almost as if the message was "don't use shelve."


Some ways out:
* ValueError if "." in basename(filaneme)  # a hammer
* ValueError if filename.endswith((".db", ".gdbm", ...))  # block only known extensions
* strip extension if it's known that underlying library is going to add it
* patch underlying library to always use filename verbatim

----------
components: Extension Modules
messages: 260362
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: shelve filename inconsistent between platforms
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26370>
_______________________________________

From report at bugs.python.org  Tue Feb 16 09:35:44 2016
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 16 Feb 2016 14:35:44 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1455633344.88.0.0498994862557.issue14597@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Tue Feb 16 11:03:12 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 16 Feb 2016 16:03:12 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1455638592.78.0.80397652742.issue24911@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

The patch looks good.  It would also be cool if you can add a short code snippet somewhere:

   sock = socket.socket()
   with sock:
      sock.bind(('127.0.0.1', 8080))
      sock.listen()
      ...

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Tue Feb 16 11:45:46 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 16 Feb 2016 16:45:46 +0000
Subject: [issue25713] Setuptools included with 64-bit Windows installer is
 outdated
In-Reply-To: <1448301960.52.0.82472871794.issue25713@psf.upfronthosting.co.za>
Message-ID: <1455641146.88.0.0246129462296.issue25713@psf.upfronthosting.co.za>


Paul Moore added the comment:

Just to clarify, it's intended that you simply "python -m pip install --upgrade pip setuptools" to get the latest version.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25713>
_______________________________________

From report at bugs.python.org  Tue Feb 16 13:14:02 2016
From: report at bugs.python.org (Mark Mikofski)
Date: Tue, 16 Feb 2016 18:14:02 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1455646442.94.0.571133870345.issue14597@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

Snippets of "proprietary" code

`setup.py`
----------
# run clean or build libraries if they don't exist
if 'clean' in sys.argv:
    try:
        os.remove(os.path.join(LIB_DIR, SOLPOSAM_LIB_FILE))
        os.remove(os.path.join(LIB_DIR, SPECTRL2_LIB_FILE))
    except OSError as err:
        sys.stderr.write('%s\n' % err)

`core.py`
---------
    # load the DLL
    solposAM_dll = ctypes.cdll.LoadLibrary(SOLPOSAMDLL)
    _solposAM = solposAM_dll.solposAM

After deleting files, setup.py tries to build, then runs test_cdlls.py a unittest that contains test_solposAM() that calls solposAM() and imports core.py that contains solposAM.

Case 1:
-------
I put the load library calls inside the function solposAM().
Function calls works as expected.
I am able to delete dlls after interpreter exits and restarts using os.remove()

Case 2:
-------
I put the load library calls at the module level.
Function calls works as expected.
If I try to delete dlls after interpreter exits and restarts using os.remove() I get access denied, but I can delete them from windows explorer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Tue Feb 16 13:19:16 2016
From: report at bugs.python.org (francisco)
Date: Tue, 16 Feb 2016 18:19:16 +0000
Subject: [issue13276] bdist_wininst-created installer does not run the
 postinstallation script when uninstalling
In-Reply-To: <1319729455.78.0.312367178712.issue13276@psf.upfronthosting.co.za>
Message-ID: <1455646756.51.0.94666680311.issue13276@psf.upfronthosting.co.za>


francisco added the comment:

I believe that this bug?which I reported in 2011?is not correctly tagged, what may explain why it has not been fixed yet. Despite the fact that the original issue report contains a script to reproduce the bug and that  msg148674 contains a patch to fix the issue the State of this issue is "test needed". Shouldn't State be "patch review" instead?

----------
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13276>
_______________________________________

From report at bugs.python.org  Tue Feb 16 14:03:57 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 16 Feb 2016 19:03:57 +0000
Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern
 object
In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za>
Message-ID: <1455649437.8.0.234133924817.issue26336@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26336>
_______________________________________

From report at bugs.python.org  Tue Feb 16 15:47:24 2016
From: report at bugs.python.org (NGG)
Date: Tue, 16 Feb 2016 20:47:24 +0000
Subject: [issue26371] asynchat.async_chat and asyncore.dispatcher_with_send
 are not thread-safe
Message-ID: <1455655644.91.0.36699489167.issue26371@psf.upfronthosting.co.za>


New submission from NGG:

The initiate_send() method in both asynchat.async_chat and asyncore.dispatcher_with_send is not a thread-safe function, but it can be called from multiple threads.

For example if asyncore.loop() runs in a background thread, and the main thread sends a message then both threads will call this.

It can result in sending (part of) the message multiple times or not sending part of it.

Possible solution:
asyncore.dispatcher_with_send.out_buffer and asynchat.async_chat.producer_fifo should be guarded with a lock (it should be locked even in writable())

----------
components: Library (Lib)
messages: 260367
nosy: ngg
priority: normal
severity: normal
status: open
title: asynchat.async_chat and asyncore.dispatcher_with_send are not thread-safe
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26371>
_______________________________________

From report at bugs.python.org  Tue Feb 16 15:53:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Feb 2016 20:53:59 +0000
Subject: [issue26371] asynchat.async_chat and asyncore.dispatcher_with_send
 are not thread-safe
In-Reply-To: <1455655644.91.0.36699489167.issue26371@psf.upfronthosting.co.za>
Message-ID: <1455656039.63.0.199873958124.issue26371@psf.upfronthosting.co.za>


STINNER Victor added the comment:

asynchat is now deprecated in favor of asyncio.

Almost all asyncio functions are not thread-safe, it's now well documented, see the general info:
https://docs.python.org/dev/library/asyncio-dev.html#concurrency-and-multithreading

If we do something, I suggest to only touch asynchat doc to explain well that asyncore and asynchat are not thread-safe.

----------
components: +asyncio
nosy: +gvanrossum, haypo, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26371>
_______________________________________

From report at bugs.python.org  Tue Feb 16 15:58:05 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 16 Feb 2016 20:58:05 +0000
Subject: [issue26371] asynchat.async_chat and asyncore.dispatcher_with_send
 are not thread-safe
In-Reply-To: <1455655644.91.0.36699489167.issue26371@psf.upfronthosting.co.za>
Message-ID: <1455656285.94.0.0712584079937.issue26371@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't believe the original issue is a bug. There is nothing in the docs for asyncore or asynchat that suggests they would be thread-safe.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26371>
_______________________________________

From report at bugs.python.org  Tue Feb 16 18:03:40 2016
From: report at bugs.python.org (Nathan West)
Date: Tue, 16 Feb 2016 23:03:40 +0000
Subject: [issue25671] Fix venv activate.fish to maintain $status
In-Reply-To: <1447946690.19.0.336666934208.issue25671@psf.upfronthosting.co.za>
Message-ID: <1455663820.81.0.889701599729.issue25671@psf.upfronthosting.co.za>


Nathan West added the comment:

Not quite, no. The issue looks like this:

    user at host ~/test> python3 -mvenv env
    user at host ~/test> true
    user at host ~/test> false
    user at host ~/test [1]> source env/bin/activate.fish 
    (env) user at host ~/test> true
    (env) user at host ~/test> false
    (env) user at host ~/test> deactivate
    user at host ~/test> true
    user at host ~/test> false
    user at host ~/test [1]>

Notice that, after running the `false` command the first time, the command prompt includes a "[1]", indicating the exit status of the `false` command. However, after activating the virtual environment, the command prompt no longer shows the error code from the `false` command. After deactivating the virtualenv, the command prompt once again displays the error code from `false`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25671>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:19:45 2016
From: report at bugs.python.org (Manuel Jacob)
Date: Wed, 17 Feb 2016 00:19:45 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455668385.32.0.807391747488.issue26367@psf.upfronthosting.co.za>


Changes by Manuel Jacob <me at manueljacob.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file41937/relimport-3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:20:00 2016
From: report at bugs.python.org (Manuel Jacob)
Date: Wed, 17 Feb 2016 00:20:00 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455668400.68.0.238170532452.issue26367@psf.upfronthosting.co.za>


Changes by Manuel Jacob <me at manueljacob.de>:


Added file: http://bugs.python.org/file41938/relimport-3.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:22:40 2016
From: report at bugs.python.org (Frederick Wagner)
Date: Wed, 17 Feb 2016 00:22:40 +0000
Subject: [issue26347] BoundArguments.apply_defaults doesn't handle empty
 arguments
In-Reply-To: <1455247989.9.0.159596346531.issue26347@psf.upfronthosting.co.za>
Message-ID: <1455668560.49.0.753442572101.issue26347@psf.upfronthosting.co.za>


Frederick Wagner added the comment:

All right, looks like I have the asterisk now! Looking forward to officially contributing to the Python standard library :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26347>
_______________________________________

From report at bugs.python.org  Tue Feb 16 20:19:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 01:19:41 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455671981.72.0.731161022645.issue26360@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Tue Feb 16 20:26:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 01:26:35 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455672395.7.0.83530609902.issue26360@psf.upfronthosting.co.za>


STINNER Victor added the comment:

debug-build-stacktrace.txt:
* Thread 1 is waiting on threading_hang.py:21: thread.join()
* Thread 2-6 (5 threads) are waiting for the GIL

The thread 1 is not supposed to hold the GIL: thread.join() is implemented by lock_PyThread_acquire_lock() at Modules/threadmodule.c:52:

    Py_BEGIN_ALLOW_THREADS
    i = PyThread_acquire_lock(self->lock_lock, i);
    Py_END_ALLOW_THREADS

Note: I backported enhancements of python-gdb.py from Python 3, but I'm not sure that "Waiting for the GIL" line is reliable :-/ I recall vaguely a technical issue specific to Python 2 to check if a thread is waiting on the GIL or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Tue Feb 16 20:28:32 2016
From: report at bugs.python.org (Memeplex)
Date: Wed, 17 Feb 2016 01:28:32 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
Message-ID: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>


New submission from Memeplex:

When not using a timeout, communicate will raise a BrokenPipeError if the command returns an error code. For example:

sp = subprocess.Popen('cat --not-an-option', shell=True, stdin=subprocess.PIPE)
time.sleep(.2)
sp.communicate(b'hi\n')

This isn't consistent with the behavior of communicate with a timeout, which doesn't raise the  exception. Moreover, there is even a comment near the point of the exception stating that communicate must ignore BrokenPipeError:

    def _stdin_write(self, input):
        if input:
            try:
                self.stdin.write(input)
            except BrokenPipeError:
                # communicate() must ignore broken pipe error
                pass
            ....
        self.stdin.close()

Obviously, the problem is that self.stdin.close() is outside the except clause.

----------
components: Library (Lib)
messages: 260373
nosy: memeplex
priority: normal
severity: normal
status: open
title: Popen.communicate not ignoring BrokenPipeError
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Tue Feb 16 20:33:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 01:33:15 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455672795.76.0.457587665916.issue26360@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I've also not yet managed to reproduce on Python 3, but I haven't tried that hard. I suspect it's a Python 2-only problem, though.

Python 3.2 got a new GIL and many bugs related to the GIL were fixed in Python 3 too.

The "workaround" is to use Python 3, until this Python 2 issue is fixed (if we are able to fix it!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Tue Feb 16 20:46:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 01:46:41 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455673601.78.0.559899368996.issue26360@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>> lock=0x0 looks suspicious.

> Agreed. I think that *could* possibly be a consequence of the earlier multiple GILs, though I haven't figured out exactly how yet.

Don't trust gdb output when Python is compiled in release mode (with -O3).

gdb output is only reliable when Python is compiled with -O0 (./configure --with-pydebug is enough for Python 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Tue Feb 16 21:56:22 2016
From: report at bugs.python.org (Zach Byrne)
Date: Wed, 17 Feb 2016 02:56:22 +0000
Subject: [issue26280] ceval: Optimize list[int] (subscript) operation
 similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1455677782.95.0.783098600171.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

Here's a patch that looks likes Victor's from the duplicate, but with tuples covered as well. I ran some straight forward micro benchmarks but haven't bothered running the benchmark suite yet. Unsurprisingly, optimized paths are faster, and the others take a penalty.

[0]byrnez at byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = [1,2,3,4,5,6]" "l[3]"
10000000 loops, best of 3: 0.0306 usec per loop
[0]byrnez at byrnez-laptop:~/git/python$ ./python -m timeit -s "l = [1,2,3,4,5,6]" "l[3]"
10000000 loops, best of 3: 0.0243 usec per loop

[0]byrnez at byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = (1,2,3,4,5,6)" "l[3]"
10000000 loops, best of 3: 0.0291 usec per loop
[0]byrnez at byrnez-laptop:~/git/python$ ./python -m timeit -s "l = (1,2,3,4,5,6)" "l[3]"
10000000 loops, best of 3: 0.0241 usec per loop

[0]byrnez at byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = 'asdfasdf'" "l[3]"
10000000 loops, best of 3: 0.034 usec per loop
[0]byrnez at byrnez-laptop:~/git/python$ ./python -m timeit -s "l = 'asdfasdf'" "l[3]"
10000000 loops, best of 3: 0.0366 usec per loop

[0]byrnez at byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = [1,2,3,4,5,6]" "l[:3]"
10000000 loops, best of 3: 0.124 usec per loop
[0]byrnez at byrnez-laptop:~/git/python$ ./python -m timeit -s "l = [1,2,3,4,5,6]" "l[:3]"
10000000 loops, best of 3: 0.125 usec per loop

----------
Added file: http://bugs.python.org/file41939/subscr1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26280>
_______________________________________

From report at bugs.python.org  Wed Feb 17 02:07:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 07:07:21 +0000
Subject: [issue26280] ceval: Optimize list
In-Reply-To: <1455677782.95.0.783098600171.issue26280@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZH3ZwgiROL=_igvWDzOBJMORmTvpcm5WtALhXXTGBCEQ@mail.gmail.com>


STINNER Victor added the comment:

I suggest to try to inline PyList_GetItem: use PyList_GET_ITEM and raise
the exception manually if needed.

I'm not sure that it's ok to add PyLong_AsSize_t() to the slow path. Copy
the code in each if? A macro can help.

----------
title: ceval: Optimize list[int] (subscript) operation similarly to CPython 2.7 -> ceval: Optimize list

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26280>
_______________________________________

From report at bugs.python.org  Wed Feb 17 02:14:03 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Feb 2016 07:14:03 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455693243.88.0.237339622964.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I'm not sure that "Waiting for the GIL" line is reliable

Right; I was interpreting that line more as "I don't have the GIL at the moment", which I think applies to all threads, including the main thread. It's pretty clear that threads 2-5 really are waiting for the GIL, and (as you point out), for thread 1 to be where it is, it must have also released the GIL by that point.

Agreed about the gdb results for the -O3 build.

So it looks as though something's gone wrong with the "I've just released the GIL; now someone else can pick it up" signaling mechanism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Wed Feb 17 03:14:14 2016
From: report at bugs.python.org (Florian Bruhin)
Date: Wed, 17 Feb 2016 08:14:14 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1455696854.05.0.88902455921.issue22836@psf.upfronthosting.co.za>


Florian Bruhin added the comment:

I just got bitten by this again - is anything holding this back from being merged (other than lack of review-manpower)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Wed Feb 17 03:25:17 2016
From: report at bugs.python.org (NGG)
Date: Wed, 17 Feb 2016 08:25:17 +0000
Subject: [issue26371] asynchat.async_chat and asyncore.dispatcher_with_send
 are not thread-safe
In-Reply-To: <1455655644.91.0.36699489167.issue26371@psf.upfronthosting.co.za>
Message-ID: <1455697517.62.0.31523339154.issue26371@psf.upfronthosting.co.za>


NGG added the comment:

If I want to write a TCP client which communicates back and forth with the server (both parties can send messages anytime) then it would be really easy to use it the following way:
Start a background thread with asyncore.loop(), and you can send messages easily, and handle_read() will be called automatically whenever data is received.
If this usage is not supported and I understand correctly then I can only send messages before starting the loop or callbacks from the loop (handle_accept, handle_read, etc).
This seems to be a much more difficult and error-prone way (at least for pre-Future python versions)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26371>
_______________________________________

From report at bugs.python.org  Wed Feb 17 04:07:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 09:07:39 +0000
Subject: [issue26371] asynchat.async_chat and asyncore.dispatcher_with_send
 are not thread-safe
In-Reply-To: <1455655644.91.0.36699489167.issue26371@psf.upfronthosting.co.za>
Message-ID: <1455700059.27.0.514907630837.issue26371@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"If this usage is not supported (...)"

You can use threads, but access concurrently asyncore/asynchat from different threads. You have to build a communicate channel between your threads using thread-safe primitive like queue.Queue. asyncio has a builtin support for that: loop.call_soon_threadsafe().

Why not using asyncio instead of having to rebuild your own implementation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26371>
_______________________________________

From report at bugs.python.org  Wed Feb 17 04:15:19 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Wed, 17 Feb 2016 09:15:19 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455700519.49.0.358399643101.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

Crap, I just checked spams today and almost all mails of the reviewboard landed in spams ! So I made a new patch addressing all concerns:

* regex moved closer to where they're used
* regex globals start with an _
* case insensitive regex + handling(already handled in the previous revision)
* correct rounding + case suggested by Martin added as a test case
* more precise docstrings specifying that only a subset of ISO 8601 is accepted

bonus:
* useless non-capturing groups removed in regex, thus shorter and simpler

I still have a doubt though about the place I moved the regex. Tell me.

----------
Added file: http://bugs.python.org/file41940/fromisoformat_new2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Feb 17 04:16:49 2016
From: report at bugs.python.org (NGG)
Date: Wed, 17 Feb 2016 09:16:49 +0000
Subject: [issue26371] asynchat.async_chat and asyncore.dispatcher_with_send
 are not thread-safe
In-Reply-To: <1455655644.91.0.36699489167.issue26371@psf.upfronthosting.co.za>
Message-ID: <1455700609.09.0.880711209802.issue26371@psf.upfronthosting.co.za>


NGG added the comment:

"Why not using asyncio instead of having to rebuild your own implementation?"

The issue happened with python 2.7 and we don't want that project to depend on additional libraries.
I think we will upgrade that project to python3 soon and will probably use asyncio then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26371>
_______________________________________

From report at bugs.python.org  Wed Feb 17 04:18:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 09:18:24 +0000
Subject: [issue26371] asynchat.async_chat and asyncore.dispatcher_with_send
 are not thread-safe
In-Reply-To: <1455655644.91.0.36699489167.issue26371@psf.upfronthosting.co.za>
Message-ID: <1455700703.99.0.540741691796.issue26371@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"I think we will upgrade that project to python3 soon and will probably use asyncio then."

Great :-) You may have a look at my https://pypi.python.org/pypi/sixer project, it may help :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26371>
_______________________________________

From report at bugs.python.org  Wed Feb 17 05:11:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 17 Feb 2016 10:11:35 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1455703895.45.0.122614542622.issue22836@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes a review would help. Also, I suspect this will require a separate patch for Python 2. When I get a chance I will have another look at this and see if I am comfortable committing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Wed Feb 17 05:40:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 10:40:50 +0000
Subject: [issue26360] Deadlock in thread.join
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455705650.07.0.864029815563.issue26360@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Each iteration takes around 60 seconds, and I typically get a deadlock within the first 5 iterations."

I ran a modified version of threading_hang.py (I added some debug print) a whole night: it's still running after 118 iterations.

Each iteration takes ~5 minutes, I'm using a debug build of Python 2.7 on Linux (Fedora 23).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Wed Feb 17 05:42:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 10:42:59 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455705779.2.0.105286476143.issue26360@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Deadlock in thread.join -> Deadlock in thread.join on Python 2.7/Mac OS X 10.9

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Wed Feb 17 05:51:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 17 Feb 2016 10:51:41 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455706301.58.0.506134108155.issue26372@psf.upfronthosting.co.za>


Martin Panter added the comment:

Seems a reasonable proposal to me. Originally the bufsize parameter defaulted to 0 so this wouldn?t have been such a problem. Explicitly setting bufsize=0 should be a decent workaround.

----------
nosy: +martin.panter
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:01:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 17 Feb 2016 11:01:51 +0000
Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly
In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za>
Message-ID: <1455706911.66.0.74231830508.issue25738@psf.upfronthosting.co.za>


Martin Panter added the comment:

Mathieu:  What code are you suggesting to delete? The handling of NO_CONTENT etc? That could potentially break people?s code, and I don?t see the harm in leaving it as it is. I would prefer to either bless it in the documentation, or deprecate it if there is a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25738>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:14:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 11:14:25 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455707665.41.0.185832548225.issue26372@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This isn't consistent with the behavior of communicate with a timeout

Right, it looks like BrokenPipeError on writing into stdin is ignored in some cases, but not in all cases.

Attached patch for Python 3.6 adds two try/except BrokenPipeError with two unit tests.

It looks like Python 2.7 has a similar bug: stdin.close() is not surrounded by try/except BrokenPipeError.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:14:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 11:14:53 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455707693.98.0.7959982489.issue26372@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Explicitly setting bufsize=0 should be a decent workaround.

It kills performances, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:16:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 11:16:48 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455707808.67.0.748158463194.issue26372@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like asyncio.subprocess has a similar issue in Process._feed_stdin, but I'm not sure that stdin.close() can trigger BrokenPipeError. Well, it wouldn't hurd to protect stdin.close() with a try/except BrokenPipeError too ;-)

----------
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:17:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 11:17:13 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455707833.11.0.318206873471.issue26372@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +asyncio
nosy: +gvanrossum, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:17:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 11:17:21 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455707841.61.0.926830764255.issue26372@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file41941/broken_pipe_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:25:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 11:25:01 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1455708301.04.0.952164054205.issue24911@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed the patch.

> It would also be cool if you can add a short code snippet somewhere:

The socket module has examples.

Why not modifying these examples to promote the context manager protocol?

Example:
--------
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s
# use with to ensure that the socket is closed, especially on error
with s:
  s.bind((HOST, PORT))
  s.listen(1)
  conn, addr = s.accept()
  with conn:
    print('Connected by', addr)
    while True:
        data = conn.recv(1024)
        if not data: break
        conn.sendall(data)
    conn.close()
--------

The second "with conn:" is maybe overkill. What do you think?

For a client connection, usually I prefer to explicitly close the socket (even if I use "with conn:") to get exception on my ".close()" line, instead of getting an exception from the context manager, which is harder to understand.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:30:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 11:30:21 +0000
Subject: [issue26373] asyncio: add support for async context manager on
 streams?
Message-ID: <1455708621.94.0.460576626878.issue26373@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While working on the issue #24911 (Context manager of socket.socket is not documented), I recalled that asyncio objects don't support context manager. With the PEP 492, it becomes possible to add support for async context manager for a few asyncio objects. I suggest to start with StreamWriter.

Usually, my rationale to decide which object should implement context manager is to check if the destructor can emit ResourceWarning.

In asyncio, ResourceWarning is now emitted by transport and event loop destructors:
https://docs.python.org/dev/library/asyncio-dev.html#close-transports-and-event-loops

----------
components: asyncio
messages: 260394
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: add support for async context manager on streams?
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26373>
_______________________________________

From report at bugs.python.org  Wed Feb 17 06:47:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Feb 2016 11:47:07 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1455709627.41.0.586590888935.issue22836@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This may be a part of more general issue. Should repr() fail at all? Wouldn't be better to fall back to the default __repr__ instead? repr() is typically used for debugging. Failing repr() can be a part of larger __repr__, thus raising an exception in subobject's repr() leads to the loss of information about full object.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Wed Feb 17 07:26:30 2016
From: report at bugs.python.org (F.D. Sacerdoti)
Date: Wed, 17 Feb 2016 12:26:30 +0000
Subject: [issue26374] concurrent_futures Executor.map semantics better
 specified in docs
Message-ID: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>


New submission from F.D. Sacerdoti:

Hello,

My colleague and I have both written parallel executors for the concurrent_futures module, and are having an argument, as described in the dialog below. To resolve, I would like to add "order of results is undefined" to disambiguate the docs for "map(func, *iterables, timeout=None)".

DISCUSSION

Q: Correct Semantics to return results out of order?
JH: No, breaks API as stated
Rebut: order is undefined, concurrent_futures specifies map() returns an iterator, where builtin map returns a list. 
Q: Does it break the spirit of the module?
A: No, I believe one of the best things about doing things async is the dataflow model: do the next thing as soon as its inputs are ready.
 Q: Should we hold up the caller in all cases when there are stragglers, i.e. elements that compute slower?
 A: No, the interface should allow both modes.

def james_map(exe, fn, *args):
  return iter( sorted( list( exe.map( fn, *args ) ) ) )

----------
messages: 260396
nosy: F.D. Sacerdoti
priority: normal
severity: normal
status: open
title: concurrent_futures Executor.map semantics better specified in docs
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26374>
_______________________________________

From report at bugs.python.org  Wed Feb 17 07:39:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Feb 2016 12:39:37 +0000
Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern
 object
In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za>
Message-ID: <1455712777.69.0.66911608829.issue26336@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Regex bytecode is implementation detail. It was 16-bit in narrow builds, but was changed to at least 32-bit in bugfix releases. It can be changed to 64-bit or to pack an argument with an opcode in one word. The implementation can not use the bytecode at all, but use the tree instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26336>
_______________________________________

From report at bugs.python.org  Wed Feb 17 08:39:17 2016
From: report at bugs.python.org (Michal Niklas)
Date: Wed, 17 Feb 2016 13:39:17 +0000
Subject: [issue26375] New versions of Python hangs on imaplib.IMAP4_SSL()
Message-ID: <1455716357.67.0.858374272161.issue26375@psf.upfronthosting.co.za>


New submission from Michal Niklas:

I have application that import emails from client IMAP4 mailboxes on home.pl (I think it is popular provider in Poland). It worked very well up to Python 2.7.9 but with version 2.7.10 it hangs on read() in imaplib.IMAP4_SSL().

On my Fedora 23 I have Python 3.4.3 and 2.7.10.

With Python 3.4.3 such code works as expected:

	[mn] python3 -c "import imaplib; x=imaplib.IMAP4_SSL('imap.home.pl', 993); print('finish', x)"
	finish <imaplib.IMAP4_SSL object at 0x7f80cfd31710>

But with Python 2.7.10 it hangs. I pressed Ctrl-C after few seconds:

	[mn] python -c "import imaplib; x=imaplib.IMAP4_SSL('imap.home.pl', 993); print('finish', x)"
	^CTraceback (most recent call last):
	  File "<string>", line 1, in <module>
	  File "/usr/lib64/python2.7/imaplib.py", line 1166, in __init__
		IMAP4.__init__(self, host, port)
	  File "/usr/lib64/python2.7/imaplib.py", line 202, in __init__
		typ, dat = self.capability()
	  File "/usr/lib64/python2.7/imaplib.py", line 374, in capability
		typ, dat = self._simple_command(name)
	  File "/usr/lib64/python2.7/imaplib.py", line 1088, in _simple_command
		return self._command_complete(name, self._command(name, *args))
	  File "/usr/lib64/python2.7/imaplib.py", line 910, in _command_complete
		typ, data = self._get_tagged_response(tag)
	  File "/usr/lib64/python2.7/imaplib.py", line 1017, in _get_tagged_response
		self._get_response()
	  File "/usr/lib64/python2.7/imaplib.py", line 929, in _get_response
		resp = self._get_line()
	  File "/usr/lib64/python2.7/imaplib.py", line 1027, in _get_line
		line = self.readline()
	  File "/usr/lib64/python2.7/imaplib.py", line 1189, in readline
		return self.file.readline()
	  File "/usr/lib64/python2.7/socket.py", line 451, in readline
		data = self._sock.recv(self._rbufsize)
	  File "/usr/lib64/python2.7/ssl.py", line 734, in recv
		return self.read(buflen)
	  File "/usr/lib64/python2.7/ssl.py", line 621, in read
		v = self._sslobj.read(len or 1024)
	KeyboardInterrupt

You can also test it with docker to see that it worked with older versions of Python:

	[mn] sudo docker run --rm -it python:2.7.9 python -c "import imaplib; x=imaplib.IMAP4_SSL('imap.home.pl', 993); print('finish', x)"
	('finish', <imaplib.IMAP4_SSL instance at 0x7f682422b2d8>)

	[mn] sudo docker run --rm -it python:2.7.10 python -c "import imaplib; x=imaplib.IMAP4_SSL('imap.home.pl', 993); print('finish', x)"
	^CTraceback (most recent call last):
	  File "<string>", line 1, in <module>
	  File "/usr/local/lib/python2.7/imaplib.py", line 1166, in __init__
		IMAP4.__init__(self, host, port)
	  File "/usr/local/lib/python2.7/imaplib.py", line 202, in __init__
		typ, dat = self.capability()
	  File "/usr/local/lib/python2.7/imaplib.py", line 374, in capability
		typ, dat = self._simple_command(name)
	  File "/usr/local/lib/python2.7/imaplib.py", line 1088, in _simple_command
		return self._command_complete(name, self._command(name, *args))
	  File "/usr/local/lib/python2.7/imaplib.py", line 910, in _command_complete
		typ, data = self._get_tagged_response(tag)
	  File "/usr/local/lib/python2.7/imaplib.py", line 1017, in _get_tagged_response
		self._get_response()
	  File "/usr/local/lib/python2.7/imaplib.py", line 929, in _get_response
		resp = self._get_line()
	  File "/usr/local/lib/python2.7/imaplib.py", line 1027, in _get_line
		line = self.readline()
	  File "/usr/local/lib/python2.7/imaplib.py", line 1189, in readline
		return self.file.readline()
	  File "/usr/local/lib/python2.7/socket.py", line 451, in readline
		data = self._sock.recv(self._rbufsize)
	  File "/usr/local/lib/python2.7/ssl.py", line 734, in recv
		return self.read(buflen)
	  File "/usr/local/lib/python2.7/ssl.py", line 621, in read
		v = self._sslobj.read(len or 1024)
	KeyboardInterrupt

The same way I tested that it hangs with Python 3.4.4.

I think it is a bug because it hangs instead of raising an exception with helpful information.
Maybe it is caused by removing RC4 cipher from new versions of Python?

How can I workaround this problem?

----------
messages: 260398
nosy: mniklas
priority: normal
severity: normal
status: open
title: New versions of Python hangs on imaplib.IMAP4_SSL()
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26375>
_______________________________________

From report at bugs.python.org  Wed Feb 17 09:05:24 2016
From: report at bugs.python.org (Anish Shah)
Date: Wed, 17 Feb 2016 14:05:24 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1455717924.3.0.0573275298312.issue26302@psf.upfronthosting.co.za>


Anish Shah added the comment:

Is this patch ready to merge?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26302>
_______________________________________

From report at bugs.python.org  Wed Feb 17 10:00:45 2016
From: report at bugs.python.org (Sam Yeager)
Date: Wed, 17 Feb 2016 15:00:45 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
Message-ID: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>


New submission from Sam Yeager:

Using the following code, the root window will not close properly when the close icon is clicked:

from tkinter import *
rootWin = Tk()
l = Label(rootWin, text="foo")
l.pack()

Similar issue occurs with Tk.grid().


OS: Mac OS X 10.10.5
Python IDE: IDLE 3.4.4
tkinter.TkVersion: 8.5
tkinter.TclVersion: 8.5
ActiveTcl: 8.6.4

----------
components: IDLE, Macintosh, Tkinter
files: Screen Shot 2016-02-17 at 10.00.21 AM.png
messages: 260400
nosy: Sam Yeager, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Tkinter root window won't close if packed.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41942/Screen Shot 2016-02-17 at 10.00.21 AM.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Wed Feb 17 10:01:48 2016
From: report at bugs.python.org (Sam Yeager)
Date: Wed, 17 Feb 2016 15:01:48 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1455721308.39.0.78998688337.issue26376@psf.upfronthosting.co.za>


Changes by Sam Yeager <samyeager at gmail.com>:


Removed file: http://bugs.python.org/file41942/Screen Shot 2016-02-17 at 10.00.21 AM.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Wed Feb 17 10:07:00 2016
From: report at bugs.python.org (Sam Yeager)
Date: Wed, 17 Feb 2016 15:07:00 +0000
Subject: [issue26377] Tkinter dialogs will not close if root window not packed.
Message-ID: <1455721620.42.0.0590186130956.issue26377@psf.upfronthosting.co.za>


New submission from Sam Yeager:

Using the following code, the messagebox will not close, leaving it on top of all other open windows:

from tkinter import *
rootWin = Tk()
messagebox.showinfo("Title", "foo")


If the root window contains a widget (Label, Entry, Button, etc.), the dialog can close.
Similar results have been obtained with filedialog. 

OS: Mac OS X 10.10.5
Python IDE: IDLE 3.4.4
tkinter.TkVersion: 8.5
tkinter.TclVersion: 8.5
ActiveTcl: 8.6.4

----------
components: IDLE, Macintosh, Tkinter
messages: 260401
nosy: Sam Yeager, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Tkinter dialogs will not close if root window not packed.
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26377>
_______________________________________

From report at bugs.python.org  Wed Feb 17 11:07:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Feb 2016 16:07:54 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1455725274.64.0.0821467821927.issue26376@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What do you mean with "properly"? All looks good to me on Linux.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Wed Feb 17 12:07:50 2016
From: report at bugs.python.org (Akira Li)
Date: Wed, 17 Feb 2016 17:07:50 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1455728870.07.0.0684992618726.issue23570@psf.upfronthosting.co.za>


Akira Li added the comment:

Should this issue be reopened in light of
http://bugs.python.org/issue26372 (Popen.communicate not ignoring
BrokenPipeError)?

If .close() shouldn't raise BrokenPipeError in .communicate() (and it
shouldn't) then it seems logical that .close() shouldn't raise
BrokenPipeError in .__exit__() too (and in other subprocess.Popen
methods that do not return until the child process is dead such as
subprocess.run())

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23570>
_______________________________________

From report at bugs.python.org  Wed Feb 17 12:21:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 17:21:23 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1455729683.9.0.29979268639.issue23570@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Should this issue be reopened in light of http://bugs.python.org/issue26372 (Popen.communicate not ignoring BrokenPipeError)?"

I don't like reopen old issues. IMHO the two issues are different enough to justify two entries in the bug tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23570>
_______________________________________

From report at bugs.python.org  Wed Feb 17 12:21:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 17:21:43 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455729703.62.0.315280555438.issue26372@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #23570: Change "with subprocess.Popen():" (context manager) to ignore broken pipe error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 12:29:03 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Feb 2016 17:29:03 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455730143.4.0.0251373750285.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks for testing! It wouldn't entirely surprise me if this turned out to be an Apple bug somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Wed Feb 17 12:39:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 17:39:37 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455730777.02.0.602572130026.issue26360@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Thanks for testing! It wouldn't entirely surprise me if this turned out to be an Apple bug somewhere.

I'm ran threading_hang.py on Mac OS X 10.10 Yosemite (darwin 14.5) on Python 2.7 compiled in release mode.

After 28 iterations (~4 hours, 9 minutes per iteration), the bug was still not reproduced.

It looks like my OS X version is more recent than yours. You should run your test on various OS X versions to try to identify the bug.

Since it's likely a race condition, I would not be surprised that the bug is very hard to reproduce and may exist on other platforms, but may be less likely on other platforms or even less likely on some computers for various reasons...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Wed Feb 17 14:44:31 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Feb 2016 19:44:31 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455738271.98.0.139654246635.issue26367@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Wed Feb 17 15:24:04 2016
From: report at bugs.python.org (Jonathan Goble)
Date: Wed, 17 Feb 2016 20:24:04 +0000
Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern
 object
In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za>
Message-ID: <1455740644.12.0.830850709222.issue26336@psf.upfronthosting.co.za>


Jonathan Goble added the comment:

It would indeed be marked as a CPython implementation detail, and with no guarantee of backward compatibility. Others (well, at least one other) have suggested the same on python-ideas. So a simple note in the accompanying documentation would suffice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26336>
_______________________________________

From report at bugs.python.org  Wed Feb 17 16:05:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 21:05:38 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455743138.17.0.651013404423.issue26323@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If we go into this direction, I suggest to add *two* methods:

* assert_called(): called at least once
* assert_called_once(): called exactly once

I would be more consitent with the existing API:

https://docs.python.org/dev/library/unittest.mock.html#unittest.mock.Mock.assert_not_called

https://docs.python.org/dev/library/unittest.mock.html#unittest.mock.Mock.assert_called_with

https://docs.python.org/dev/library/unittest.mock.html#unittest.mock.Mock.assert_called_once_with

----------
nosy: +haypo, rbcollins
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Wed Feb 17 16:06:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Feb 2016 21:06:53 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455743213.58.0.610174968657.issue26323@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I would be more consitent with the existing API:

Hum, I'm not sure that I was clear.

If we only add assert_called() (without assert_called_once()), users may use assert_called() to check if a function is called exactly once which would be a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Wed Feb 17 16:43:04 2016
From: report at bugs.python.org (David Rager)
Date: Wed, 17 Feb 2016 21:43:04 +0000
Subject: [issue26378] Typo in regex documentation
Message-ID: <1455745384.28.0.629898893574.issue26378@psf.upfronthosting.co.za>


New submission from David Rager:

In the following sentence, "few" should probably be "fewer."

"Repetitions such as * are greedy; when repeating a RE, the matching engine will try to repeat it as many times as possible. If later portions of the pattern don?t match, the matching engine will then back up and try again with few repetitions."

https://docs.python.org/2/howto/regex.html

Thanks for such a great language and documentation!  My apologies if this isn't actually a typo.

----------
assignee: docs at python
components: Documentation
messages: 260411
nosy: David Rager, docs at python
priority: normal
severity: normal
status: open
title: Typo in regex documentation
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26378>
_______________________________________

From report at bugs.python.org  Wed Feb 17 17:47:50 2016
From: report at bugs.python.org (Amit Saha)
Date: Wed, 17 Feb 2016 22:47:50 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455749270.06.0.676662671414.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Thanks for your comments. I am +1 to those additions and would be happy to update the patch. Let me know if I should go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Wed Feb 17 18:18:40 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Feb 2016 23:18:40 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <8F80E581-B652-43B4-995B-94BB7DD911F7@python.org>


Ned Deily added the comment:

Also note that installing ActiveTcl 8.6.x has no effect if the tkinter in use was linked with an 8.5 version of Tcl/Tk, as the one you are using apparently was. Make sure you have installed the latest version of ActiveTcl 8.5.x and try again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:05:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 00:05:17 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455753917.06.0.299630992022.issue26372@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looking over the code for communicate(), I think setting bufsize=0 should not cause a performance problem in the original use case. Communicate() either calls stdin.write() once, or bypasses the file object and calls os.write(). Only if stdin, stdout, etc were used before communicate(), then there could be a problem (and subtly different behaviour).

I left some suggestions on the code review.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:08:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Feb 2016 00:08:38 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455753917.06.0.299630992022.issue26372@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYE=rWZyvfMLb2NC1CiUHCyV43iKWBvA4kQ9Fo2R4ovvw@mail.gmail.com>


STINNER Victor added the comment:

bufsize impacts all streams, no only stdin, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:14:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 00:14:03 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
 communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1455754443.72.0.143506103937.issue10963@psf.upfronthosting.co.za>


Martin Panter added the comment:

FTR Issue 26372 has been opened about Serhiy?s bug with stdin.close() raising EPIPE.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10963>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:18:27 2016
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBEdm/FmcOhaw==?=)
Date: Thu, 18 Feb 2016 00:18:27 +0000
Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows
 xp
In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za>
Message-ID: <1455754707.49.0.253888775641.issue20010@psf.upfronthosting.co.za>


Changes by V?clav Dvo??k <vashek at gmail.com>:


----------
nosy: +V?clav Dvo??k

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20010>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:32:23 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 18 Feb 2016 00:32:23 +0000
Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly
In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za>
Message-ID: <1455755543.2.0.0175803339655.issue25738@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

Oh, my mistake ; I though send_error was to be used internally only, but it's actually a documented public method, that does not enforce to only use "actual" HTTP error code (I wonder what's the point of calling send_error with a non-error status code but that's beyond the point of this bug).

I will finish the work of SpaceOne : do a clean patch with just the modification (no rename of the variable nor comments) and write a test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25738>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:33:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 00:33:29 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1455755609.72.0.26603826546.issue26372@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes I understand bufsize (and universal_newlines) affects any of stdin, stdout and stderr that is set to PIPE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:37:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 00:37:23 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1455755843.01.0.500157994158.issue24911@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the reviews.

In this new patch, I modified two existing examples, but did not add any new example. Does that work for you Yury?

Also modified example code for the socketserver module.

Victor: IMO the ?with conn? in the example is not overkill. It ensures the client connection socket is cleaned up, which is completely independent of the server listening socket s.

What exceptions can you get out of conn.close()? I can only think of unusual programming errors like EBADF. I would prefer to remove close() as being redundant with the context manager.

----------
Added file: http://bugs.python.org/file41943/socket-context.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Wed Feb 17 20:46:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 01:46:16 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455759976.2.0.730480109745.issue15873@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hi Aymeric Augustin. I am guessing you are the original author of the code and tests in Django for parsing datetime strings (https://bugs.python.org/issue15873#msg260342). If so, would you be happy for it to be incorporated into Python?

Mathieu: I left a couple quick review comments. (Normally I leave a message in the main bug thread, but I forgot the other time.)

Doc strings: Generally I think we keep the doc strings to a minimum, and leave the main documentation for the RST files. For the RST documentation, I would suggest including a rough summary of the format. E.g. for time.fromisoformat(), something like ?The string should be in the RFC?s ?full-time? format, which looks like HH:MM:SS[.mmmmmm][Z|?HH:MM].?

Now that you added the two new regex strings, I can see that it might be useful to keep them together, rather than next to each class. Or you could even make them class attributes. No strong opinions either way; whatever works for you I think.

----------
nosy: +aymeric.augustin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Feb 17 21:03:09 2016
From: report at bugs.python.org (karl)
Date: Thu, 18 Feb 2016 02:03:09 +0000
Subject: [issue24772] Smaller viewport shifts the "expand left menu" character
 into the text
In-Reply-To: <1438422511.74.0.548589592521.issue24772@psf.upfronthosting.co.za>
Message-ID: <1455760989.79.0.462323146044.issue24772@psf.upfronthosting.co.za>


karl added the comment:

Where should I propose a patch to help resolve this issue?
A pointer to the code in the repo and I will do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24772>
_______________________________________

From report at bugs.python.org  Wed Feb 17 21:07:19 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Feb 2016 02:07:19 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455761239.95.0.533589622411.issue26360@psf.upfronthosting.co.za>


Ned Deily added the comment:

I'm not able to test it myself at the moment but you could also try ensuring your 2.7 build is with the most up-to-date ABI for your system:

./configure MACOSX_DEPLOYMENT_TARGET=10.9

2.7 builds do not set this automatically; 3.x builds do.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Wed Feb 17 22:50:51 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 18 Feb 2016 03:50:51 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
 auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1455767451.34.0.175733801803.issue2202@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

up

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Wed Feb 17 23:08:20 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Thu, 18 Feb 2016 04:08:20 +0000
Subject: [issue26379] zlib decompress as_bytearray flag
Message-ID: <1455768500.67.0.379084833673.issue26379@psf.upfronthosting.co.za>


New submission from Joe Jevnik:

Adds a keyword only flag to zlib.decompress and zlib.Decompress.decompress which marks that the return type should be a bytearray instead of bytes.

The use case for this is reading compressed data into a mutable array to do further operations without requiring that the user copy the data first. Often, if a user is choosing to compress the data there might be a real cost to copying the uncompressed bytes into a mutable buffer.

The impetus for this change comes from a patch for Pandas (https://github.com/pydata/pandas/pull/12359). I have also worked on a similar feature for blosc, another popular compression library for python (https://github.com/Blosc/python-blosc/pull/107).

My hope is to fix the hacky solution presented in the pandas patch by supporting this feature directly in the compression libraries.

As a side note: this is my first time using the argument clinic and I love it. It was so simple to add this argument, thank you very much for developing such an amazing tool!

----------
components: Extension Modules
files: zlib.patch
keywords: patch
messages: 260424
nosy: llllllllll
priority: normal
severity: normal
status: open
title: zlib decompress as_bytearray flag
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41944/zlib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26379>
_______________________________________

From report at bugs.python.org  Wed Feb 17 23:09:41 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 04:09:41 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455768581.83.0.707721226686.issue15873@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Feb 17 23:10:28 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Thu, 18 Feb 2016 04:10:28 +0000
Subject: [issue25770] expose name, args, and kwargs from methodcaller
In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za>
Message-ID: <1455768628.95.0.00517331268471.issue25770@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

ping: any decision on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25770>
_______________________________________

From report at bugs.python.org  Wed Feb 17 23:22:27 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 18 Feb 2016 04:22:27 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455769347.74.0.924581978312.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

New patch with all your concerns addressed (martin.panther+ silentghost) EXCEPT the single dispatch dictionary thing.

----------
Added file: http://bugs.python.org/file41945/fromisoformat_new3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Feb 17 23:32:34 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 18 Feb 2016 04:32:34 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455769954.01.0.222157793035.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

SilentGhost: the dictionary single dispatch thing attached (apply on top of the last, fromisoformat_new3).
I mind the performance penalty for date-only parsing users, but the code is definitively shorter and more elegant.

But we have a major problem: tests fails because what is used in tests is a subclass of datetime classes (Subclass[Date|Time|DateTime]) and thus, the dispatch break with a KeyError: class.SubDate[...]. I have no idea on how mitigate that. Do you ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 18 00:31:01 2016
From: report at bugs.python.org (Kushal Das)
Date: Thu, 18 Feb 2016 05:31:01 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455773461.91.0.416274851428.issue26323@psf.upfronthosting.co.za>


Kushal Das added the comment:

Go ahead and update the patch for assert_called_once and related tests.

----------
nosy: +kushal.das

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 01:18:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Feb 2016 06:18:47 +0000
Subject: [issue25939] _ssl.enum_certificates() fails with ERROR_ACCESS_DENIED
 if python.exe run with low integrity level
In-Reply-To: <1450989628.26.0.849835515988.issue25939@psf.upfronthosting.co.za>
Message-ID: <20160218061843.1967.55098@psf.io>


Roundup Robot added the comment:

New changeset 8ff4c1827499 by Benjamin Peterson in branch '3.5':
merge 3.4 (closes #25939)
https://hg.python.org/cpython/rev/8ff4c1827499

New changeset d6474257ef38 by Benjamin Peterson in branch 'default':
merge 3.5 (closes #25939)
https://hg.python.org/cpython/rev/d6474257ef38

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25939>
_______________________________________

From report at bugs.python.org  Thu Feb 18 01:20:05 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Feb 2016 06:20:05 +0000
Subject: [issue25939] _ssl.enum_certificates() fails with ERROR_ACCESS_DENIED
 if python.exe run with low integrity level
In-Reply-To: <1450989628.26.0.849835515988.issue25939@psf.upfronthosting.co.za>
Message-ID: <1455776405.1.0.282784968668.issue25939@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The patch itself seems fine, so I committed that. It doesn't seem like how best to test this has been figured out, so leaving the issue open.

----------
nosy: +benjamin.peterson
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25939>
_______________________________________

From report at bugs.python.org  Thu Feb 18 01:24:05 2016
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 18 Feb 2016 06:24:05 +0000
Subject: [issue26380] Add an http method enum
Message-ID: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>


New submission from Demian Brecht:

Super minor annoyance that I've had over multiple projects is seeing either hard coded strings being used (which is a bit of a no-no in terms of best practices) or each project defining its own set of constants for http methods. Why not just include a standard set in http as is done for status codes?

----------
components: Library (Lib)
keywords: needs review
messages: 260431
nosy: demian.brecht, r.david.murray
priority: normal
severity: normal
status: open
title: Add an http method enum
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Thu Feb 18 01:25:05 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 18 Feb 2016 06:25:05 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455776705.0.0.333105293952.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Added assert_call_once()

----------
Added file: http://bugs.python.org/file41946/issue26323.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 01:28:34 2016
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 18 Feb 2016 06:28:34 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455776914.41.0.847355100071.issue26380@psf.upfronthosting.co.za>


Demian Brecht added the comment:

If nobody's opposed to the addition, I'll run through the unit tests and replace the hard coded strings.

----------
keywords: +patch
Added file: http://bugs.python.org/file41947/issue26380.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Thu Feb 18 01:55:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 06:55:28 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1455778528.96.0.345700185335.issue22836@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the review; here is an updated patch.

If we just fall back the the default, it hides the fact that that there is a problem in the custom __repr__() method. Another option may be to both indicate there was an error, _and_ a fall back.

----------
versions:  -Python 3.4
Added file: http://bugs.python.org/file41948/unraisable-continue.v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Thu Feb 18 02:08:14 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Feb 2016 07:08:14 +0000
Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows
 xp
In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za>
Message-ID: <1455779294.1.0.0171926295883.issue20010@psf.upfronthosting.co.za>


Eryk Sun added the comment:

%z works correctly in the new CRT that's used by 3.5:

    Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25)
    [MSC v.1900 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import time
    >>> time.strftime('%z', time.localtime(time.time()))
    '-0000'
    >>> time.strftime('%Z', time.localtime(time.time()))
    'Coordinated Universal Time'

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20010>
_______________________________________

From report at bugs.python.org  Thu Feb 18 02:43:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Feb 2016 07:43:20 +0000
Subject: [issue26378] Typo in regex documentation
In-Reply-To: <1455745384.28.0.629898893574.issue26378@psf.upfronthosting.co.za>
Message-ID: <20160218074317.1962.8605@psf.io>


Roundup Robot added the comment:

New changeset c272a1e53f5b by Benjamin Peterson in branch '2.7':
fix typo (closes #26378)
https://hg.python.org/cpython/rev/c272a1e53f5b

New changeset 69717fdd9d5a by Benjamin Peterson in branch '3.5':
fix typo (closes #26378)
https://hg.python.org/cpython/rev/69717fdd9d5a

New changeset 6f0d3ae9f1f3 by Benjamin Peterson in branch 'default':
merge 3.5 (#26378)
https://hg.python.org/cpython/rev/6f0d3ae9f1f3

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26378>
_______________________________________

From report at bugs.python.org  Thu Feb 18 03:01:53 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 18 Feb 2016 08:01:53 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
 auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1455782513.4.0.543600765621.issue2202@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

python 2.7

----------
Added file: http://bugs.python.org/file41949/md5-sess_not_implem_27_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Feb 18 03:02:25 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 18 Feb 2016 08:02:25 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
 auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1455782545.5.0.249054441204.issue2202@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

python current

----------
Added file: http://bugs.python.org/file41950/md5-sess_not_implem_cur_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Feb 18 03:13:42 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Feb 2016 08:13:42 +0000
Subject: [issue26378] Typo in regex documentation
In-Reply-To: <1455745384.28.0.629898893574.issue26378@psf.upfronthosting.co.za>
Message-ID: <1455783222.88.0.129875532034.issue26378@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks for the report!

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26378>
_______________________________________

From report at bugs.python.org  Thu Feb 18 03:23:25 2016
From: report at bugs.python.org (Aymeric Augustin)
Date: Thu, 18 Feb 2016 08:23:25 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455783805.12.0.205850379458.issue15873@psf.upfronthosting.co.za>


Aymeric Augustin added the comment:

martin.panter: of course, I'm fine with integrating that code into Python.

deronnax: could you create a ticket on https://code.djangoproject.com/ highlighting the differences between Django's original implementation and the improved version that you worked on?

I'd like to use the stdlib implementation when it's available and align Django's current implementation to whatever's getting into the stdlib (to prepare the transition, even though we aren't going to drop support for Python 3.5 soon).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 18 03:37:41 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 08:37:41 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455784661.62.0.73120173645.issue15873@psf.upfronthosting.co.za>


SilentGhost added the comment:

Mathieu, nothing was attached. The penalty's worth only a few if statements, I wouldn't worry too much about it. Besides, a C version is going to be provided as well, right?

Perhaps the following approach might solve the subclasses problem:

regex = dispatch.get(cls)
if not regex:
    classes = datetime, date, time
    cls = next((c for c in classes if issubclass(cls, c)), None)
    if cls is None:   
        raise TypeError
    regex = dispatch[cls]

Perhaps, TypeError is unnecessary there and just propagating StopIteration would do. In that case the if clause would look like:

    classes = datetime, date, time
    cls = next(c for c in classes if issubclass(cls, c))
    regex = dispatch[cls]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 18 03:52:32 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 18 Feb 2016 08:52:32 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455785552.08.0.366404585653.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

crap, here is the attachment.
Yeah, but I really would like to use regex in the C version (unless you strongly disadvise), so we will have the same logic and the same problem. And I never made a patch for the C interpreter itself, so the C equivalent is not close to be here soon. (btw if you have a starting point to recommend)

I definitely do not like this fix, it destroys the elegance and the simplicity of the "single-dispatch" solution. And it introduce a lot of noisy code for a very rare case, people subclassing datetime.* classes.

Maybe making the regex dictionary having string keys instead of class and passing the correct string from the calling function, like:

    def fromisoformat(string):
        _parse_isodatetime('time', string)

or maybe functools.singledispatch handle this case ?

----------
Added file: http://bugs.python.org/file41951/fromisoformat_singledispatch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 18 04:09:22 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 18 Feb 2016 09:09:22 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1455717924.3.0.0573275298312.issue26302@psf.upfronthosting.co.za>
Message-ID: <8695F00B-E322-44DB-AC8D-E2D3CEE0C3B4@jaraco.com>


Jason R. Coombs added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26302>
_______________________________________

From report at bugs.python.org  Thu Feb 18 04:33:44 2016
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 18 Feb 2016 09:33:44 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1455788024.43.0.181810764573.issue26049@psf.upfronthosting.co.za>


C?dric Krier added the comment:

ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Thu Feb 18 04:34:23 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 09:34:23 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455788063.13.0.900424730631.issue15873@psf.upfronthosting.co.za>


SilentGhost added the comment:

Probably only other solution that I see is to add the third argument, an actual class, e.g.:

_parse_isodatetime(cls, string, datetime)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 18 04:39:26 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2016 09:39:26 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455788366.25.0.443109056046.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks, Ned. I tried with:

   ./configure --with-pydebug MACOSX_DEPLOYMENT_TARGET=10.9 && make

I'm still able to reproduce. I plan to find some time this weekend to dig into the source and see if I can narrow down the cause (or at least make the hang easier / quicker to reproduce).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Thu Feb 18 05:48:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 10:48:46 +0000
Subject: [issue26379] zlib decompress as_bytearray flag
In-Reply-To: <1455768500.67.0.379084833673.issue26379@psf.upfronthosting.co.za>
Message-ID: <1455792526.72.0.0826322847528.issue26379@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is an unusual technique. I can?t think of any other standard library routine that returns a new bytearray instead of a bytes object.

Normally there are sister functions with an -into() suffix that accept a pre-allocated buffer. Examples are BufferedIOBase.readinto(), struct.pack_into(), socket.recv_into(). What do you think about adding a decompressobj.decompress_into(input, output) method instead? If necessary you could use it in a wrapper, something like:

def decompress_as_bytearray(data, wbits=15, bufsize=16384):
    decompressor = zlib.decompressobj(wbits=wbits)
    buffer = bytearray(bufsize + 1)  # Overallocate to help detect EOF
    offset = 0
    while True:
        with memoryview(buffer) as view:
            offset += decompressor.decompress_into(data, view[offset:])
        if offset < len(buffer):
            break
        data = decompressor.unconsumed_tail
        buffer *= 2  # Expand the buffer
    del buffer[offset:]
    if not decompressor.eof:
        raise zlib.error("Incomplete data")
    return buffer

If anything is added for zlib decompression, it would be good to add equivalent functionality in the bz2 and LZMA modules.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26379>
_______________________________________

From report at bugs.python.org  Thu Feb 18 05:57:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 10:57:47 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
 auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1455793067.12.0.866037114584.issue2202@psf.upfronthosting.co.za>


Martin Panter added the comment:

I do wonder if NotImplementedError is the right exception. According to the documentation it is derived from RuntimeError and is meant for abstract methods, i.e. it is a programmer error. Other cases in urllib.request raise ValueError (e.g. AbstractBasicAuthHandler), which is fairly normal for protocol errors like this.

Also it would be nice to add a test case for the bug fix.

----------
nosy: +martin.panter
stage: needs patch -> patch review
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Feb 18 06:26:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 11:26:13 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1455794773.08.0.369735977826.issue15873@psf.upfronthosting.co.za>


Martin Panter added the comment:

Did you see my class attributes suggestion a couple messages back? That might solve your dispatch problem:

def _parse_isodatetime(cls, string):
    match = cls._iso_regex.match(...)

class time:
    _iso_regex = re.compile(...)

# or

time._iso_regex = re.compile(...)
date._iso_regex = ...

For the C module, start looking at /Modules/datetimemodule.c. Maybe if you can think of a similar function implemented in C to copy off. It looks like strptime() defers to a Python-only implementation; maybe that is another option.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Feb 18 06:54:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Feb 2016 11:54:37 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock()
 doesn't shutdown request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <20160218115434.1979.4630@psf.io>


Roundup Robot added the comment:

New changeset 651a6d47bc78 by Martin Panter in branch '3.5':
Issue #26309: Shut down socketserver request if verify_request() is false
https://hg.python.org/cpython/rev/651a6d47bc78

New changeset 0768edf5878d by Martin Panter in branch 'default':
Issue #26309: Merge socketserver fix from 3.5
https://hg.python.org/cpython/rev/0768edf5878d

New changeset e0fbd25f0b36 by Martin Panter in branch '2.7':
Issue #26309: Shut down SocketServer request if verify_request() is false
https://hg.python.org/cpython/rev/e0fbd25f0b36

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Thu Feb 18 06:56:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Feb 2016 11:56:03 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455776705.0.0.333105293952.issue26323@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbo8mC1m=PnR+TDhUmfeNHhwmZ3f952i0xm9zZ5PUE5vA@mail.gmail.com>


STINNER Victor added the comment:

I reviewed your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 06:58:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 11:58:29 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock()
 doesn't shutdown request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455796709.22.0.198961219705.issue26309@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the Python 2 version I had to make some small changes to the test. I used indirection instead of ?nonlocal?, and replaced the super() call because the classes are apparently the wrong kind for super().

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Thu Feb 18 07:27:09 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 18 Feb 2016 12:27:09 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455798429.76.0.0443837155133.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Thanks for the review. Updated patch addressing the comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 07:27:14 2016
From: report at bugs.python.org (Serhiy Int)
Date: Thu, 18 Feb 2016 12:27:14 +0000
Subject: [issue26381] Add 'geo' URI scheme (RFC 5870) to
 urllib.parse.uses_params
Message-ID: <1455798434.45.0.376625800279.issue26381@psf.upfronthosting.co.za>


Changes by Serhiy Int <serhiy.int at gmail.com>:


----------
components: Library (Lib)
nosy: Serhiy Int
priority: normal
severity: normal
status: open
title: Add 'geo' URI scheme (RFC 5870) to urllib.parse.uses_params
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26381>
_______________________________________

From report at bugs.python.org  Thu Feb 18 07:28:19 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 18 Feb 2016 12:28:19 +0000
Subject: [issue26323] Add a assert_called() method for mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455798499.25.0.71140400125.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Updated patch

----------
Added file: http://bugs.python.org/file41952/issue26323.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 07:29:29 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 18 Feb 2016 12:29:29 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455798569.49.0.813432965011.issue26323@psf.upfronthosting.co.za>


Changes by Amit Saha <amitsaha.in at gmail.com>:


----------
title: Add a assert_called() method for mock objects -> Add assert_called() and assert_called_once() methods for mock objects

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 07:53:45 2016
From: report at bugs.python.org (Krishna Oza)
Date: Thu, 18 Feb 2016 12:53:45 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1455800025.51.0.46438201131.issue1731717@psf.upfronthosting.co.za>


Krishna Oza added the comment:

Hi, Could anyone help here to identify in which Python release the bug is fixed. I am unable to deduce from the bug tracker interface in which release this issue is fixed.

Regards.

----------
nosy: +Krishna Oza

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Thu Feb 18 08:00:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Feb 2016 13:00:28 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455800428.19.0.722711985788.issue26323@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you please also document your changes in Doc/library/unittest.mock.rst? You will have to use ".. versionadded:: 3.6" in the doc of new functions.

You may also document directly the news functions in Doc/whatsnew/3.6.rst. It looks like you have to add a new "unittest" section in "Improved Modules".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 08:05:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Feb 2016 13:05:37 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1455800737.41.0.460353204704.issue1731717@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Hi, Could anyone help here to identify in which Python release the bug is fixed. I am unable to deduce from the bug tracker interface in which release this issue is fixed."

Oh, this is an old issue :-)

msg123946: "r87233 fixes the OSError escaping from wait() issue when SIGCLD is set to be ignored.  (to appear in 3.2beta1; it is a candidate for backporting to 3.1 and 2.7)"

msg123951: "sorry, i meant 3.2beta2 above.
release27-maint: r87234 targeting 2.7.2
release31-maint: r87235 targeting 3.1.4"

=> the fix is in Python 2 >= 2.7.2, Python 3.1 >= v3.1.4,  Python 3 >= 3.2.4.

I hope that you are using a more recent Python version than these versions :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Thu Feb 18 09:23:41 2016
From: report at bugs.python.org (Florian Bruhin)
Date: Thu, 18 Feb 2016 14:23:41 +0000
Subject: [issue25532] infinite loop when running inspect.unwrap over
 unittest.mock.call
In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za>
Message-ID: <1455805421.1.0.87485467272.issue25532@psf.upfronthosting.co.za>


Florian Bruhin added the comment:

FWIW, this also affects pytest users: https://github.com/pytest-dev/pytest/issues/1217

----------
nosy: +The Compiler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25532>
_______________________________________

From report at bugs.python.org  Thu Feb 18 09:26:52 2016
From: report at bugs.python.org (Catalin Gabriel Manciu)
Date: Thu, 18 Feb 2016 14:26:52 +0000
Subject: [issue26382] List object memory allocator
Message-ID: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>


New submission from Catalin Gabriel Manciu:

Hi All,

This is Catalin from the Server Scripting Languages Optimization Team at Intel Corporation. I would like to submit a patch that replaces the 'malloc' allocator used by the list object (Objects/listobject.c) with the small object allocator (obmalloc.c) and simplifies the 'list_resize' function by removing a redundant check and properly handling resizing to zero.

Replacing PyMem_* calls with PyObject_* inside the list implementation is beneficial because many PyMem_* calls are made for requesting sizes that are better handled by the small object allocator. For example, when running Tools/pybench.py -w 1 a total of 48.295.840 allocation requests are made by the list implementation (either by using 'PyMem_MALLOC' directly or by calling 'PyMem_RESIZE') out of which 42.581.993 (88%) are requesting sizes that can be handled by the small object allocator (they're equal or less than 512 bytes in size).

The changes to 'list_resize' were made in order to further improve performance by removing a redundant check and handling the 'resize to zero' case separately. The 'empty' state of a list is suggested by the 'PyList_New' function as having the 'ob_item' pointer NULL and the 'ob_size' and 'allocated' members equal with 0. Previously, when being called with zero as a size parameter, 'list_resize' would set 'ob_size' and 'allocated' to zero, but it would also call 'PyMem_RESIZE' which, by its design, would call 'realloc' with a size of 1, thus going through the process of allocating an unnecessary 1 byte and setting the 'ob_item' pointer with the newly obtained address. The proposed implementation just deletes the buffer pointed by 'ob_item' and sets 'ob_size', 'allocated' and 'ob_item' to zero when receiving a 'resize to zero' request.


Hardware and OS Configuration
=============================
Hardware:           Intel XEON (Haswell-EP) 36 Cores / Intel XEON (Broadwell-EP) 36 Cores

BIOS settings:      Intel Turbo Boost Technology: false
                    Hyper-Threading: false                  

OS:                 Ubuntu 14.04.2 LTS

OS configuration:   Address Space Layout Randomization (ASLR) disabled to reduce run
                    to run variation by echo 0 > /proc/sys/kernel/randomize_va_space
                    CPU frequency set fixed at 2.3GHz

GCC version:        GCC version 5.1.0

Benchmark:          Grand Unified Python Benchmark from 
                    https://hg.python.org/benchmarks/

Measurements and Results
========================
A. Repository:
    GUPB Benchmark:
        hg id :  9923b81a1d34 tip
        hg --debug id -i : 9923b81a1d346891f179f57f8780f86dcf5cf3b9

    CPython3:
        hg id : 733a902ac816 tip
        hg id -r 'ancestors(.) and tag()': 737efcadf5a6 (3.4) v3.4.4
        hg --debug id -i : 733a902ac816bd5b7b88884867ae1939844ba2c5

    CPython2:
        hg id : 5715a6d9ff12 (2.7)
        hg id -r 'ancestors(.) and tag()': 6d1b6a68f775 (2.7) v2.7.11
        hg --debug id -i : 5715a6d9ff12053e81f7ad75268ac059b079b351

B. Results:
CPython2 and CPython3 sample results, measured on a Haswell and a Broadwell platform can be viewed in Tables 1, 2, 3 and 4. The first column (Benchmark) is the benchmark name and the second (%D) is the speedup in percents compared with the unpatched version.

Table 1. CPython 3 results on Intel XEON (Haswell-EP) @ 2.3 GHz

Benchmark                   %D
----------------------------------
unpickle_list               20.27
regex_effbot                6.07
fannkuch                    5.87
mako_v2                     5.19
meteor_contest              4.31
simple_logging              3.98
nqueens                     3.40
json_dump_v2                3.14
fastpickle                  2.16
django_v3                   2.03
tornado_http                1.90
pathlib                     1.84
fastunpickle                1.81
call_simple                 1.75
nbody                       1.60
etree_process               1.58
go                          1.54
call_method_unknown         1.53
2to3                        1.26
telco                       1.04
etree_generate              1.02
json_load                   0.85
etree_parse                 0.81
call_method_slots           0.73
etree_iterparse             0.68
call_method                 0.65
normal_startup              0.63
silent_logging              0.56
chameleon_v2                0.56
pickle_list                 0.52
regex_compile               0.50
hexiom2                     0.47
pidigits                    0.39
startup_nosite              0.17
pickle_dict                 0.00
unpack_sequence             0.00
formatted_logging          -0.06
raytrace                   -0.06
float                      -0.18
richards                   -0.37
spectral_norm              -0.51
chaos                      -0.65
regex_v8                   -0.72


Table 2. CPython 3 results on Intel XEON (Broadwell-EP) @ 2.3 GHz

Benchmark                   %D
----------------------------------
unpickle_list               15.75
nqueens                     5.24
mako_v2                     5.17
unpack_sequence             4.44
fannkuch                    4.42
nbody                       3.25
meteor_contest              2.86
regex_effbot                2.45
json_dump_v2                2.44
django_v3                   2.26
call_simple                 2.09
tornado_http                1.74
regex_compile               1.40
regex_v8                    1.16
spectral_norm               0.89
2to3                        0.76   
chameleon_v2                0.70
telco                       0.70
normal_startup              0.64
etree_generate              0.61
etree_process               0.55
hexiom2                     0.51
json_load                   0.51
call_method_slots           0.48
formatted_logging           0.33
call_method                 0.28
startup_nosite             -0.02
fastunpickle               -0.02
pidigits                   -0.20
etree_parse                -0.23
etree_iterparse            -0.27
richards                   -0.30
silent_logging             -0.36
pickle_list                -0.42
simple_logging             -0.82
float                      -0.91
pathlib                    -0.99
go                         -1.16
raytrace                   -1.16
chaos                      -1.26
fastpickle                 -1.72
call_method_unknown        -2.94
pickle_dict                -4.73


Table 3. CPython 2 results on Intel XEON (Haswell-EP) @ 2.3 GHz

Benchmark                   %D
----------------------------------
unpickle_list               15.89
json_load                   11.53
fannkuch                    7.90
mako_v2                     7.01
meteor_contest              4.21
nqueens                     3.81
fastunpickle                3.56
django_v3                   2.91
call_simple                 2.72
call_method_slots           2.45
slowpickle                  2.23
call_method                 2.21
html5lib_warmup             1.90
chaos                       1.89
html5lib                    1.81
regex_v8                    1.81
tornado_http                1.66
2to3                        1.56
json_dump_v2                1.49
nbody                       1.38
rietveld                    1.26
formatted_logging           1.12
regex_compile               0.99
spambayes                   0.92
pickle_list                 0.87
normal_startup              0.82
pybench                     0.74
slowunpickle                0.71
raytrace                    0.67
startup_nosite              0.59
float                       0.47
hexiom2                     0.46
slowspitfire                0.46
pidigits                    0.44
etree_process               0.44
etree_generate              0.37
go                          0.27
telco                       0.24
regex_effbot                0.12
etree_iterparse             0.06
bzr_startup                 0.04
richards                    0.03
etree_parse                 0.00
unpack_sequence             0.00
call_method_unknown        -0.26
pathlib                    -0.57
fastpickle                 -0.64
silent_logging             -0.94
simple_logging             -1.10
chameleon_v2               -1.25
pickle_dict                -1.67
spectral_norm              -3.25


Table 4. CPython 2 results on Intel XEON (Broadwell-EP) @ 2.3 GHz

Benchmark                   %D
----------------------------------
unpickle_list               15.44
json_load                   11.11
fannkuch                    7.55
meteor_contest              5.51
mako_v2                     4.94
nqueens                     3.49
html5lib_warmup             3.15
html5lib                    2.78
call_simple                 2.35
silent_logging              2.33
json_dump_v2                2.14
startup_nosite              2.09
bzr_startup                 1.93
fastunpickle                1.93
slowspitfire                1.91
regex_v8                    1.79
rietveld                    1.74
pybench                     1.59
nbody                       1.57
regex_compile               1.56
pathlib                     1.51
tornado_http                1.33
normal_startup              1.21
2to3                        1.14
chaos                       1.00
spambayes                   0.85
etree_process               0.73
pickle_list                 0.70
float                       0.69
hexiom2                     0.51
slowpickle                  0.44
call_method_unknown         0.42
slowunpickle                0.37
pickle_dict                 0.25
etree_parse                 0.20
go                          0.19
django_v3                   0.12
call_method_slots           0.12
spectral_norm               0.05
call_method                 0.01
unpack_sequence             0.00
raytrace                   -0.08
pidigits                   -0.11
richards                   -0.16
etree_generate             -0.23
regex_effbot               -0.26
telco                      -0.28
simple_logging             -0.32
etree_iterparse            -0.38
formatted_logging          -0.50
fastpickle                 -1.08
chameleon_v2               -1.74

----------
components: Interpreter Core
files: listobject_CPython3.patch
keywords: patch
messages: 260459
nosy: catalin.manciu
priority: normal
severity: normal
status: open
title: List object memory allocator
type: performance
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41953/listobject_CPython3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Thu Feb 18 09:27:25 2016
From: report at bugs.python.org (Catalin Gabriel Manciu)
Date: Thu, 18 Feb 2016 14:27:25 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455805645.53.0.161762176621.issue26382@psf.upfronthosting.co.za>


Changes by Catalin Gabriel Manciu <catalin.gabriel.manciu at intel.com>:


Added file: http://bugs.python.org/file41954/listobject_CPython2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Thu Feb 18 09:30:26 2016
From: report at bugs.python.org (Florin Papa)
Date: Thu, 18 Feb 2016 14:30:26 +0000
Subject: [issue26383] number of decimal places in csv output
Message-ID: <1455805826.32.0.222173600977.issue26383@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi,

This is Florin Papa from the Dynamic Scripting Languages Optimizations Team at Intel Corporation.

This patch checks whether the benchmark measurement that will be included in the csv output has more than 3 of the first decimal places equal to 0 and outputs more decimal places.

The problem is that each measurement in the csv output has only 6 decimal places (default for "%f" format), while some benchmarks, like unpack_sequence, will output values of the magnitude 0.0000xx (first four decimal places 0). This truncation of the original value can lead to incorrect results.

----------
components: Benchmarks
files: decimal_csv_output.csv
messages: 260460
nosy: brett.cannon, florin.papa, pitrou
priority: normal
severity: normal
status: open
title: number of decimal places in csv output
type: behavior
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41955/decimal_csv_output.csv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26383>
_______________________________________

From report at bugs.python.org  Thu Feb 18 09:43:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Feb 2016 14:43:04 +0000
Subject: [issue26383] benchmarks (perf.py): number of decimal places in csv
 output
In-Reply-To: <1455805826.32.0.222173600977.issue26383@psf.upfronthosting.co.za>
Message-ID: <1455806584.74.0.536130890472.issue26383@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: number of decimal places in csv output -> benchmarks (perf.py): number of decimal places in csv output

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26383>
_______________________________________

From report at bugs.python.org  Thu Feb 18 09:44:03 2016
From: report at bugs.python.org (Manuel Jacob)
Date: Thu, 18 Feb 2016 14:44:03 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455806643.27.0.611448030627.issue26367@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

(For some reason, I forgot to submit the previous comment).

The attached patches fix the issue (one for the 3.5 branch, one for the default branch) by bringing importlib.__import__ closer to the builtin __import__.

The extra code in the default / 3.6 branch is because of the changes from issue18018.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Thu Feb 18 10:35:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Feb 2016 15:35:28 +0000
Subject: [issue16915] mode of socket.makefile is more limited than
 documentation suggests
In-Reply-To: <1357825217.2.0.655032840521.issue16915@psf.upfronthosting.co.za>
Message-ID: <20160218153454.1541.80373@psf.io>


Roundup Robot added the comment:

New changeset a7391c31ec4e by Berker Peksag in branch '3.5':
Issue #16915: Clarify that mode parameter of socket.makefile() does not accept
https://hg.python.org/cpython/rev/a7391c31ec4e

New changeset bbfbde6ee9d0 by Berker Peksag in branch 'default':
Issue #16915: Clarify that mode parameter of socket.makefile() does not accept
https://hg.python.org/cpython/rev/bbfbde6ee9d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16915>
_______________________________________

From report at bugs.python.org  Thu Feb 18 10:40:39 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Feb 2016 15:40:39 +0000
Subject: [issue16915] mode of socket.makefile is more limited than
 documentation suggests
In-Reply-To: <1357825217.2.0.655032840521.issue16915@psf.upfronthosting.co.za>
Message-ID: <1455810039.22.0.051055873811.issue16915@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and for the patch. I would prefer to keep the code simple so I just applied documentation changes with a minor tweak.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +berker.peksag, docs at python
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16915>
_______________________________________

From report at bugs.python.org  Thu Feb 18 10:50:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Feb 2016 15:50:52 +0000
Subject: [issue26384] UnboundLocalError in socket._sendfile_use_sendfile
Message-ID: <1455810652.46.0.743197751136.issue26384@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I noticed this while working on issue 16915:

Traceback (most recent call last):
  ...
  File "/home/berker/projects/cpython/default/Lib/socket.py", line 262, in _sendfile_use_sendfile
    raise _GiveupOnSendfile(err)  # not a regular file
UnboundLocalError: local variable 'err' referenced before assignment

Here's a patch.

----------
components: Library (Lib)
files: socket_unboundlocalerror.diff
keywords: patch
messages: 260464
nosy: berker.peksag
priority: normal
severity: normal
stage: patch review
status: open
title: UnboundLocalError in socket._sendfile_use_sendfile
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41956/socket_unboundlocalerror.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26384>
_______________________________________

From report at bugs.python.org  Thu Feb 18 10:57:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Feb 2016 15:57:17 +0000
Subject: [issue25532] infinite loop when running inspect.unwrap over
 unittest.mock.call
In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za>
Message-ID: <1455811037.59.0.434183612026.issue25532@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25532>
_______________________________________

From report at bugs.python.org  Thu Feb 18 11:17:48 2016
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 18 Feb 2016 16:17:48 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455812268.62.0.54716392238.issue26380@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I don't have a firm opinion at this point -- can you give a few examples of how this will help in code?

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Thu Feb 18 11:17:52 2016
From: report at bugs.python.org (Eugene Viktorov)
Date: Thu, 18 Feb 2016 16:17:52 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
Message-ID: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>


New submission from Eugene Viktorov:

When calling the tempfile.NamedTemporaryFile with mode='wr' or with any other wrong value for "mode", it raises the ValueError and silently leaves an unknown, just created file on the file system.

----------
components: Library (Lib)
files: temp_file.py
messages: 260466
nosy: Eugene Viktorov
priority: normal
severity: normal
status: open
title: the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41957/temp_file.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Thu Feb 18 11:21:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Feb 2016 16:21:29 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455812489.64.0.87392176576.issue26382@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Instead of modifying individual files, I proposed to modify PyMem_Malloc to use PyObject_Malloc allocator: issue #26249.

But the patch for Python 2 still makes sense.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Thu Feb 18 11:27:57 2016
From: report at bugs.python.org (Tony R.)
Date: Thu, 18 Feb 2016 16:27:57 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455812877.69.0.541684407424.issue26366@psf.upfronthosting.co.za>


Tony R. added the comment:

> My weak opinion is that a new parameter is a new API item, not just a change in behaviour, so should probably have ?versionadded?. 

This was my reasoning as well.  

Also, when I noticed so many instances of ``.. versionchanged`` that all say ?Added the *x* parameter? (or whatever), it strikes me that these are a *large class of changes*, which all have some kind of addition in common.  If you think about it, deprecations and removals are also changes, but they are a large-enough class of changes to merit a distinct markup directive.  

So, just as this is true for ?deprecated? or ?deprecated-removed?, I believe it is just as true for ?added?.  Once all additions, deprecations, and removals have been marked up as such, I think find that there?s still PLENTY of annotations that remain under ``.. versionchanged``.  

Put another way: 

Since these are all different types of changes, it is most useful to the reader if the most specific *type* of change is reflected in the markup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Thu Feb 18 11:30:08 2016
From: report at bugs.python.org (George)
Date: Thu, 18 Feb 2016 16:30:08 +0000
Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle
Message-ID: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za>


New submission from George:

Id's with spaces in them causes a crash when using the .selection* methods Treeview.  Version of ttk.py "0.3.1" dated 12/6/2015.  Traceback line numbers are 1415 then 1395  

Either of these lines of code, where the item id is "2009 Report.pdf" crash
   allParents = oTree.get_children()
   for id in allParents:
     oTree.selection_add(id)
     #  oTree.selection_toggle(id)

These two lines of workaround code do work however.
   oTree.selection_add('"' + id + '"')
   #  oTree.selection_toggle('"' + id + '"')

Note that so far all other places in dealing with the item id's have no issue when there are spaces in them.

----------
components: Tkinter
messages: 260469
nosy: gbarnabic
priority: normal
severity: normal
status: open
title: tkinter - Treeview - .selection_add and selection_toggle
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26386>
_______________________________________

From report at bugs.python.org  Thu Feb 18 11:52:52 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 18 Feb 2016 16:52:52 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1455814372.14.0.644770829205.issue19251@psf.upfronthosting.co.za>


???? ????????? added the comment:

in order to increase perofrmance even more, use block operation on bytes. I.e. Xor by 8 bytes first (on 64-bit system) while size remainig is bigger or equal to 8, then by 4 bytes using same loop, and then xor remaining bytes by one byte. This will increase performance roughly to 8 times on 64bit systems and by 4 times on 32bit systems.

See my PR https://github.com/KeepSafe/aiohttp/pull/687/files for details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Thu Feb 18 12:31:24 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2016 17:31:24 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1455816684.04.0.354785120452.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

A minor update: I did manage to verify that the GIL is indeed not held by any threads at the moment of the hang, so it does look very much as though a `pthread_cond_signal` signal has gone astray somehow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Thu Feb 18 12:59:33 2016
From: report at bugs.python.org (Filipp Andjelo)
Date: Thu, 18 Feb 2016 17:59:33 +0000
Subject: [issue26387] Race condition in sqlite module
Message-ID: <1455818373.79.0.020961668279.issue26387@psf.upfronthosting.co.za>


New submission from Filipp Andjelo:

Race condition in sqlite close/dealloc crashes the application with double free(). The pointer is set to NULL outside of mutexed zone, so if close and dealloc follow each other very shortly application crashes. Please see the attached patch.

----------
components: Library (Lib)
files: sqlite_connection.c.patch
keywords: patch
messages: 260472
nosy: scorp
priority: normal
severity: normal
status: open
title: Race condition in sqlite module
type: crash
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41958/sqlite_connection.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26387>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:03:53 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 18:03:53 +0000
Subject: [issue26387] Race condition in sqlite module
In-Reply-To: <1455818373.79.0.020961668279.issue26387@psf.upfronthosting.co.za>
Message-ID: <1455818633.27.0.682348965238.issue26387@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components: +Extension Modules
nosy: +ghaering
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26387>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:33:13 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 18 Feb 2016 18:33:13 +0000
Subject: [issue18454] distutils crashes when uploading to PyPI having only the
 username (no pw) defined
In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za>
Message-ID: <1455820393.97.0.229042787553.issue18454@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've recently taken a different tack to this issue with setuptools 20.1, which will resolve the password from a keyring if available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18454>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:43:06 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 18 Feb 2016 18:43:06 +0000
Subject: [issue26149] Suggest PyCharm Community as an editor for Unix platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1455820986.88.0.702379910376.issue26149@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26149>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:44:00 2016
From: report at bugs.python.org (Anish Shah)
Date: Thu, 18 Feb 2016 18:44:00 +0000
Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle
In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za>
Message-ID: <1455821040.85.0.332681265707.issue26386@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26386>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:48:04 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 18:48:04 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455821284.93.0.117186356723.issue26385@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is a na?ve fix including a test.

----------
keywords: +patch
nosy: +SilentGhost, georg.brandl
stage:  -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41959/issue26385.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:50:06 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 18:50:06 +0000
Subject: [issue26381] Add 'geo' URI scheme (RFC 5870) to
 urllib.parse.uses_params
Message-ID: <1455821406.84.0.516711453948.issue26381@psf.upfronthosting.co.za>


New submission from SilentGhost:

Here is the spec: https://tools.ietf.org/html/rfc5870#section-3.3

----------
nosy: +SilentGhost, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26381>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:50:44 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 18:50:44 +0000
Subject: [issue26374] concurrent_futures Executor.map semantics better
 specified in docs
In-Reply-To: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>
Message-ID: <1455821444.26.0.176213791606.issue26374@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components: +Library (Lib)
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26374>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:55:32 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 18 Feb 2016 18:55:32 +0000
Subject: [issue26370] shelve filename inconsistent between platforms
In-Reply-To: <1455631325.94.0.590014562337.issue26370@psf.upfronthosting.co.za>
Message-ID: <1455821732.76.0.925777166582.issue26370@psf.upfronthosting.co.za>


SilentGhost added the comment:

Would you like to try to submit a patch for a solution you think most appropriate?

----------
nosy: +SilentGhost, georg.brandl
type: behavior -> enhancement
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26370>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:57:06 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2016 18:57:06 +0000
Subject: [issue26374] concurrent_futures Executor.map semantics better
 specified in docs
In-Reply-To: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>
Message-ID: <1455821826.95.0.446611479017.issue26374@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The documentation says: "Equivalent to map(func, *iterables)". I believe that that equivalency implies that the ordering *is* defined, so it would be incorrect to add "order of results is undefined" to the documentation.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26374>
_______________________________________

From report at bugs.python.org  Thu Feb 18 14:00:01 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2016 19:00:01 +0000
Subject: [issue26374] concurrent_futures Executor.map semantics better
 specified in docs
In-Reply-To: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>
Message-ID: <1455822001.16.0.0406531575219.issue26374@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Note also this code snippet from PEP 3148:

    for number, prime in zip(PRIMES, executor.map(is_prime,
                                                      PRIMES)):

The use of zip here suggests strongly that the intention is that the order of the `map` result is well-defined.

It's possible that the docs should be updated to make the ordering requirement clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26374>
_______________________________________

From report at bugs.python.org  Thu Feb 18 14:22:14 2016
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 18 Feb 2016 19:22:14 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455823334.67.0.448455523401.issue26380@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> I don't have a firm opinion at this point -- can you give a few examples of how this will help in code?

It'll help solely with consistency across projects. Generally, using constants are generally favored over using hardcoded values. Mainly, it helps reduce typos. Some projects use literals, others use project-specific constants. It's something that I've found myself redefining over various projects, and I just though "why couldn't this be added to the standard library, given it's an attribute of the HTTP/1.1 RFC"?

/Very/ minor, personal annoyance.

The updated patch fixes the OPTION typo.

----------
Added file: http://bugs.python.org/file41960/issue26380_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Thu Feb 18 14:51:31 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Thu, 18 Feb 2016 19:51:31 +0000
Subject: [issue26379] zlib decompress as_bytearray flag
In-Reply-To: <1455768500.67.0.379084833673.issue26379@psf.upfronthosting.co.za>
Message-ID: <1455825091.32.0.116639436131.issue26379@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

The recipe you showed looks like it is very complicated for the expected use case of decompressing all of the data into a mutable buffer. One difference I see with this and struct.pack_into or socket.recv_into is that in both of those cases we know how large our buffer needs to be. With zlib.decompress there is not a simple way for users to preallocate a buffer to hold the result and need to resort to some looping with a lot of resizes. I think that returning either a mutable or immutable buffer hits 95% of use cases. If we go with the decompress_into method I would strongly advise putting decompress_as_bytearray into the standard library so that users do not need write this themselves.

Thank you for pointing me at the bz2 and LZMA modules. When we come to an agreement on the API I will update bz2 and LZMA so that they match. Should I also update the gzip module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26379>
_______________________________________

From report at bugs.python.org  Thu Feb 18 16:16:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 21:16:21 +0000
Subject: [issue26379] zlib decompress as_bytearray flag
In-Reply-To: <1455768500.67.0.379084833673.issue26379@psf.upfronthosting.co.za>
Message-ID: <1455830181.1.0.167471866512.issue26379@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you don?t know how large the buffer is when you call zlib.decompress(), there may be copying involved as the buffer is expanded. Have you found that the copying the bytes result into a bytearray is significantly worse than expanding a bytearray (e.g. timing results)?

The trouble with this proposal is that to me it doesn?t seem like there is a high demand for it. That is why I suggested the more minimal, low-level decompress_into() version. I think I would like to hear other opinions.

As for updating GzipFile, that uses an intermediate BufferedReader, so we cannot completely avoid copying. But it might be worthwhile updating the internal readinto() method anyway. Possibly also with the zipfile module, though I am not so familiar with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26379>
_______________________________________

From report at bugs.python.org  Thu Feb 18 16:24:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 18 Feb 2016 21:24:37 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455830677.72.0.00819019350026.issue26380@psf.upfronthosting.co.za>


Martin Panter added the comment:

I can see the advantage of using an enum over a plain string. But you only get an error at run time, not compile time, if you misspell it. And there is also the disadvantage of the extra boilerplate of importing HTTPMessage. So I don?t have a strong opinion either way. Do other libraries have a similar enum?

BTW I think it is actually OPTIONS; see review comment.

----------
nosy: +martin.panter
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Thu Feb 18 17:37:01 2016
From: report at bugs.python.org (Mike Kaplinskiy)
Date: Thu, 18 Feb 2016 22:37:01 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
Message-ID: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>


New submission from Mike Kaplinskiy:

For the purposes of pex (https://github.com/pantsbuild/pex), it would be useful to allow calling run_module without sys.argv[0] changing. In general, this behavior is useful if the script intends to re-exec itself (so it needs to know the original arguments that it was started with).

To make run_module more useful in general, I propose adding a `argv` parameter that has the following semantics:
 - (default) If set to a special value runpy.INHERIT (similar to subprocess.STDOUT), produces the current behavior of just changing sys.argv[0].
 - If set to None, does not touch sys.argv at all.
 - If set to an iterable, executes `sys.argv = [module.__file__] + list(argv)`, and properly reverts it once the module is done executing.

----------
components: Library (Lib)
messages: 260483
nosy: Mike Kaplinskiy
priority: normal
severity: normal
status: open
title: Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Thu Feb 18 17:40:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Feb 2016 22:40:04 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1455835204.63.0.458056693461.issue26388@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Thu Feb 18 17:53:43 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Feb 2016 22:53:43 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455836023.56.0.466746326025.issue26367@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The corresponding code in C that actually does the check: https://hg.python.org/cpython/file/default/Python/import.c#l1498

Manuel, can you sign the CLA at https://www.python.org/psf/contrib/contrib-form/ ? Once you sign it I can officially review your patch, otherwise I technically can't touch your code.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Thu Feb 18 17:59:10 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Feb 2016 22:59:10 +0000
Subject: [issue26389] Expand traceback module API to accept just an exception
 as an argument
Message-ID: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za>


New submission from Brett Cannon:

When reading https://docs.python.org/3/library/traceback.html#traceback.print_exception I noticed that everything takes a traceback or a set of exception type, instance, and traceback. But since Python 3.0 all of that information is contained in a single exception object. So there's no reason to expand the APIs in the traceback module that take an exception to just take an exception instance and infer the exception type and grab the exception from exception instance itself.

----------
components: Library (Lib)
messages: 260485
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Expand traceback module API to accept just an exception as an argument
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26389>
_______________________________________

From report at bugs.python.org  Thu Feb 18 18:07:12 2016
From: report at bugs.python.org (Manuel Jacob)
Date: Thu, 18 Feb 2016 23:07:12 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455836832.34.0.430812786962.issue26367@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

Done.  I'm a bit surprised this wasn't necessary for my previous two patches, but they were even more trival than this one. ;)

Do we have to wait until my tracker profile is updated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Thu Feb 18 18:14:10 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 18 Feb 2016 23:14:10 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1455837250.2.0.724790819304.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Updated patch with docs and addressed review comments.

----------
Added file: http://bugs.python.org/file41961/issue26323.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Thu Feb 18 18:49:36 2016
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 18 Feb 2016 23:49:36 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455839376.05.0.26440647337.issue26380@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> I can see the advantage of using an enum over a plain string. But you only get an error at run time, not compile time, if you misspell it.

Sure, but at least you're giving static analysis utilities the chance to catch it up front.

> And there is also the disadvantage of the extra boilerplate of importing HTTPMessage.

I guess that all depends on how you're importing your modules. If you just import "http", then there's no additional boilerplate.

> So I don?t have a strong opinion either way. Do other libraries have a similar enum?

I haven't seen enums in other libraries, only constants. I figured that it might as well be consistent with HTTPStatus, although granted, HTTPStatus does a little more than the methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Thu Feb 18 18:53:35 2016
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 18 Feb 2016 23:53:35 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455839615.12.0.540558596069.issue26380@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> BTW I think it is actually OPTIONS; see review comment.
Well, don't I feel silly. Fixed.

----------
Added file: http://bugs.python.org/file41962/issue26380_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Thu Feb 18 19:00:57 2016
From: report at bugs.python.org (Daan Bakker)
Date: Fri, 19 Feb 2016 00:00:57 +0000
Subject: [issue26390] hashlib's pbkdf2_hmac documentation "rounds" does not
 match source
Message-ID: <1455840057.88.0.0946194046166.issue26390@psf.upfronthosting.co.za>


New submission from Daan Bakker:

The documentation for pbkdf2_hmac at https://docs.python.org/3/library/hashlib.html uses the "rounds" keyword:

hashlib.pbkdf2_hmac(name, password, salt, rounds, dklen=None)

However, the actual source code uses "iterations". No-one has probably noticed it before because no error is raised if the number of iterations is given as a positional argument.

----------
assignee: docs at python
components: Documentation
files: pbkdf2_4.patch
keywords: patch
messages: 260490
nosy: dbakker, docs at python
priority: normal
severity: normal
status: open
title: hashlib's pbkdf2_hmac documentation "rounds" does not match source
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41963/pbkdf2_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26390>
_______________________________________

From report at bugs.python.org  Thu Feb 18 19:06:38 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 19 Feb 2016 00:06:38 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455840398.52.0.822512313708.issue26367@psf.upfronthosting.co.za>


Brett Cannon added the comment:

If a contribution is insignificant enough then technically a CLA isn't necessary, but I just make it a habit to ask for one regardless.

And your profile will probably get updated fairly quickly, so I wouldn't worry about it holding anything up (I'm hoping to commit the code tomorrow; I already did a review and it LGTM).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Thu Feb 18 19:36:10 2016
From: report at bugs.python.org (Eric Snow)
Date: Fri, 19 Feb 2016 00:36:10 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1455842170.09.0.78504058658.issue26388@psf.upfronthosting.co.za>


Eric Snow added the comment:

python-dev thread:

  https://mail.python.org/pipermail/python-dev/2016-February/143374.html

Notably:

  https://github.com/pantsbuild/pex/pull/211

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:09:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 01:09:48 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455844188.76.0.761774989724.issue26385@psf.upfronthosting.co.za>


Martin Panter added the comment:

This looks like an extension of Issue 21058. Does the unlink() work on Windows? It seems to me that the file is configured to remove itself on close(), therefore I expect unlink() will raise an exception of its own. Also made some suggestions in the code review.

This problem also affects Python 2, if you fudge the right wrong parameters:

>>> NamedTemporaryFile((), prefix="blaua.")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/proj/python/cpython/Lib/tempfile.py", line 477, in NamedTemporaryFile
    file = _os.fdopen(fd, mode, bufsize)
TypeError: argument 2 must be string, not tuple
[59140 refs]
>>> glob("/tmp/blaua.*")
['/tmp/blaua.AFtEqx']

----------
nosy: +martin.panter
versions: +Python 2.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:24:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 01:24:27 +0000
Subject: [issue26390] hashlib's pbkdf2_hmac documentation "rounds" does not
 match source
In-Reply-To: <1455840057.88.0.0946194046166.issue26390@psf.upfronthosting.co.za>
Message-ID: <1455845067.85.0.864322565257.issue26390@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch. The documentation still mentions *rounds* in one place, which I presume was meant to be a direct reference to the parameter.

----------
nosy: +martin.panter
stage:  -> patch review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26390>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:37:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 01:37:59 +0000
Subject: [issue26381] Add 'geo' URI scheme (RFC 5870) to
 urllib.parse.uses_params
In-Reply-To: <1455821406.84.0.516711453948.issue26381@psf.upfronthosting.co.za>
Message-ID: <1455845879.03.0.569363119491.issue26381@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sounds reasonable to me, and thanks for the reference.

But it would be nice to find a way for this to work sensibly with arbitrary schemes, in the same spirit as Issue 18828. Would it break anything if we removed the uses_params list altogether? I notice it already works if you omit the scheme:

>>> urlparse("48.198634,16.371648;crs=wgs84")
ParseResult(scheme='', netloc='', path='48.198634,16.371648', params='crs=wgs84', query='', fragment='')

If a programmer doesn?t want to split of the ?params? they can always use urlsplit() instead of urlparse().

----------
nosy: +martin.panter
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26381>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:48:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 01:48:48 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock()
 doesn't shutdown request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455846528.44.0.610187386038.issue26309@psf.upfronthosting.co.za>


Martin Panter added the comment:

Some of the buildbots failed (e.g. <http://buildbot.python.org/all/builders/ARMv7%20Ubuntu%202.7/builds/1145/steps/test/logs/stdio>). I think the server is run in a separate thread, and the problem is a race between shutdown_request() being called and run_server returning.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Thu Feb 18 21:19:51 2016
From: report at bugs.python.org (Zach Byrne)
Date: Fri, 19 Feb 2016 02:19:51 +0000
Subject: [issue26280] ceval: Optimize list
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1455848391.3.0.823552503031.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

Is it worth handling the exception, or just let it take the slow path and get caught by PyObject_GetItem()? We're still making sure the index is in bounds.

Also, where would be an appropriate place to put a macro for adjusting negative indices?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26280>
_______________________________________

From report at bugs.python.org  Thu Feb 18 21:43:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Feb 2016 02:43:37 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock()
 doesn't shutdown request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <20160219024334.1950.18794@psf.io>


Roundup Robot added the comment:

New changeset cba717fa8e10 by Martin Panter in branch '2.7':
Issue #26309: Rewrite test in main thread and avoid race condition
https://hg.python.org/cpython/rev/cba717fa8e10

New changeset 537608bafa5a by Martin Panter in branch '3.5':
Issue #26309: Rewrite test in main thread and avoid race condition
https://hg.python.org/cpython/rev/537608bafa5a

New changeset c791d57c8168 by Martin Panter in branch 'default':
Issue #26309: Merge socketserver fix from 3.5
https://hg.python.org/cpython/rev/c791d57c8168

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Thu Feb 18 21:50:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 02:50:25 +0000
Subject: [issue5824] SocketServer.DatagramRequestHandler Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1455850225.02.0.0369470970284.issue5824@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch to enable the Unix domain DatagramRequestHandler tests, and bind the client to a socket name. Tests pass for me on Linux :)

The Python 2 version will need to have lowercase socketserver changed case to camel-case SocketServer.

----------
components: +Tests -Documentation
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2
Added file: http://bugs.python.org/file41964/bind-unix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________

From report at bugs.python.org  Thu Feb 18 21:54:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 02:54:44 +0000
Subject: [issue5824] SocketServer.DatagramRequestHandler Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1455850484.93.0.534844387992.issue5824@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed file: http://bugs.python.org/file41964/bind-unix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________

From report at bugs.python.org  Thu Feb 18 21:55:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 02:55:03 +0000
Subject: [issue5824] SocketServer.DatagramRequestHandler Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1455850503.56.0.768765846721.issue5824@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file41965/bind-unix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________

From report at bugs.python.org  Thu Feb 18 22:35:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Feb 2016 03:35:13 +0000
Subject: [issue15608] Improve socketserver doc
In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za>
Message-ID: <20160219033446.1705.29346@psf.io>


Roundup Robot added the comment:

New changeset 8b71cd67f548 by Martin Panter in branch '3.5':
Issue #15608: Improve socketserver module documentation
https://hg.python.org/cpython/rev/8b71cd67f548

New changeset fbb8b634fe59 by Martin Panter in branch 'default':
Issue #15608: Merge socketserver doc from 3.5
https://hg.python.org/cpython/rev/fbb8b634fe59

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15608>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:01:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Feb 2016 04:01:38 +0000
Subject: [issue15608] Improve socketserver doc
In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za>
Message-ID: <20160219040125.1715.65141@psf.io>


Roundup Robot added the comment:

New changeset 9211b7e60c92 by Martin Panter in branch '2.7':
Issue #15608: Improve socketserver module documentation
https://hg.python.org/cpython/rev/9211b7e60c92

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15608>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:04:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 04:04:09 +0000
Subject: [issue15608] Improve socketserver doc
In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za>
Message-ID: <1455854649.81.0.584024958812.issue15608@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15608>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:14:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Feb 2016 04:14:16 +0000
Subject: [issue16823] Python quits on running tkinter code with threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1455855256.46.0.501705176516.issue16823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If I understand the test code, it creates the tk window in thread 0 (the main thread), generates data in thread 1, sends data via a queue to thread 2, which then inserts it into the Text widget.  I ran a 3.x version up to 34000 iterations.  When I comment out 'tk.mainloop()' or stop the mainloop with ^C, thread 2 stops (reproducibly) with

Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\Programs\Python35\lib\threading.py", line 914, in _bootstrap_inner
    self.run()
  File "C:\Programs\Python35\lib\threading.py", line 862, in run
    self._target(*self._args, **self._kwargs)
  File "F:\Python\mypy\tem.py", line 23, in QueueHandler
    widinst.configure(state="normal")
  File "C:\Programs\Python35\lib\tkinter\__init__.py", line 1330, in configure
    return self._configure('configure', cnf, kw)
  File "C:\Programs\Python35\lib\tkinter\__init__.py", line 1321, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
RuntimeError: main thread is not in main loop

I removed the spamming of Shell with 'running' and sped up the test code by reducing the queued and inserted text to the iteration number and reran to completion at 999999.  I retract my statement about all widget access in threads being unsupported.  At least some seems to be at least in 3.x.

Running the original test code above in 2.7.11 from IDLE and console both fail before 2000 iterations in my tries.

Sarbjit: I do not understand 'tkinter wizard'.

Serhiy: I am coming back to this after reading #11077.  Do you have any idea why this code runs in 3.x but eventually fails in 2.x?  If there anything to do, or just close?

----------
nosy: +serhiy.storchaka -gpolo, roger.serwy
Added file: http://bugs.python.org/file41966/tem.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16823>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:14:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Feb 2016 04:14:39 +0000
Subject: [issue16823] Python quits on running tkinter code with threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1455855279.32.0.614205780363.issue16823@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.5 -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16823>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:24:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 04:24:04 +0000
Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch
 exiting exceptions
In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za>
Message-ID: <1455855844.58.0.678720595795.issue23430@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the reivew Berker. I have merged the patch with recent changes and updated according to your comments.

----------
Added file: http://bugs.python.org/file41967/socketserver-exit.v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23430>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:31:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 04:31:24 +0000
Subject: [issue26309] socketserver.BaseServer._handle_request_noblock()
 doesn't shutdown request if verify_request is False
In-Reply-To: <1454950713.49.0.94493423375.issue26309@psf.upfronthosting.co.za>
Message-ID: <1455856283.99.0.510808259289.issue26309@psf.upfronthosting.co.za>


Martin Panter added the comment:

The race depended on how whether serve_forever had a chance to hande the first request before the main thread told it to stop.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26309>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:54:15 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Feb 2016 04:54:15 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455857655.98.0.454595028125.issue26385@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> Does the unlink() work on Windows?

Yes. O_TEMPORARY opens the file with FILE_SHARE_DELETE, so unlink won't raise an error. 

Opening a file creates and returns a handle for a kernel File object that references the underlying file/link/stream control block in the file system. There may be multiple open File objects from separate NtCreateFile and NtOpenFile system calls, but they all reference a common file control block. Deleting a file requires a File handle, which is used to set the delete disposition in the control block. When all references (handle and pointer) to all File objects that reference the file are closed, the file is unlinked if the delete disposition is set.

The way delete-on-close works is to set a flag in the File object that causes the delete disposition to be automatically set when the File object is closed. However, any File handle that references the file can be used to set or unset this disposition if it has DELETE access. So it's harmless to manually call DeleteFile on the file (i.e. NtOpenFile and NtSetInformationFile to set the delete disposition) beforehand.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:18:51 2016
From: report at bugs.python.org (Florin Papa)
Date: Fri, 19 Feb 2016 07:18:51 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455866331.43.0.282967429589.issue26382@psf.upfronthosting.co.za>


Changes by Florin Papa <florin.papa at intel.com>:


----------
nosy: +florin.papa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:52:09 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Feb 2016 07:52:09 +0000
Subject: [issue26374] concurrent_futures Executor.map semantics better
 specified in docs
In-Reply-To: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>
Message-ID: <1455868329.9.0.19670303823.issue26374@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26374>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:56:09 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 19 Feb 2016 07:56:09 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455868569.12.0.683527199823.issue26385@psf.upfronthosting.co.za>


SilentGhost added the comment:

I wonder if Victor could clarify why bare except wasn't used in the python3 version.

Anyway, here is the updated patch testing for TypeError as well.

----------
nosy: +haypo
Added file: http://bugs.python.org/file41968/issue26385_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:58:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Feb 2016 07:58:01 +0000
Subject: [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <20160219075755.1669.19114@psf.io>


Roundup Robot added the comment:

New changeset 2d8e8d0e7162 by Georg Brandl in branch '2.7':
Closes #20169: fix inner links random doc.
https://hg.python.org/cpython/rev/2d8e8d0e7162

New changeset 426ac89548b3 by Georg Brandl in branch '3.5':
Closes #20169: fix inner links random doc.
https://hg.python.org/cpython/rev/426ac89548b3

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20169>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:59:55 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Feb 2016 07:59:55 +0000
Subject: [issue26374] concurrent_futures Executor.map semantics better
 specified in docs
In-Reply-To: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>
Message-ID: <1455868795.29.0.648783738168.issue26374@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I just noticed this point, which may be confusing things:

> Rebut: order is undefined, concurrent_futures specifies map() returns an iterator, where builtin map returns a list.

In Python 3, the built-in map function returns an iterator, not a list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26374>
_______________________________________

From report at bugs.python.org  Fri Feb 19 03:01:18 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Feb 2016 08:01:18 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455868878.85.0.545312504177.issue26366@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Here are the original descriptions of the old LaTeX version.

    \begin{macrodesc}{versionadded}{\op{explanation}\p{version}}
      The version of Python which added the described feature to the
      library or C API.  \var{explanation} should be a \emph{brief}
      explanation of the change consisting of a capitalized sentence
      fragment; a period will be appended by the formatting process.
      When this applies to an entire module, it should be placed at
      the top of the module section before any prose.
    \end{macrodesc}

    \begin{macrodesc}{versionchanged}{\op{explanation}\p{version}}
      The version of Python in which the named feature was changed in
      some way (new parameters, changed side effects, etc.).
      \var{explanation} should be a \emph{brief} explanation of the
      change consisting of a capitalized sentence fragment; a
      period will be appended by the formatting process.  This should
      not generally be applied to modules.
    \end{macrodesc}

Adding a parameter is explicitly a "versionchanged" kind of change.

Since the Sphinx items are supposed to be equivalent, this has always been the intention, even if the current devguide deviates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Fri Feb 19 03:30:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Feb 2016 08:30:12 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455870612.28.0.263992208913.issue26385@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I wonder if Victor could clarify why bare except wasn't used in the python3 version.

What do you call a "bare except"?

I wrote "except Exception: <cleanup code>; raise", it doesn't ignore the error. I want to always call the cleanup code on error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 03:49:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 08:49:48 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455871788.09.0.311801810664.issue26385@psf.upfronthosting.co.za>


Martin Panter added the comment:

Victor: You changed ?except Exception:? to bare ?except:? in revision 182f08c0dd45 in Python 2, but the Python 3 code never got such a change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 04:03:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Feb 2016 09:03:11 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455872591.58.0.661998259804.issue26385@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Victor: You changed ?except Exception:? to bare ?except:? in revision 182f08c0dd45 in Python 2, but the Python 3 code never got such a change.

Ah strange :-) Python 3 must also be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 04:11:41 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Feb 2016 09:11:41 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455873101.18.0.466574840225.issue26385@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy:  -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 04:20:12 2016
From: report at bugs.python.org (Catalin Gabriel Manciu)
Date: Fri, 19 Feb 2016 09:20:12 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455873612.78.0.77238069526.issue26382@psf.upfronthosting.co.za>


Catalin Gabriel Manciu added the comment:

Hi Victor,

This patch follows the same idea as your proposal, but it's focused on a single object type. I think doing this incrementally is the safer approach, allowing us to have finer control over the new 
areas where we enable allocating using the small object allocator and detect where this replacement might be detrimental to the performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 04:46:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Feb 2016 09:46:03 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455873612.78.0.77238069526.issue26382@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYw3z_+4b+U=CX4j8RVAw=GAxZyFBToUvQABBMVubJbLg@mail.gmail.com>


STINNER Victor added the comment:

Catalin Gabriel Manciu: "(...) allowing us to have finer control over
the new areas where we enable allocating using the small object
allocator and detect where this replacement might be detrimental to
the performance"

Ah, interesting, do you think that it's possible that my change can
*slow down* Python? I don't think so, but I'm interested on feedback
on my patch :-) You may try to run benchmarks with my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 05:34:08 2016
From: report at bugs.python.org (Daan Bakker)
Date: Fri, 19 Feb 2016 10:34:08 +0000
Subject: [issue26390] hashlib's pbkdf2_hmac documentation "rounds" does not
 match source
In-Reply-To: <1455840057.88.0.0946194046166.issue26390@psf.upfronthosting.co.za>
Message-ID: <1455878048.78.0.645893093503.issue26390@psf.upfronthosting.co.za>


Daan Bakker added the comment:

Good catch. I updated that reference now from rounds to iterations as well.

----------
Added file: http://bugs.python.org/file41969/pbkdf2_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26390>
_______________________________________

From report at bugs.python.org  Fri Feb 19 05:54:25 2016
From: report at bugs.python.org (Filipp Andjelo)
Date: Fri, 19 Feb 2016 10:54:25 +0000
Subject: [issue26387] Race condition in sqlite module
In-Reply-To: <1455818373.79.0.020961668279.issue26387@psf.upfronthosting.co.za>
Message-ID: <1455879265.15.0.665826411347.issue26387@psf.upfronthosting.co.za>


Filipp Andjelo added the comment:

Hm, this is strange, because close() can only be called from the same thread and dealloc() can be called only if reference count is 0, right? So why is there a mutex again each other anyway? And how can that be, that sqlite3_close() is called multiple times with the same pointer? We are getting a crash, which is only possible if dealloc() is called where close() is not yet done. Is this possible? Or do I understand something wrong? For such cases we also have to set database pointer to NULL in dealloc(), but it looks like the problem is somewhere different, the whole code looks strange for me.

----------
Added file: http://bugs.python.org/file41970/sqlite_connection.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26387>
_______________________________________

From report at bugs.python.org  Fri Feb 19 06:06:31 2016
From: report at bugs.python.org (Catalin Gabriel Manciu)
Date: Fri, 19 Feb 2016 11:06:31 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455879991.19.0.181057753079.issue26382@psf.upfronthosting.co.za>


Catalin Gabriel Manciu added the comment:

Theoretically, an object type that consistently allocates more than the small object threshold would perform a bit slower because
it would first jump to the small object allocator, do the size comparison and then jump to malloc. There would be a small overhead 
if PyMem_* would be redirected to PyObject_* in this (hypothetical) case and the initial choice of PyMem_* over PyObject_* might have 
been determined by knowing about that overhead. This is because many think of PyMem_* as the lower-level allocator, PyObject_* as a
higher-level one. Of course, PyMem_Raw* should be used in such cases, but it's not as widely adopted as the other two.

I will post some benchmark results on your issue page as soon as I get them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 06:12:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Feb 2016 11:12:45 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455880365.01.0.0599772710283.issue26382@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Theoretically, an object type that consistently allocates more than the small object threshold would perform a bit slower because it would first jump to the small object allocator, do the size comparison and then jump to malloc."

I expect that the cost of the extra check is *very* cheap (completly negligible) compared to the cost of a call to malloc().

To have an idea of the cost of the Python code around system allocators, you can take a look at the Performance section of my PEP 445 which added an indirection to all Python allocators:
https://www.python.org/dev/peps/pep-0445/#performances

I was unable to measure an overhead on macro benchmarks (perf.py). The overhead on microbenchmarks was really hard to measure because it was so low that benchmarks were very unable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 06:20:24 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Fri, 19 Feb 2016 11:20:24 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455880824.21.0.83996279813.issue26382@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
nosy: +alecsandru.patrascu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 06:52:22 2016
From: report at bugs.python.org (Kai Wohlfahrt)
Date: Fri, 19 Feb 2016 11:52:22 +0000
Subject: [issue26391] Specialized sub-classes of Generic never call __init__
Message-ID: <1455882742.53.0.118642694532.issue26391@psf.upfronthosting.co.za>


New submission from Kai Wohlfahrt:

A specialized sub-class of a generic type never calls __init__ when it is instantiated. See below for an example:

from typing import Generic, TypeVar

T = TypeVar('T')
class Foo(Generic[T]):
    def __init__(self, value: T):
        self.value = value

Bar = Foo[str]

foo = Foo('foo')
bar = Bar('bar')

print(type(foo), end=' ')
print(foo.value)

print(type(bar), end=' ')
print(bar.value) # AttributeError

I would expect Foo[str], Foo[int], etc to be equivalent to Foo at run-time. If this is not the case it might deserve an explicit mention in the docs. At the moment, behaviour is confusing because an instance of Foo is returned that does not have any of its attributes set.

----------
messages: 260519
nosy: Kai Wohlfahrt
priority: normal
severity: normal
status: open
title: Specialized sub-classes of Generic never call __init__
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26391>
_______________________________________

From report at bugs.python.org  Fri Feb 19 07:46:07 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 19 Feb 2016 12:46:07 +0000
Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch
 exiting exceptions
In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za>
Message-ID: <1455885967.98.0.864466905741.issue23430@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23430>
_______________________________________

From report at bugs.python.org  Fri Feb 19 10:02:25 2016
From: report at bugs.python.org (Tony R.)
Date: Fri, 19 Feb 2016 15:02:25 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ3CoG92ZXIg?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455894145.28.0.961044404724.issue26366@psf.upfronthosting.co.za>


Tony R. added the comment:

> Here are the original descriptions of the old LaTeX version.

Holy crap!  You all used to use LaTeX?!  :D  

(I know--LaTeX is still going strong in academia.  I just had no idea it was ever part of Python?s documentation, except as an output format.)

> Adding a parameter is explicitly a "versionchanged" kind of change.
> 
> Since the Sphinx items are supposed to be equivalent, this has always been the intention, even if the current devguide deviates.

Ah, okay.  

Well then, if this is the sort of place where the status quo is sacred, then there is nothing more to discuss.  

But if anyone reading this is open to the idea, please re-read my previous comment in this thread.  The quoted LaTeX docs are clear, but I still believe my ?all changes = (deprecated-removed changes) + (added changes) + (other changes)? interpretation makes more sense than the LaTeX definition.  

I also think it is more helpful to the *reader*--which, I respectfully suggest, should be the basis for any documentation?s guidelines--by marking up changes according to this grouping.

It?s not my desire to be troublesome by making one more appeal.  I simply want to point out that just because somebody wrote the LaTeX definitions a long time ago doesn?t mean that we cannot rewrite them.  They were written by somebody just like us, after all.  

If it?s not obvious by now, I feel strongly about good semantic markup.  The purpose of semantic markup is to describe what something *is*. I just think that changes form a hierarchy, with a generic ?change??as something of the base class, and ?deprecated?, ?removed?, and ?added??as specializations.

If you?re reading this, and you feel similarly--speak up!  

What do you think?


Respectfully,

?Tony

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Fri Feb 19 10:38:33 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 19 Feb 2016 15:38:33 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ0gb3ZlciA=?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455894145.28.0.961044404724.issue26366@psf.upfronthosting.co.za>
Message-ID: <CAFT4OTHXOCC2+yGP3jwqMXka3HS1Mq79NB4bHZR6Ukh91qHfDA@mail.gmail.com>


Fred L. Drake, Jr. added the comment:

On Fri, Feb 19, 2016 at 10:02 AM, Tony R. <report at bugs.python.org> wrote:
> Holy crap!  You all used to use LaTeX?!  :D

Python's documentation has a long & colorful history.  :-)

> Well then, if this is the sort of place where the status quo is sacred, then
> there is nothing more to discuss.

Status quo is not sacred, but does have some value.  Changing how busy
people do things is non-trivial.

> But if anyone reading this is open to the idea, please re-read my previous
> comment in this thread.  The quoted LaTeX docs are clear, but I still
> believe my ?all changes = (deprecated-removed changes) + (added
> changes) + (other changes)? interpretation makes more sense than the
> LaTeX definition.
>
> I also think it is more helpful to the *reader*--which, I respectfully suggest,
> should be the basis for any documentation?s guidelines--by marking up
> changes according to this grouping.

I think we all agree that the documentation is for the reader.

> It?s not my desire to be troublesome by making one more appeal.
> I simply want to point out that just because somebody wrote the
> LaTeX definitions a long time ago doesn?t mean that we cannot
> rewrite them.  They were written by somebody just like us, after all.

As the person who wrote them, I don't consider them sacred or
unchangeable.

Having some rational basis for whatever we use is good, and it should
be clearly documented clearly.

> If it?s not obvious by now, I feel strongly about good semantic markup.

We're on the same page here.

> The purpose of semantic markup is to describe what something *is*.
> I just think that changes form a hierarchy, with a generic ?change? as
> something of the base class, and ?deprecated?, ?removed?, and ?added?
> as specializations.

Again, agreed.  That doesn't imply that the specializations encompass
all changes, though.  For some, 'versionchanged' is reasonable.

Part of the problem is getting the granularity right.  The initial intent was
that 'version*' were annotations for the enclosing object (function, class,
method, etc.).  If we want to have something more granular (parameter
added / deprecated / whatever), we should have distinct markup for that.

That could look something like:

    .. parameteradded:: alternate 3.6
       Further explanation goes here.

It's helpful to think of these annotations as pronouns; the antecedent
needs to be clear before they can be interpreted correctly.  It sounds
like that needs to be clarified in the documentation, and possibly
provision added for a more fine-grained form of annotation.

  -Fred

----------
nosy: +fdrake
title: Use ?.. versionadded??over ?.. versionchanged? where appropriate -> Use ?.. versionadded? over ?.. versionchanged? where appropriate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Fri Feb 19 11:21:01 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Feb 2016 16:21:01 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ0gb3ZlciA=?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455898861.89.0.0788731685797.issue26366@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> Well then, if this is the sort of place where the status quo is sacred,
> then there is nothing more to discuss.  

That wasn't my intention when quoting the old documenting guide, it was just
to show what the intent was (and still is), and that I didn't just invent it.
As Fred says, the status quo is not sacred, but we are usually pragmatic and
a nontrivial amount of weight is needed to change it.

> But if anyone reading this is open to the idea, please re-read my previous
> comment in this thread.  The quoted LaTeX docs are clear, but I still
> believe my ?all changes = (deprecated-removed changes) + (added changes) +
> (other changes)? interpretation makes more sense than the LaTeX definition.

It's one interpretation, yes.  My interpretation (which coincides with the one
written back then by Fred) is that the versionchanged applies to the API item
in whose block it occurs.  And a function is not *added* by the addition of
a parameter, it is *changed* by that.  The parameter itself is not a marked-
up API item.  If the structure was like

.. function:: foo(a, b)
   .. parameter:: a
   .. parameter:: b

then adding a parameter c would definitely be marked up as

   .. parameter:: c
      .. versionadded: 3.x

Anyway.  You think your interpretation is better, others including myself
prefer the current one.  This is exactly the kind of argument where the 
status quo wins because the churn necessary to change is not justified.

> It?s not my desire to be troublesome by making one more appeal.  I simply
> want to point out that just because somebody wrote the LaTeX definitions a
> long time ago doesn?t mean that we cannot rewrite them.  They were written
> by somebody just like us, after all.  

Again, you're mistaking the reason I quoted them.

> If it?s not obvious by now, I feel strongly about good semantic markup.
> The purpose of semantic markup is to describe what something *is*. I just
> think that changes form a hierarchy, with a generic ?change? as something
> of the base class, and ?deprecated?, ?removed?, and ?added? as specializations.

That's a nice strawman -- we all feel semantic markup is important, and we
are talking about nothing but semantic markup here.  We're just discussing
the interpretation of one aspect of the semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Fri Feb 19 11:37:42 2016
From: report at bugs.python.org (Pas)
Date: Fri, 19 Feb 2016 16:37:42 +0000
Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports
 at top of file
In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za>
Message-ID: <1455899861.99.0.168173928648.issue23061@psf.upfronthosting.co.za>


Changes by Pas <pasthelod at gmail.com>:


----------
nosy: +pas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23061>
_______________________________________

From report at bugs.python.org  Fri Feb 19 11:44:59 2016
From: report at bugs.python.org (Oliver Ruiz Dorantes)
Date: Fri, 19 Feb 2016 16:44:59 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1455900299.37.0.196763591362.issue25668@psf.upfronthosting.co.za>


Oliver Ruiz Dorantes added the comment:

I am logging from a different thread than the thread which actually created the object. Though I am getting its reference in a very odd way

I can reproduce the following while is not a deadlock, I believe is related:

Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
    msg = self.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
    return fmt.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
    record.message = record.getMessage()
  File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
    msg = msg % self.args
TypeError: not all arguments converted during string formatting

----------
nosy: +Oliver Ruiz Dorantes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25668>
_______________________________________

From report at bugs.python.org  Fri Feb 19 12:00:17 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Fri, 19 Feb 2016 17:00:17 +0000
Subject: [issue26392] socketserver.BaseServer.close_server should stop
 serve_forever
Message-ID: <1455901217.04.0.582313607927.issue26392@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

Currently if you call server_close you only close the socket. If we  called serve_forever and then call server_close without calling shutdown the serve_forever loop keep running. Before using the selectors module for doing the poll we would have had exception thrown from the select (The socket fd is -1) in serve_forever.
IMO you should be able to call server_close at any time and expect it to stop the serve_forever. Maybe even adding a block option to server_close that will wait on the server_forever if it's running (waiting for issue 12463 to resolve before doing this).
Added a patch that closes serve_forever if server_close is called.

----------
components: Library (Lib)
files: socketserver_close_stop_serve_forever.patch
keywords: patch
messages: 260524
nosy: palaviv
priority: normal
severity: normal
status: open
title: socketserver.BaseServer.close_server should stop serve_forever
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41971/socketserver_close_stop_serve_forever.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26392>
_______________________________________

From report at bugs.python.org  Fri Feb 19 12:21:05 2016
From: report at bugs.python.org (Tony R.)
Date: Fri, 19 Feb 2016 17:21:05 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ0gb3ZlciA=?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455902465.65.0.490056045558.issue26366@psf.upfronthosting.co.za>


Tony R. added the comment:

> Part of the problem is getting the granularity right.  The initial intent was
> that 'version*' were annotations for the enclosing object (function, class,
> method, etc.).  If we want to have something more granular (parameter
> added / deprecated / whatever), we should have distinct markup for that.
> 
> That could look something like:
> 
>     .. parameteradded:: alternate 3.6
>        Further explanation goes here.
> 
> It's helpful to think of these annotations as pronouns; the antecedent
> needs to be clear before they can be interpreted correctly.

Isn?t language fun?!?!  *insane smile* 8)

> It sounds
> like that needs to be clarified in the documentation, and possibly
> provision added for a more fine-grained form of annotation.

Okay.  I can participate in the discussion of that, if it would help...but adding a completely new annotation type is outside my current ability to contribute.  


----

> > Well then, if this is the sort of place where the status quo is sacred,
> > then there is nothing more to discuss.  
> 
> That wasn't my intention when quoting the old documenting guide, it was just
> to show what the intent was (and still is), and that I didn't just invent it.

Your intent was clear to me!  I did not mean to say that you -- or anyone -- just invented it.  

I only know that mature projects (like Python) tend to hold more strongly to the status quo, and that I was advocating a change that was probably going to be an uphill battle to convince others as worthwhile.

> That's a nice strawman -- we all feel semantic markup is important, and we
> are talking about nothing but semantic markup here.  We're just discussing
> the interpretation of one aspect of the semantics.

It was not my wish to set up a strawman.  (I have no formal training in logic, anyways; I?d probably screw it up if I deliberately tried!)  

The reason I was stressing semantic markup is because I anticipated resistance from the mindset of ?Ugh, I don?t want to deal with this tedious crap!?  I  wanted to emphasize semantic markup as something valuable -- worth making an effort for, even if it might appear tedious or trivial at first glance.  

----

That said, I think it?s time for me to bow out of this conversation.  I?ve never made a successful contribution to any part of Python, including the documentation.  There was some talk of updating the devguide or adding new annotations, so I hope that something good comes out of that!  But the issue patch is where my comfort level is right now, and it appears that it?s a no-go.

Thank you for your time, your consideration, and the discussion!

?Tony

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Fri Feb 19 12:37:14 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 19 Feb 2016 17:37:14 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ0gb3ZlciA=?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1455903434.77.0.47072571677.issue26366@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

Another reason to value the status-quo in this case is that this isn't just
a matter for the Python documentation; it's about the recommended usage for
the markup, which is used by many other packages.

Questions that should be discussed include:

1. Should we clarify the documentation for the current annotations to
   the intended use is more consistently understood, or should we leave
   it as-is?

2. Are other distinct kinds of annotations (such as per-parameter notes)
   needed?

   If so, we'll need to consider specific reader / information-content
   needs and determine how they should be marked using new constructs.

   This is independent of implementation, which is likely straightforward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Fri Feb 19 13:54:53 2016
From: report at bugs.python.org (Sam Yeager)
Date: Fri, 19 Feb 2016 18:54:53 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1455908093.19.0.0641041233143.issue26376@psf.upfronthosting.co.za>


Sam Yeager added the comment:

I've reverted to ActiveTcl 8.5.18. Issue persists.

Uploading screenshots before and after attempting to close root window.

----------
Added file: http://bugs.python.org/file41972/1 Before closing root window.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Fri Feb 19 13:55:02 2016
From: report at bugs.python.org (Sam Yeager)
Date: Fri, 19 Feb 2016 18:55:02 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1455908102.06.0.664392388897.issue26376@psf.upfronthosting.co.za>


Changes by Sam Yeager <samyeager at gmail.com>:


Added file: http://bugs.python.org/file41973/2 After closing root window.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Fri Feb 19 13:58:06 2016
From: report at bugs.python.org (tzickel)
Date: Fri, 19 Feb 2016 18:58:06 +0000
Subject: [issue21878] wsgi.simple_server's wsgi.input read/readline waits
 forever in certain circumstances
In-Reply-To: <1403937301.18.0.584032434522.issue21878@psf.upfronthosting.co.za>
Message-ID: <1455908286.72.0.148009836972.issue21878@psf.upfronthosting.co.za>


tzickel added the comment:

Just encountered this issue as well.

It's not related to newlines, but to not supporting HTTP or persistent connections (the wsgi.input is the socket's I/O directly, and if the client serves a persistent connection, then the .read() will block forever).

A simple solution is to use a saner wsgi server (gevent works nicely).
Here is their implmentation of the socket I/O wrapper class (Input), and it's read/readlines functions:
https://github.com/gevent/gevent/blob/a65501a1270c1763e9de336a9c3cf52081223ff6/gevent/pywsgi.py#L303

----------
nosy: +tzickel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21878>
_______________________________________

From report at bugs.python.org  Fri Feb 19 13:59:02 2016
From: report at bugs.python.org (Sam Yeager)
Date: Fri, 19 Feb 2016 18:59:02 +0000
Subject: [issue26377] Tkinter dialogs will not close if root window not packed.
In-Reply-To: <1455721620.42.0.0590186130956.issue26377@psf.upfronthosting.co.za>
Message-ID: <1455908342.83.0.707690553529.issue26377@psf.upfronthosting.co.za>


Changes by Sam Yeager <samyeager at gmail.com>:


Added file: http://bugs.python.org/file41974/1 Before closing window and box.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26377>
_______________________________________

From report at bugs.python.org  Fri Feb 19 13:59:16 2016
From: report at bugs.python.org (Sam Yeager)
Date: Fri, 19 Feb 2016 18:59:16 +0000
Subject: [issue26377] Tkinter dialogs will not close if root window not packed.
In-Reply-To: <1455721620.42.0.0590186130956.issue26377@psf.upfronthosting.co.za>
Message-ID: <1455908356.96.0.509260488429.issue26377@psf.upfronthosting.co.za>


Changes by Sam Yeager <samyeager at gmail.com>:


Added file: http://bugs.python.org/file41975/2 After closing window and box.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26377>
_______________________________________

From report at bugs.python.org  Fri Feb 19 14:32:21 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Fri, 19 Feb 2016 19:32:21 +0000
Subject: [issue26393] random.shuffled
Message-ID: <1455910341.76.0.914915111625.issue26393@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

I am suggesting adding random.shuffled to the random module. This is very similar to the shuffle function just return a new shuffled list instead of in place shuffle. This is very similar to the sorted and list.sort.

As you can see in the patch the shuffled function just return random.sample(x, len(x)) as this is what i usually do when i want to get back a shuffled list.

----------
components: Library (Lib)
files: random-shuffled.patch
keywords: patch
messages: 260529
nosy: mark.dickinson, palaviv, rhettinger
priority: normal
severity: normal
status: open
title: random.shuffled
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41976/random-shuffled.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26393>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:06:40 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 19 Feb 2016 22:06:40 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1455919600.97.0.0728294278545.issue25668@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

@Oliver Ruiz Dorantes I don't see how yuou reach that conclusion from what you're showing - it just looks like s mismatch bertween format string and arguments. If you can shrink it down to a small standalone script that demonstrates the problem, it would be helpful for diagnosis; the stack trace you provide isn't enough for this, as I have seen similar traces many a time due to mismatched format string and arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25668>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:15:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 22:15:11 +0000
Subject: [issue5715] listen socket close in
 SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1455920111.34.0.903885607085.issue5715@psf.upfronthosting.co.za>


Martin Panter added the comment:

Replying to Donghyun?s last message, I understand UDPServer is derived from the TCPServer, so it would inherit TCPServer.server_close(), and therefore would close the one and only UDP socket. I think you may have to add a new prepare_child() method, or add a special case somewhere for forked TCP (or stream) servers.

----------
nosy: +martin.panter
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:41:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 22:41:38 +0000
Subject: [issue26392] socketserver.BaseServer.close_server should stop
 serve_forever
In-Reply-To: <1455901217.04.0.582313607927.issue26392@psf.upfronthosting.co.za>
Message-ID: <1455921698.98.0.562564478128.issue26392@psf.upfronthosting.co.za>


Martin Panter added the comment:

I thought the purpose of server_close() was to clean up resources after you have finished calling serve_forever() or handle_request(). Just like you call close() on a file after you have finished reading or writing it. If you try to read or write a closed file, that is a programmer error.

This proposal sounds like a new feature, but you are overloading or redefining the purpose of server_close().

>From the test case I presume you intend to use server_close() in a separate thread from the thread running serve_forever(). But closing a file descriptor while it is being used in another thread does not seem robust to me. It could cause serve_forever() to raise EBADF. In the worst case, consider what happens if an unrelated third thread makes the server?s file descriptor valid again by opening a file.

What is your use case? If you want to use multithreading, why can?t you use the shutdown() method? For a single-threaded server, maybe see Issue 13749, and maybe Issue 23430 would help by allowing exceptions like SystemExit to stop the server.

----------
nosy: +martin.panter
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26392>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:48:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 22:48:14 +0000
Subject: [issue1429] FD leak in SocketServer when request handler throws
 exception
In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za>
Message-ID: <1455922094.54.0.465993298087.issue1429@psf.upfronthosting.co.za>


Martin Panter added the comment:

Jeff has tried many times over two years to produce the originally reported bug without success. By code inspection, I cannot see how a request handler exception could cause a leak. Therefore I am closing this as ?works for me?.

Working backwards from all the spurious version changes (I wish people wouldn?t do that!), I figure that this was originally opened against Python 2.4 only. It is possible that the bug got fixed in the meantime.

For the question of coping with exceptions from handle_error(), the change proposed in Issue 25139 should cover that.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1429>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:53:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Feb 2016 22:53:46 +0000
Subject: [issue13354] tcpserver should document non-threaded long-living
 connections
In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>
Message-ID: <1455922426.52.0.129437482285.issue13354@psf.upfronthosting.co.za>


Martin Panter added the comment:

Bas: I think you need to provide more information. Are you talking about protocols like HTTP, where multiple high-level (HTTP-level) requests are made over a single low-level (socket-level) connection? Some example code might help.

Overriding shutdown_request() sounds like a bad idea. I think you eventually would want to truly shutdown the connection. Perhaps it is better to override process_request() and avoid it calling shutdown() until it is ready.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13354>
_______________________________________

From report at bugs.python.org  Fri Feb 19 18:24:36 2016
From: report at bugs.python.org (Sam Yeager)
Date: Fri, 19 Feb 2016 23:24:36 +0000
Subject: [issue26377] Tkinter dialogs will not close if root window not packed.
In-Reply-To: <1455721620.42.0.0590186130956.issue26377@psf.upfronthosting.co.za>
Message-ID: <1455924276.13.0.672001971512.issue26377@psf.upfronthosting.co.za>


Changes by Sam Yeager <samyeager at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26377>
_______________________________________

From report at bugs.python.org  Fri Feb 19 18:53:19 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Feb 2016 23:53:19 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455925999.85.0.598754916333.issue26351@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Great idea.  In Windows, closing the window with [x] will kill the process, at the cost of loosing its contents.  In IDLE's Shell, Restart Shell will do the same without killing IDLE, but it is easy to not know of or forget that option in a moment of panic.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Fri Feb 19 18:59:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Feb 2016 23:59:36 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455926376.79.0.976444550449.issue26351@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Great idea.  In Windows, closing the window with [x] will kill the process, at the cost of loosing its contents.

Note: after a few years, I heard that Windows supports something like SIGKILL: CTRL+Pause kills the current process ;-) You loose the process, but you don't have to close the terminal, confirm and reopen a new terminal, go back to your working directly, etc.

Note 2: Even more off-topic, type .~<enter> in an SSH session to kill it, again it avoids to reopen a terminal window ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:03:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 00:03:24 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1455926604.55.0.361122201056.issue26358@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +twouters
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:18:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Feb 2016 00:18:57 +0000
Subject: [issue22468] Tarfile using fstat on GZip file object
In-Reply-To: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za>
Message-ID: <20160220001853.1695.39846@psf.io>


Roundup Robot added the comment:

New changeset 94a94deaf06a by Martin Panter in branch '3.5':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/94a94deaf06a

New changeset e66c476b25ec by Martin Panter in branch 'default':
Issue #22468: Merge gettarinfo() doc from 3.5
https://hg.python.org/cpython/rev/e66c476b25ec

New changeset 9d5217aaea13 by Martin Panter in branch '2.7':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/9d5217aaea13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22468>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:18:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Feb 2016 00:18:58 +0000
Subject: [issue21996] gettarinfo method does not handle files without text
 string names
In-Reply-To: <1405583528.37.0.553699872308.issue21996@psf.upfronthosting.co.za>
Message-ID: <20160220001853.1695.88984@psf.io>


Roundup Robot added the comment:

New changeset 94a94deaf06a by Martin Panter in branch '3.5':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/94a94deaf06a

New changeset 9d5217aaea13 by Martin Panter in branch '2.7':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/9d5217aaea13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21996>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:18:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Feb 2016 00:18:59 +0000
Subject: [issue22208] tarfile can't add in memory files (reopened)
In-Reply-To: <1408145357.61.0.947327827691.issue22208@psf.upfronthosting.co.za>
Message-ID: <20160220001853.1695.89769@psf.io>


Roundup Robot added the comment:

New changeset 94a94deaf06a by Martin Panter in branch '3.5':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/94a94deaf06a

New changeset 9d5217aaea13 by Martin Panter in branch '2.7':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/9d5217aaea13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22208>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:19:36 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 00:19:36 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1455927576.33.0.240108500473.issue26367@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Manuel, welcome to the tracker and thank you for submitting patches.  I agree that 5 lines is past the threshhold.  Your profile has been CLA-updated, so we are good to go.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:26:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 00:26:53 +0000
Subject: [issue22468] Tarfile using fstat on GZip file object
In-Reply-To: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za>
Message-ID: <1455928013.33.0.946103577346.issue22468@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hoping my clarification in the documentation is enough to call this fixed

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22468>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:27:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 00:27:16 +0000
Subject: [issue21996] gettarinfo method does not handle files without text
 string names
In-Reply-To: <1405583528.37.0.553699872308.issue21996@psf.upfronthosting.co.za>
Message-ID: <1455928036.47.0.710626654282.issue21996@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21996>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:29:23 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 00:29:23 +0000
Subject: [issue26369] doc for unicode.decode and str.encode is unnecessarily
 confusing
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1455928163.86.0.214801783855.issue26369@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The intended use for str.encode is for same-type transcoding, like this:

I was unaware of the seemingly useless behavior you quote.

>>> 'abc'.encode('base64')
'YWJj\n'
>>> 'YWJj\n'.decode('base64')
'abc'

Here is a similar use for unicode.decode.

>>> u'abc'.encode('base64')
'YWJj\n'
>>> u'YWJj\n'.decode('base64')
'abc'

Any doc change should make the intended use clear if not already.

(Note that the above give lookup errors in 3.x
>>> 'abc'.encode('base64')
...
LookupError: 'base64' is not a text encoding; use codecs.encode() to handle arbitrary codecs)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:35:02 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 00:35:02 +0000
Subject: [issue26375] Python 2.7.10 and 3.4.4 hang on imaplib.IMAP4_SSL()
In-Reply-To: <1455716357.67.0.858374272161.issue26375@psf.upfronthosting.co.za>
Message-ID: <1455928502.93.0.798255922429.issue26375@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

where was the 'RC4 cipher' removed from.  Do you know the issue or commit that did so?

----------
keywords: +3.4regression
nosy: +terry.reedy
stage:  -> test needed
title: New versions of Python hangs on imaplib.IMAP4_SSL() -> Python 2.7.10 and 3.4.4 hang on imaplib.IMAP4_SSL()
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26375>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:45:05 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 00:45:05 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1455929105.7.0.478932277242.issue26376@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

No problem on Windows either, where the minimum window width is wide enough to acommodate all 3 frame buttons (-  []  X).

Please run your test.py directly, either in the terminal or however else one does so on OSX, without IDLE, to make absolutely sure that IDLE has no effect on the behavior.  (It really ought not to.)

----------
components:  -IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:53:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 00:53:21 +0000
Subject: [issue26377] Tkinter dialogs will not close if root window not packed.
In-Reply-To: <1455721620.42.0.0590186130956.issue26377@psf.upfronthosting.co.za>
Message-ID: <1455929601.58.0.131918046456.issue26377@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Try adding 'parent=rootWin' to the messagebox call.  Otherwise, I expect that this is, as far as cause, a duplicate of #2637, in which case my comment https://bugs.python.org/issue26376#msg260544 applies.

----------
components:  -IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26377>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:56:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 00:56:51 +0000
Subject: [issue26379] zlib decompress as_bytearray flag
In-Reply-To: <1455768500.67.0.379084833673.issue26379@psf.upfronthosting.co.za>
Message-ID: <1455929811.17.0.181196558465.issue26379@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +nadeem.vawda, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26379>
_______________________________________

From report at bugs.python.org  Fri Feb 19 20:49:31 2016
From: report at bugs.python.org (Bas Wijnen)
Date: Sat, 20 Feb 2016 01:49:31 +0000
Subject: [issue13354] tcpserver should document non-threaded long-living
 connections
In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>
Message-ID: <1455932971.07.0.292034759334.issue13354@psf.upfronthosting.co.za>


Bas Wijnen added the comment:

For example, I have some programs which are HTTP servers that implement WebSockets.  For regular web page requests, it is acceptable if the connection is closed after the page is sent.  But for a WebSocket it isn't: the whole point of that protocol is to allow the server to send unsolicited messages to the browser.  If the connection is closed, it cannot do that.  The documentation currently suggests that the only way to avoid handle() closing the connection is to not return.  That means that the only way to do other things is by using multi-processing or (shiver) multi-threading.

My suggestion is to add a short explanation about how connections can be kept open after handle() returns, so that a single threaded event loop can be used.  Of course the socket must then be manually closed when the program is done with it.

If I understand you correctly, overriding process_request would allow handle() to return without closing the socket.  That does sound better than overriding shutdown_request.

In the current documentation (same link as before, now for version 3.5.1), there is no mention at all about close() or shutdown() of the accepted sockets.  The only information on the subject is that if you want asynchronous handling of data, you must start a new thread or process.  This is not true, and in many cases it is not what I would recommend.  I think event loops are much easier to maintain and debug than multi-process applications, and infinitely easier than multi-threading applications.  I don't mind that other people disagree, and I'm not suggesting that those ways of handling should be removed (multi-process has its place, and I can't convince everyone that multi-threading is evil).  What I'm saying is that the ability to use an event loop to handle asynchronous data with this class deserves to be mentioned as well.

Obviously, it does then need to have the explanation about what to override to make it work.  My suggestion is simply what I ended up with after seeing it fail and reading the code.  If what you describe is the recommended way, please say that instead.  My point is that the scenario should presented as an option, I don't have an opinion on what it should say.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13354>
_______________________________________

From report at bugs.python.org  Fri Feb 19 21:14:28 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 02:14:28 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455934468.67.0.829833344446.issue26380@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If I were deciding, I would be inclined to reject this.  Part of the understanding when enums were added was that they would not automatically be used in the stdlib anywhere there could be used.

To answer 'why not', there is an obvious gain to naming arbitrary numerical code, as with HTTPStatus.xyz.  I do not see any gain from replacing 'GET'*  with HTTPMethod.GET.  Just more work to write and read.

*Does http require uppercase for the methods?

To answer 'best practice',  I disagree with the premise that 'hardcoding' such short meaningful names is bad.  I think that this is a mis-application of a sometimes valid principle.

If people who do like such replacements are changing spellings, other than to lower case the words (enum value do not have to be uppercase), in the process, shame on them. Otherwise, typing HTTPMethod.OPTIONS is harde to type correctly, not easier, than 'OPTIONS'.  If you posted evidence as to your claim, I might be more favorably inclined.  On the other hand, if everyone used the quoted strings, 'GET', etc, there would be no problem with inconsistency.

My personal experience with turning constant strings into constant names is with tkinter, which has about 50 assignments like "E = 'e'", "RAISED = 'raised'", and so on.  I consider them more a nuisance than a help.  CAPS are harder to type than letters, and they give TOO MUCH EMPHASIS to rather minor configuration issues.  If one does 'import tkinter' or 'import tkinter as tk' instead of 'from tkinter import *', then "relief=tk.RAISED" is definitely harder to write as "relieve='raised'", and to me uglier.

To me, your later throw-in comment about static analyzers might be the most persuasive point you made

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Fri Feb 19 21:20:08 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 02:20:08 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1455934808.84.0.493777194933.issue26382@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My impression is that we do not do such performance enhancements to 2.7 for the same reason we would not do them to current 3.x -- the risk of breakage.  Have I misunderstood?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 21:40:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 02:40:26 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455936026.36.0.474182843215.issue26385@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

`except:` is equivalent to `except BaseException:`.  When I introduced the former into idlelib, a couple of years ago, I was told to do the latter in a follow-up patch, so that there would be no doubt as to the intent.  The same should be done here.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:04:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Feb 2016 03:04:20 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455934808.84.0.493777194933.issue26382@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwai=RURrw8Tvt6D=O-ZCAbh1Q01beeh=ex1H0_WGkxbDQ@mail.gmail.com>


STINNER Victor added the comment:

Terry J. Reedy added the comment:
> My impression is that we do not do such performance enhancements to 2.7 for the same reason we would not do them to current 3.x -- the risk of breakage.  Have I misunderstood?

Breakage of what? The change looks very safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:05:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Feb 2016 03:05:18 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455936026.36.0.474182843215.issue26385@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb6qXPf8DJdmeiis3T4CdFLWsNoXF=syAn+F5bLvdn7_Q@mail.gmail.com>


STINNER Victor added the comment:

I prefer "except:" over "except BaseException:". What is the benefit
of passing explicitly BaseException?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:08:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 03:08:36 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1455937716.5.0.52900155902.issue26380@psf.upfronthosting.co.za>


Martin Panter added the comment:

The RFC for HTTP says the method is case-sensitive, although I have seen one person use lowercase (probably by accident). So ?over the wire? it has to be uppercase b"GET".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:44:14 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 03:44:14 +0000
Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle
In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za>
Message-ID: <1455939854.96.0.645533121858.issue26386@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The 3.5 version of 2015 Dec 6 is 3.5.1. A traceback is not a crash for the purpose of this tracker.

It is generally a good idea to mention OS, OS version, and Tk Version. (IDLE displays TkVersion in Help => About IDLE.)  However, on Win 10 (8.6.4), I was able to reproduce with all four of the .selection_xyz(items) methods, which are all specializations of the .selection(op, items) methods.

import tkinter as tk
from tkinter import ttk
root = tk.Tk()
tree = ttk.Treeview(root)
tree.pack()
tree.insert('', 1, iid='a b', text='id with space')
for item in tree.get_children():
    print(item)
    #tree.selection_add(item)  # fail
    #tree.selection_toggle(item)  # fail
    #tree.selection_set(item)  # fail
    #tree.selection_remove(item)  # fail
    tree.selection('add', item)  # fail

getting

a b
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 10, in <module>
    tree.selection_toggle(item)
  File "C:\Programs\Python35\lib\tkinter\ttk.py", line 1415, in selection_toggle
    self.selection("toggle", items)
  File "C:\Programs\Python35\lib\tkinter\ttk.py", line 1395, in selection
    return self.tk.call(self._w, "selection", selop, items)
_tkinter.TclError: Item a not found

tkinter 


These are the only Treeview methods in which a single argument can be multiple items.  The doc string and doc do not define the form of 'items'.  The unofficial but generally helpful doc, http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Treeview.html says "The argument may be either a single iid or a sequence of iids."  I would expect sequence mean a tuple of strings, not space-separated fields in a string (a tcl sequence).

The .delete and .detach methods have signature '*items', meaning that each item is passed as a separate argument.  The methods them pass the tuple of strings to tk.  This should have been the signature of the selection methods.

Putting a single string in a tuple solves the problem, as in.

    tree.selection('add', (item,))

My suggested fix is to add a statement to .selection

    def selection(self, selop=None, items=None):
        """If selop is not specified, returns selected items."""
        if isinstance(items, str):  # new
            items = (items,)
        return self.tk.call(self._w, "selection", selop, items)

----------
nosy: +serhiy.storchaka, terry.reedy
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26386>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:45:17 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 03:45:17 +0000
Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle
In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za>
Message-ID: <1455939917.18.0.216916378209.issue26386@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26386>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:54:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 03:54:51 +0000
Subject: [issue26389] Expand traceback module API to accept just an exception
 as an argument
In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za>
Message-ID: <1455940491.11.0.696473890918.issue26389@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You title and post don't seem to match.  The title says to expand the API and the post says there is no reason to expand the API.  Did you mean 'good reason'?  Also, I think you meant 'grab the traceback' (from the exception) rather than 'grab the exception'.

How would you get from here to there and change required etype, value, tb to just required value, without breaking old code?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26389>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:55:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 03:55:50 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455940550.73.0.712086764938.issue26385@psf.upfronthosting.co.za>


Martin Panter added the comment:

Eryk Sun: The patch proposes to add an unlink() call after the file has been closed:

except Exception:
    _os.close(fd)  # This automatically deletes the file right?
    _os.unlink(name)  # Won?t this raise FileNotFoundError?
    raise

By your explanation, it sounds like it would be better to call unlink() before close().

Terry & Victor: Writing the explicit ?except BaseException:? makes it clear you weren?t being lazy in figuring out what exceptions you want to catch. But in this case the ?raise? at the end of the the exception handler make it clear enough for me. I would be happy with either option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:59:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 03:59:47 +0000
Subject: [issue26351] Occasionally check for Ctrl-C in long-running operations
 like sum
In-Reply-To: <1455299252.18.0.421982887455.issue26351@psf.upfronthosting.co.za>
Message-ID: <1455940787.77.0.460245962669.issue26351@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I verified that ^Break(pause) works.  It even causes ^C to be printed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26351>
_______________________________________

From report at bugs.python.org  Fri Feb 19 23:05:46 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Feb 2016 04:05:46 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455941146.14.0.638511234158.issue26385@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It makes it clearer that you know that it will 'everything' and intend to catch do so and that you did not casually toss in 'except:', as used to be the habit of many.  There are over 20 bare excepts in idlelib and I suspect many or most are unintentionally over-broad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Fri Feb 19 23:49:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 04:49:16 +0000
Subject: [issue13354] tcpserver should document non-threaded long-living
 connections
In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>
Message-ID: <1455943756.15.0.683571618612.issue13354@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the fast response!

There is a paragraph right at the end of <https://docs.python.org/3/library/socketserver.html#server-creation-notes> that mentions this technique: ?. . . maintain an explicit table of partially finished requests . . .?. Perhaps that is the suggestion that you couldn?t find before.

I once wrote an RTSP proxy that uses a related technique. It still handles each high-level RSTP request or RTP packet synchronously, but uses the ?selectors? module to switch between the various connections and listening sockets after each high-level request had been handled. Code at <https://repo.or.cz/python-iview.git/blob/refs/heads/rtsp:/iview/utils.py#l318>.

Do you want to propose some specific additions or a patch to the documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13354>
_______________________________________

From report at bugs.python.org  Sat Feb 20 00:12:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 05:12:44 +0000
Subject: [issue26389] Expand traceback module API to accept just an exception
 as an argument
In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za>
Message-ID: <1455945164.61.0.437598848555.issue26389@psf.upfronthosting.co.za>


Martin Panter added the comment:

There is precedent with Python 2?s ?raise? statement for accepting an exception instance for the first parameter (where an exception class would otherwise be passed). Also, generator.throw() supports this; see Issue 14911 for clarifying its documentation.

I would support changing the following signatures so that the first parameter could hold the value, not just the type:

print_exception(etype, value=None, tb=None, limit=None, ...)
format_exception_only(etype, value=None)
format_exception(etype, value=None, tb=None, limit=None, ...)
TracebackException(exc_type, exc_value=None, exc_traceback=None, *, ...)

----------
nosy: +martin.panter
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26389>
_______________________________________

From report at bugs.python.org  Sat Feb 20 01:24:20 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 20 Feb 2016 06:24:20 +0000
Subject: [issue13354] tcpserver should document non-threaded long-living
 connections
In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>
Message-ID: <1455949460.95.0.709806570589.issue13354@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13354>
_______________________________________

From report at bugs.python.org  Sat Feb 20 01:42:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 06:42:06 +0000
Subject: [issue4928] Problem with tempfile.NamedTemporaryFile
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1455950526.0.0.394710592496.issue4928@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am surprised at the report that Red Hat Linux automatically removed the file. What system calls are involved? On my Arch Linux setup with current 3.6 code it leaves the file behind (same as the Solaris report).

However the the Windows version does automatically deleting the file once all file handles are closed:

# Setting O_TEMPORARY in the flags causes the OS to delete
# the file when it is closed.  This is only supported by Windows.

Perhaps this behaviour should be documented.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4928>
_______________________________________

From report at bugs.python.org  Sat Feb 20 02:45:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 07:45:21 +0000
Subject: [issue26261] NamedTemporaryFile documentation is vague about the
 `name` attribute
In-Reply-To: <1454347282.51.0.892341568817.issue26261@psf.upfronthosting.co.za>
Message-ID: <1455954321.87.0.238022530474.issue26261@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is my proposed patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41977/tempfile-name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26261>
_______________________________________

From report at bugs.python.org  Sat Feb 20 03:48:52 2016
From: report at bugs.python.org (Bas Wijnen)
Date: Sat, 20 Feb 2016 08:48:52 +0000
Subject: [issue13354] tcpserver should document non-threaded long-living
 connections
In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>
Message-ID: <1455958132.05.0.649668055813.issue13354@psf.upfronthosting.co.za>


Bas Wijnen added the comment:

Thank you for your fast response as well.

I overlooked that paragraph indeed.  It doesn't mention anything about avoiding a socket shutdown however.  Keeping a list of requests isn't very useful if all the sockets in the list are closed. ;-)

So I would indeed suggest an addition: I would change this paragraph:

These four classes process requests synchronously; each request must be completed before the next request can be started. This isn?t suitable if each request takes a long time to complete, because it requires a lot of computation, or because it returns a lot of data which the client is slow to process. The solution is to create a separate process or thread to handle each request; the ForkingMixIn and ThreadingMixIn mix-in classes can be used to support asynchronous behaviour.

into:

By default, these four classes process requests synchronously; each request must be completed before the next request can be started. This isn?t suitable if each request takes a long time to complete, because it requires a lot of computation, or because it returns a lot of data which the client is slow to process, or because the information that should be sent to the client isn't available yet when the request is made. One possible solution is to create a separate process or thread to handle each request; the ForkingMixIn and ThreadingMixIn mix-in classes can be used to support asynchronous behaviour. Another option is to store the socket for later use, and disable the shutting down of the socket by overriding process_request with an function that only calls finish_request, and not shutdown_request. In that case, the socket must be shut down by the program when it is done with it.

At the end of the last paragraph you refer to, it should also be mentioned that the program must do something to prevent the socket from being shut down.  In the description of process_request, it would probably also be useful to add that the default implementation (as opposed to *MixIn) calls shutdown_request() after finish_request().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13354>
_______________________________________

From report at bugs.python.org  Sat Feb 20 04:20:10 2016
From: report at bugs.python.org (Ian Kelly)
Date: Sat, 20 Feb 2016 09:20:10 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1455960010.55.0.106913900946.issue26221@psf.upfronthosting.co.za>


Ian Kelly added the comment:

Chris Angelico suggested on python-list that another possibly useful thing to do would be to add a "from __future__ import generator_stop" to asyncio/futures.py. This would at least have the effect of causing "await future" to raise a RuntimeError instead of silently returning None if a StopIteration is set on the future. Future.__iter__ is the only generator in the file, so this change shouldn't have any other effects.

----------
title: asynco run_in_executor swallows StopIteration -> awaiting asyncio.Future swallows StopIteration

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sat Feb 20 05:15:19 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 20 Feb 2016 10:15:19 +0000
Subject: [issue26392] socketserver.BaseServer.close_server should stop
 serve_forever
In-Reply-To: <1455901217.04.0.582313607927.issue26392@psf.upfronthosting.co.za>
Message-ID: <1455963319.43.0.297018484338.issue26392@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I see your point about the server_close purpose and I changed the patch to simulate the behavior of closed file (raising ValueError when operating on closed file).
I don't think that this should be an enhancement as what i try to do is return the behavior as it was before the change to the selectors module. When closing the socket using server_close at the next serve_forever loop you would have gotten ValueError for bad file descriptor to select. In the current implementation we actually keep on pulling on a already free resource.
I know that the user should call shutdown before the server_close but i think that as you said the behavior should simulate closed file. When someone will try to use any other function of a closed file he will receive a ValueError.

----------
Added file: http://bugs.python.org/file41978/socketserver_close_stop_serve_forever2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26392>
_______________________________________

From report at bugs.python.org  Sat Feb 20 09:00:46 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Feb 2016 14:00:46 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455976846.59.0.0876817555184.issue26385@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> By your explanation, it sounds like it would be better 
> to call unlink() before close().

Sorry, I was responding in general, because I thought you meant unlink would fail like it would for most open files on Windows, because the CRT normally doesn't open files with delete sharing. But I see what you meant now. Yes, the order needs to be reversed as unlink() and then close() for this to work. Doing the close first does raise a FileNotFoundError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Sat Feb 20 09:23:43 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Feb 2016 14:23:43 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1455978223.56.0.530888284147.issue26385@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the updated patch including fixes for except and order of deletion.

----------
Added file: http://bugs.python.org/file41979/issue26385_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Sat Feb 20 10:53:56 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 20 Feb 2016 15:53:56 +0000
Subject: [issue4928] Problem with tempfile.NamedTemporaryFile
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1455983636.59.0.716145432887.issue4928@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Maybe a note could be added to suggest using a SIGTERM signal handler (e.g. the handler could raise a SIGTERM exception):

POSIX: The file will not be deleted if the process is terminated abruptly by a signal. A process may register a SIGTERM handler to ensure that the file is deleted, but SIGKILL cannot be handled. Windows: the file will be deleted when it is closed, even if the process is terminated.

Note that for Windows it is possible to make the file permanent, but it's probably not common enough to bother with documenting this. Currently the documentation states that "[w]hether the name can be used to open the file a second time, while the named temporary file is still open, varies across platforms (it can be so used on Unix; it cannot on Windows NT or later)". Actually on Windows the file can be opened again while the named temporary file is still open. You can use an opener that calls os.open with the O_TEMPORARY flag. But the opener can also call _winapi.CreateFile with read, write, and delete sharing. If DELETE access is requested this handle can be used to make the file permanent via SetFileInformationByHandle.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eryksun
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4928>
_______________________________________

From report at bugs.python.org  Sat Feb 20 11:17:11 2016
From: report at bugs.python.org (Michael Herold)
Date: Sat, 20 Feb 2016 16:17:11 +0000
Subject: [issue26394] argparse: Add set_values() function to complement
 set_defaults()
Message-ID: <1455985031.95.0.488150837583.issue26394@psf.upfronthosting.co.za>


New submission from Michael Herold:

argparse has at least three features to set defaults (default=, set_defaults(),  argument_default=). However, there is no feature to set the values of arguments.

The difference is, that a required argument has to be specified, also if a default value exists. Thus, a clean way to set values from config files or env variables does not exist without making all arguments optional.

See for example <http://stackoverflow.com/questions/10551117/setting-options-from-environment-variables-when-using-argparse>, where it becomes clear that no general solution for all actions exists. As a result, people also start to mess around with the args parameter of parse_args(). Even ConfigArgParse (used by Let's Encrypt) seems to fail in doing this properly.

So please add a set_values() function, similar to set_defaults(). The predefined value should be treated as if it had been entered on the command line. If the value has also been supplied via the command line, the predefined value is overwritten.

----------
components: Library (Lib)
messages: 260568
nosy: quabla
priority: normal
severity: normal
status: open
title: argparse: Add set_values() function to complement set_defaults()
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26394>
_______________________________________

From report at bugs.python.org  Sat Feb 20 13:14:00 2016
From: report at bugs.python.org (Jonathan Goble)
Date: Sat, 20 Feb 2016 18:14:00 +0000
Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern
 object
In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za>
Message-ID: <1455992040.42.0.154404191889.issue26336@psf.upfronthosting.co.za>


Jonathan Goble added the comment:

Noting for the record that, as I had brought up on python-ideas [1], in addition to simply exposing the raw code, it would be nice to have a public constructor for the compiled pattern type and a 'dis'-like module for support. The former would enable optimizers, and the latter would simplify programmatic analysis.

[1] https://mail.python.org/pipermail/python-ideas/2016-February/thread.html#38488

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26336>
_______________________________________

From report at bugs.python.org  Sat Feb 20 13:24:14 2016
From: report at bugs.python.org (Martin Morrison)
Date: Sat, 20 Feb 2016 18:24:14 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <1455992654.66.0.84827056769.issue25913@psf.upfronthosting.co.za>


Martin Morrison added the comment:

3.patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25913>
_______________________________________

From report at bugs.python.org  Sat Feb 20 14:48:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Feb 2016 19:48:08 +0000
Subject: [issue26389] Expand traceback module API to accept just an exception
 as an argument
In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za>
Message-ID: <1455997688.77.0.877336911581.issue26389@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So Terry's right that in my haste to write down the idea I contradicted myself. I do want to tweak the APIs in the traceback module to accept only an exception. The question is whether we need entirely new functions or if the pre-existing ones can be updated to work with just an exception.

And if we were to tweak the existing functions instead of add new ones, I would do it by making all arguments optional and adding a new keyword-only argument called `exc` that took the exception. Either `exc` would be set or the old arguments would need to all be set, and it would be an error to set both sets of arguments. And when the old arguments were taken away then all arguments for those functions would become keyword-only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26389>
_______________________________________

From report at bugs.python.org  Sat Feb 20 15:10:27 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Feb 2016 20:10:27 +0000
Subject: [issue26394] argparse: Add set_values() function to complement
 set_defaults()
In-Reply-To: <1455985031.95.0.488150837583.issue26394@psf.upfronthosting.co.za>
Message-ID: <1455999027.22.0.0786229390613.issue26394@psf.upfronthosting.co.za>


Brett Cannon added the comment:

To paraphrase Michael, he wants a way to tell argparse that an argument has to be supplied either from the command-line or some other mechanism (e.g., envvar, config file, etc.), but that if the value cannot be found in either situation, argparse fails saying the value is missing. This is different from a default value and making something optional as argparse has no way to signal that a default value isn't available, forcing the user to do the actual check externally to argparse itself. All of this stems from the fact that argparse's default argument stuff happens prior to parsing sys.argv and determining what is missing.

What this probably requires is a new keyword-only argument like `fallback` which is a callable which is only called if an accompanying value isn't found from sys.argv and which can raise some specific exception to signal that the fallback value couldn't be determined on top of missing from sys.argv.

----------
nosy: +brett.cannon
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26394>
_______________________________________

From report at bugs.python.org  Sat Feb 20 15:10:56 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Feb 2016 20:10:56 +0000
Subject: [issue26394] Have argparse provide ability to require a fallback
 value be present
In-Reply-To: <1455985031.95.0.488150837583.issue26394@psf.upfronthosting.co.za>
Message-ID: <1455999056.26.0.739531381494.issue26394@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
title: argparse: Add set_values() function to complement set_defaults() -> Have argparse provide ability to require a fallback value be present

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26394>
_______________________________________

From report at bugs.python.org  Sat Feb 20 15:27:59 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Feb 2016 20:27:59 +0000
Subject: [issue26307] no PGO for built-in modules with `make profile-opt`
In-Reply-To: <1454938106.72.0.648611247693.issue26307@psf.upfronthosting.co.za>
Message-ID: <1456000079.19.0.915997460738.issue26307@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26307>
_______________________________________

From report at bugs.python.org  Sat Feb 20 15:28:06 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Feb 2016 20:28:06 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1456000086.67.0.626484932673.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Please add the fix to the issue that reported the problem so that the fix can be tracked with the bug report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Feb 20 15:51:47 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 20 Feb 2016 20:51:47 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1456001507.96.0.305228043614.issue26221@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Chris, can you help out here? I still don't understand the issue here. Since "from __future__ import generator_stop" only works in 3.5+ it would not work in Python 3.3/3.4 (supported by upstream asyncio with literally the same source code currently). If there's no use case for f.set_exception(StopIteration) maybe we should just complain about that?

----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sat Feb 20 15:59:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Feb 2016 20:59:44 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <20160220205941.1640.69793@psf.io>


Roundup Robot added the comment:

New changeset e523efd47418 by Brett Cannon in branch '3.5':
Issue #26367: Have importlib.__init__() raise RuntimeError when
https://hg.python.org/cpython/rev/e523efd47418

New changeset 8f72bf88f471 by Brett Cannon in branch 'default':
Merge for issue #26367
https://hg.python.org/cpython/rev/8f72bf88f471

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Sat Feb 20 16:00:13 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Feb 2016 21:00:13 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1456002013.52.0.164552484715.issue26367@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Manuel!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Sat Feb 20 16:34:59 2016
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 20 Feb 2016 21:34:59 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1456004099.85.0.727154816919.issue26221@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Ultimately, it's the exact same thing that PEP 479 is meant to deal with - raising StopIteration is functionally identical to returning. I don't use asyncio enough to be certain, but I'm not aware of any good reason to inject a StopIteration into it; maybe an alternative solution is to add a check in set_exception "if isinstance(exception, StopIteration): raise DontBeAFool"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sat Feb 20 16:57:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Feb 2016 21:57:01 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1456005421.45.0.239411646703.issue26385@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think patch 3 is good for Python 3, thankyou. For Python 2, the test will have to be adjusted. From memory, mode='wr' is accepted without an exception, and mode=2 triggers an early error (so we never trigger the bug).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Sat Feb 20 17:47:49 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Sat, 20 Feb 2016 22:47:49 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1456008469.62.0.524703242321.issue21042@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

What do you think about this regex?

'(lib%s\.[^\s]+\s\(%s(?:\)|,\s.*\))\s=>\s.*)' % (re.escape(name), abi_type))

It works on 64 bit, just like before, but I could not test it on 32 bit. I'll add tests soon.

I looked for documentation on ldconfig, but could not find anything useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Sat Feb 20 17:50:29 2016
From: report at bugs.python.org (Simon Bernier St-Pierre)
Date: Sat, 20 Feb 2016 22:50:29 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
Message-ID: <1456008629.58.0.297729770488.issue26395@psf.upfronthosting.co.za>


New submission from Simon Bernier St-Pierre:

I want to receive data on a UDP socket that was bound, without blocking the event loop. I've looked through the asyncio docs, and I haven't found a way of doing that using the coroutine API (yield from/await).

There is a sock_recv method on BaseEventLoop which is a coroutine, it seems like sock_recvfrom was never implemented.

I don't have a patch for this right now, I wanted to know what people thought of adding support for this.

----------
components: asyncio
messages: 260580
nosy: Simon Bernier St-Pierre, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio does not support yielding from recvfrom (socket/udp)
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Sat Feb 20 18:45:39 2016
From: report at bugs.python.org (Mark Mikofski)
Date: Sat, 20 Feb 2016 23:45:39 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1456011939.42.0.280853403664.issue24872@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

still have the `link.exe` 1561 error without `extra_args=['/DLL']` issue. is there a patch? It goes in `distutils._msvccompiler` right?

----------
nosy: +bwanamarko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sat Feb 20 18:59:24 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 20 Feb 2016 23:59:24 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
In-Reply-To: <1456008629.58.0.297729770488.issue26395@psf.upfronthosting.co.za>
Message-ID: <1456012764.7.0.935859831769.issue26395@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

You should be able to do this by calling create_datagram_endpoint(), passing it a custom DatagramProtocol subclass whose datagram_received() stores the data in the result of a Future. You can then wait for the Future to wait for the data (assuming it ever arrives :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:10:43 2016
From: report at bugs.python.org (Sean Gillespie)
Date: Sun, 21 Feb 2016 00:10:43 +0000
Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free
In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za>
Message-ID: <1456013443.67.0.659617138946.issue26000@psf.upfronthosting.co.za>


Sean Gillespie added the comment:

Is anyone currently working on this? If not, I'd like to try and fix this. I've debugged this a little and think I have an idea of what's going on.

----------
nosy: +swgillespie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26000>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:20:33 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 21 Feb 2016 00:20:33 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1456004099.85.0.727154816919.issue26221@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+4rJVW+zvE=uJBAK9EqE1QgWav0MsCYppfOv+81fq4xw@mail.gmail.com>


Guido van Rossum added the comment:

OK, since eventually there won't be a way to inject StopIteration into
a Future anyway (it'll always raise RuntimeError once PEP 479 is the
default behavior) we should just reject this in set_exception().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:23:49 2016
From: report at bugs.python.org (Simon Bernier St-Pierre)
Date: Sun, 21 Feb 2016 00:23:49 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
In-Reply-To: <1456008629.58.0.297729770488.issue26395@psf.upfronthosting.co.za>
Message-ID: <1456014229.42.0.284680419361.issue26395@psf.upfronthosting.co.za>


Simon Bernier St-Pierre added the comment:

That could work. I came up with this

class MyProtocol(aio.DatagramProtocol):
    def __init__(self, fut):
        self._fut = fut

    def datagram_received(self, data, addr):
        self.fut.set_result((data, addr))

fut = aio.Future()
loop.create_datagram_endpoint(lambda: MyProtocol(fut), ...)
yield from fut

1. Is there a better way of sharing the future between the protocol and the main function?
2. This might be inefficient because I have to create a new endpoint every time I want to receive a packet. I might be able to implement a scheme where I give the protocol a new future after every packet, but it's kind of cumbersome.

If I wrote the patch to make sock_recvfrom work, can it get merged or must it go through the PEP process?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:36:37 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 21 Feb 2016 00:36:37 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
In-Reply-To: <1456014229.42.0.284680419361.issue26395@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+02V8vnEouXaPTDCfAsJ0U-+8Ys4oVLHJ0_iA9JLy-yg@mail.gmail.com>


Guido van Rossum added the comment:

I won't make you go through the PEP process, but I do think it's a bad
idea to add this. After all datagrams aren't guaranteed to arrive, so,
whil I don't know what protocol you're trying to implement, I think
you're probably better off writing the whole thing as a
DatagramProtocol subclass that handles all incoming packets.

If you need help writing your app's code it's probably better to ask
around on a mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:44:28 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Feb 2016 00:44:28 +0000
Subject: [issue26396] Create json.JSONType
Message-ID: <1456015468.57.0.0882861590724.issue26396@psf.upfronthosting.co.za>


New submission from Brett Cannon:

See https://github.com/python/typing/issues/182 for the full details, but it should be:

JSONType = t.Union[str, int, float, bool, None, t.Dict[str, t.Any], t.List[Any]]

----------
assignee: brett.cannon
components: Library (Lib)
messages: 260587
nosy: brett.cannon, gvanrossum
priority: low
severity: normal
stage: needs patch
status: open
title: Create json.JSONType
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26396>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:47:42 2016
From: report at bugs.python.org (Simon Bernier St-Pierre)
Date: Sun, 21 Feb 2016 00:47:42 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
In-Reply-To: <1456008629.58.0.297729770488.issue26395@psf.upfronthosting.co.za>
Message-ID: <1456015662.7.0.00382711667437.issue26395@psf.upfronthosting.co.za>


Simon Bernier St-Pierre added the comment:

I want to have a loop that receives data like this:

socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
socket.bind(('0.0.0.0', port))
socket.setblocking(False)
while True:
    data, addr = await loop.sock_recvfrom(sock, 4096)
    # process packet

It's pretty similar to what the blocking code would look like, but it allows me to keep everything on a single thread without blocking. It could be done with the Protocol API, but I'd rather use the shiny new async/await API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:59:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Feb 2016 00:59:08 +0000
Subject: [issue26397] Tweak importlib Example of importlib.import_module() to
 use importlib.util.module_from_spec()
Message-ID: <1456016348.28.0.973001051865.issue26397@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The example uses `spec.loader.create_module()` where it should be using `util.module_from_spec(spec)`.

----------
assignee: brett.cannon
components: Documentation
messages: 260589
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Tweak importlib Example of importlib.import_module() to use importlib.util.module_from_spec()
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26397>
_______________________________________

From report at bugs.python.org  Sat Feb 20 20:22:20 2016
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 21 Feb 2016 01:22:20 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1456017740.69.0.298825219556.issue26221@psf.upfronthosting.co.za>


Chris Angelico added the comment:

POC patch, no tests. Is TypeError right? Should it be ValueError, since the notional type is "Exception"?

----------
keywords: +patch
Added file: http://bugs.python.org/file41980/no_stop_iter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sat Feb 20 20:34:20 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 21 Feb 2016 01:34:20 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1456017740.69.0.298825219556.issue26221@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ7EVgcFM9Z328sonY6OoNBrNygZqfCHC8kyr5+km0J1g@mail.gmail.com>


Guido van Rossum added the comment:

I think TypeError is fine. I would make the message a bit longer to
explain carefully what's the matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sat Feb 20 21:25:08 2016
From: report at bugs.python.org (Mike Kaplinskiy)
Date: Sun, 21 Feb 2016 02:25:08 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1456021508.93.0.13096021571.issue26388@psf.upfronthosting.co.za>


Changes by Mike Kaplinskiy <mike.kaplinskiy at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file41981/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Sat Feb 20 21:37:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Feb 2016 02:37:13 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <20160221023709.1977.35390@psf.io>


Roundup Robot added the comment:

New changeset 9f1e680896ef by Brett Cannon in branch '3.5':
Issue #26186: Remove an invalid type check in
https://hg.python.org/cpython/rev/9f1e680896ef

New changeset 86fc6cdd65de by Brett Cannon in branch 'default':
Merge for issue #26186
https://hg.python.org/cpython/rev/86fc6cdd65de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26186>
_______________________________________

From report at bugs.python.org  Sat Feb 20 21:44:23 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Feb 2016 02:44:23 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1456022663.19.0.996217690924.issue26186@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This has been resolved by removing the check (the docs have always said the method was ignored, so that will just continue). I also did separate commit to list that BuiltinImporter and ExtensionFileLoader won't work (they would need to be updated to return a module subclass to work).

I'm leaving this issue open to decide if I want to add an explicit check in importlib.util.LazyLoader.create_module() to verify that None is returned in Python 3.5 (I probably will, but I want to think about on it for a little bit).

----------
resolution:  -> fixed
stage: test needed -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26186>
_______________________________________

From report at bugs.python.org  Sat Feb 20 21:46:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Feb 2016 02:46:03 +0000
Subject: [issue26397] Tweak importlib Example of importlib.import_module() to
 use importlib.util.module_from_spec()
In-Reply-To: <1456016348.28.0.973001051865.issue26397@psf.upfronthosting.co.za>
Message-ID: <20160221024600.1705.12587@psf.io>


Roundup Robot added the comment:

New changeset f2a089d68297 by Brett Cannon in branch 'default':
Issue #26397: Update an importlib example to use util.module_from_spec() instead of create_module()
https://hg.python.org/cpython/rev/f2a089d68297

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26397>
_______________________________________

From report at bugs.python.org  Sat Feb 20 21:46:18 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Feb 2016 02:46:18 +0000
Subject: [issue26397] Tweak importlib Example of importlib.import_module() to
 use importlib.util.module_from_spec()
In-Reply-To: <1456016348.28.0.973001051865.issue26397@psf.upfronthosting.co.za>
Message-ID: <1456022778.15.0.255589133451.issue26397@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26397>
_______________________________________

From report at bugs.python.org  Sun Feb 21 02:05:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 07:05:44 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1456038344.51.0.319704905184.issue21042@psf.upfronthosting.co.za>


Martin Panter added the comment:

Tam?s, it might be a good idea for you to sign a contributor agreement <https://www.python.org/psf/contrib/contrib-form/>.

I compiled Python in 32-bit mode and tried your v2 patch out, which found the wrong library as I predicted. Then I tried your new regex and it picked out the correct line. I had to edit it to get it to extract just the filename from the line:

r'lib%s\.[^\s]+\s\(%s(?:,\s.*)?\)\s=>\s(.*)' % (re.escape(name), abi_type)

I factored out the closing bracket from the comma + space bit, moved the group brackets to the end to extract the filename, and made it a raw string.

Without the patch, in 32-bit mode it will find 64-bit-only libraries:

>>> find_library("m")  # 32- and 64-bit available
'libm.so.6'
>>> find_library("tcl8.6")  # Only 64-bit version available!
'libtcl8.6.so'

With my edited regex:

>>> find_library("m")
'/usr/lib32/libm.so.6'
>>> find_library("tcl8.6") is None  # No 32-bit version found
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Sun Feb 21 02:41:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 07:41:02 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
In-Reply-To: <1456008629.58.0.297729770488.issue26395@psf.upfronthosting.co.za>
Message-ID: <1456040462.94.0.273139833972.issue26395@psf.upfronthosting.co.za>


Martin Panter added the comment:

If your event loop supports it, maybe you could use add_reader() etc as a workaround (roughly based off a different function of my own; this version completely untested):

async def sock_recvfrom(nonblocking_sock, *pos, loop, **kw):
    while True:
        try:
            return nonblocking_sock.recvfrom(*pos, **kw)
        except BlockingIOError:
            future = Future(loop=loop)
            loop.add_reader(nonblocking_sock.fileno(), future.set_result, None)
            try:
                await future
            finally:
                loop.remove_reader(nonblocking_sock.fileno())

I?m not very experienced with asyncio, but I imagine having general-purpose loop.wait_readable(file_descriptor) etc methods would make writing these kind of functions easier.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Sun Feb 21 03:19:45 2016
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 21 Feb 2016 08:19:45 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1456042785.63.0.358232287198.issue26221@psf.upfronthosting.co.za>


Chris Angelico added the comment:

How about "StopException interacts badly with generators and cannot be raised into a Future"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sun Feb 21 03:28:09 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 21 Feb 2016 08:28:09 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1456043289.31.0.872787744192.issue26385@psf.upfronthosting.co.za>


SilentGhost added the comment:

Then, I think the TypeError check could be dropped and 'wr' replaced by an obviously wrong value, both seem fairly trivial. I don't have a working 2.7 checkout, so if anyone wants to extend the fix to that branch, they're more than welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Sun Feb 21 04:29:39 2016
From: report at bugs.python.org (Manuel Jacob)
Date: Sun, 21 Feb 2016 09:29:39 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1456046979.35.0.156625902401.issue26367@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

I think the "What's New" entry has two typos.  It should be `importlib.__import__()` instead of `importlib.__init__()` and SystemError instead of RuntimeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Sun Feb 21 04:45:59 2016
From: report at bugs.python.org (Dhiraj)
Date: Sun, 21 Feb 2016 09:45:59 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTMLi Vulnerabilities
Message-ID: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>


New submission from Dhiraj:

The Pre-defined Module cgi.escape() can lead to XSS or HTMLi
in every Version of Python.

Example :

import cgi
test = "<h1>Vulnerable</h1>"
cgi.escape(test)

Works Properly all the Charters are escape properly but ,

Example 2:

import cgi 
test2 = ' " '
cgi.escape(test2) 

Do not works Fine and the ' " ' Character is not escape properly and this may cause and XSS or HTMLi
Please find the Attachments Below (PFA)

The Python Security Expert says :

" - The behavior of the cgi.escape() function is not a bug. It works
exactly as documented in the Python documentation,
https://docs.python.org/2/library/cgi.html#cgi.escape

- By default the cgi.escape() function only escapes the three chars '<',
'>' and '&'. The double quote char '"' is not quoted unless you cann
cgi.escape() with quote=True. The default mode is suitable for
escaping blocks of text that may contain HTML."

He says that if the quote = True then its not Vulnerable.
Example :

cgi.escape('<h1>"&auml;"</h1>', quote=True)

But Many Websites Developers and many popular Companies forget to implement the
quote = True function and this may cause XSS and HTMLi
According to me there should be a Predefine value in cgi.escape() which makes 
quote = True ,  then it will not be Vulnerable.

I hope this will be patched soon and will be Updated.
Thank You (PFA)
Dhiraj Mishra
Bug

----------
assignee: docs at python
components: Documentation
files: CGI.ESCAPE_2.png
messages: 260600
nosy: DhirajMishra, docs at python
priority: normal
severity: normal
status: open
title: cgi.escape() Can Lead To XSS and HTMLi Vulnerabilities
versions: Python 3.6
Added file: http://bugs.python.org/file41982/CGI.ESCAPE_2.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:09:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 10:09:30 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456049370.23.0.726389892083.issue26398@psf.upfronthosting.co.za>


Martin Panter added the comment:

The Python 3 documentation <https://docs.python.org/3/library/cgi.html#cgi.escape> says this is deprecated in favour of html.escape(), which by default has quote=True. AFAIK there is no equivalent in Python 2. See Issue 2830 for the addition of html.escape(), and also Issue 9061 about cgi.escape() introducing vulnerabilities.

----------
nosy: +martin.panter
title: cgi.escape() Can Lead To XSS and HTMLi Vulnerabilities -> cgi.escape() Can Lead To XSS and HTML Vulnerabilities

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:45:20 2016
From: report at bugs.python.org (Acid)
Date: Sun, 21 Feb 2016 10:45:20 +0000
Subject: [issue26399] -2+1
Message-ID: <1456051520.47.0.797070893394.issue26399@psf.upfronthosting.co.za>


Changes by Acid <acid.exploit at gmail.com>:


----------
nosy: Acid
priority: normal
severity: normal
status: open
title: -2+1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26399>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:48:54 2016
From: report at bugs.python.org (Acid)
Date: Sun, 21 Feb 2016 10:48:54 +0000
Subject: [issue26399] -2+3+cmd|' /C calc'!A0
Message-ID: <1456051734.14.0.543770977328.issue26399@psf.upfronthosting.co.za>


Changes by Acid <acid.exploit at gmail.com>:


----------
title: -2+1 -> -2+3+cmd|' /C calc'!A0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26399>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:54:16 2016
From: report at bugs.python.org (Acid)
Date: Sun, 21 Feb 2016 10:54:16 +0000
Subject: [issue26399] CSV Injection Vulnerability
Message-ID: <1456052056.17.0.370587788847.issue26399@psf.upfronthosting.co.za>


New submission from Acid:

The "Download as CSV " feature of bugs.python.org does not properly "escape" fields. This allows an adversary to turn a field into active content so when we download the csv and opens it, the active content gets executed. Here is more information about this issue:
http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/

Steps to Reproduce.
1. Enter the title with the payload : -2+3+cmd|' /C calc'!A0
2. Download the bugs as CSV
3. Open it with excel and Calc will get prompted.

Depending upon the system user privileges, an attacker can perform various tasks using the same.
If the user is with high privilege, it is easy to change the system password as mentioned below
-2+3+cmd|' /C net user administrator lol at 123'!A0

Mitigations:
Ensure all fields are properly "escaped" before returning the CSV file to the user.

Regards,
Acid

----------
title: -2+3+cmd|' /C calc'!A0 -> CSV Injection Vulnerability

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26399>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:57:59 2016
From: report at bugs.python.org (Acid)
Date: Sun, 21 Feb 2016 10:57:59 +0000
Subject: [issue26399] CSV Injection Vulnerability
In-Reply-To: <1456052056.17.0.370587788847.issue26399@psf.upfronthosting.co.za>
Message-ID: <1456052279.16.0.817142116573.issue26399@psf.upfronthosting.co.za>


Acid added the comment:

Impact of this one is high, as download as CSV is present for guest user as well. Means anyone can download the bugs using "Download as CSV " function and as the file is downloaded from the trusted resource so the possibility is high the code will get executed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26399>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:58:12 2016
From: report at bugs.python.org (Manvi B)
Date: Sun, 21 Feb 2016 10:58:12 +0000
Subject: [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1456052292.28.0.400462908406.issue26247@psf.upfronthosting.co.za>


Manvi B added the comment:

We (Elena Oat and I) tried to open web browser Chrome/Chromium in versions 2.7, 3.3, 3.5 and 3.6. It seems working and so updated in the table for version 2.7. The patch issue26247.diff is submitted.

----------
keywords: +patch
nosy: +Manvi B
Added file: http://bugs.python.org/file41983/issue26247.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26247>
_______________________________________

From report at bugs.python.org  Sun Feb 21 06:01:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Feb 2016 11:01:43 +0000
Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch
 exiting exceptions
In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za>
Message-ID: <20160221110140.1973.86652@psf.io>


Roundup Robot added the comment:

New changeset d500d1a9615f by Martin Panter in branch 'default':
Issue #23430: Stop socketserver from catching SystemExit etc from handlers
https://hg.python.org/cpython/rev/d500d1a9615f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23430>
_______________________________________

From report at bugs.python.org  Sun Feb 21 06:05:30 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Feb 2016 11:05:30 +0000
Subject: [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1456052730.78.0.946678522968.issue26247@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the patch, however since this is for the 2.7 branch, it should only say in which 2.7.x version this has been added.  The note should also use the .. versionadded:: directive.
All minor releases are tagged in the repo, so you can try to update the repo to each 2.7.x version and check in which one chrome support has been introduced.

----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26247>
_______________________________________

From report at bugs.python.org  Sun Feb 21 06:21:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 11:21:14 +0000
Subject: [issue26295] Random failures when running test suite in parallel (-m
 test -j0) caused by test_regrtest
In-Reply-To: <1454663707.24.0.201658170139.issue26295@psf.upfronthosting.co.za>
Message-ID: <1456053674.02.0.0325038437945.issue26295@psf.upfronthosting.co.za>


Martin Panter added the comment:

You say you couldn?t get the test package to be split into multiple directories. What did you try? As far as I can see, we need a way for test_regrtest to invoke the child process with some flag to say ?add this extra directory to test.__path__?.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26295>
_______________________________________

From report at bugs.python.org  Sun Feb 21 06:25:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 11:25:51 +0000
Subject: [issue25139] socketserver.ThreadingMixIn exception handler: Just a
 little refactoring
In-Reply-To: <1442395563.59.0.192959239996.issue25139@psf.upfronthosting.co.za>
Message-ID: <1456053951.71.0.614973349963.issue25139@psf.upfronthosting.co.za>


Martin Panter added the comment:

I pushed the above code to 3.6, so closing this.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed
superseder:  -> socketserver.BaseServer.handle_error() should not catch exiting exceptions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25139>
_______________________________________

From report at bugs.python.org  Sun Feb 21 06:32:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 11:32:58 +0000
Subject: [issue26295] Random failures when running test suite in parallel (-m
 test -j0) caused by test_regrtest
In-Reply-To: <1454663707.24.0.201658170139.issue26295@psf.upfronthosting.co.za>
Message-ID: <1456054378.32.0.346965190925.issue26295@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another idea is to make a loader script that loads the ?test? module, patches its __path__, and then runs test.__main__ or whatever as usual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26295>
_______________________________________

From report at bugs.python.org  Sun Feb 21 07:31:25 2016
From: report at bugs.python.org (Dhiraj)
Date: Sun, 21 Feb 2016 12:31:25 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456057885.46.0.350942149443.issue26398@psf.upfronthosting.co.za>


Dhiraj added the comment:

Hello @martin.panter okay But still the module cgi.escape() Vulnerable  if the Python Docs have created a new html.escape so you might remove the cgi.escape() or Implement the quote = True in cgi.escape()  Predefine as its in html.escape because Developer mostly use CGI. 
Its an Humble request , I hope I did well.

Thank You martin.panter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Sun Feb 21 08:05:36 2016
From: report at bugs.python.org (Michael Herold)
Date: Sun, 21 Feb 2016 13:05:36 +0000
Subject: [issue26394] Have argparse provide ability to require a fallback
 value be present
In-Reply-To: <1455985031.95.0.488150837583.issue26394@psf.upfronthosting.co.za>
Message-ID: <1456059936.92.0.422715379908.issue26394@psf.upfronthosting.co.za>


Michael Herold added the comment:

Thank you for clarifying my request. Callables sound like a great solution to me!

Looks like the fallback should be called in `take_action()` if argument_values is "empty" (None?). Per default it should be transparent to an `Action` if the values are based on a fallback call. However, it might be useful to call `Action` with two additional parameters like `commandline_values` and `fallback_values` such that a (custom) action 'append_with_fallback' can be realized. Calling the fallback each time (required for `fallback_values`) makes it some kind of early called hook for argparse.

I am attaching a sketch of what might be a typical use case. I noted that a callable supplied to fallback would usually rely on informations that could be provided as `action.long_option_names` and `action.is_positional` to avoid that this logic is implemented outside of argparse again.

Please let me know I can provide any help.

----------
Added file: http://bugs.python.org/file41984/fallback.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26394>
_______________________________________

From report at bugs.python.org  Sun Feb 21 09:39:43 2016
From: report at bugs.python.org (giumas)
Date: Sun, 21 Feb 2016 14:39:43 +0000
Subject: [issue26400] SyntaxError when running Python 2.7 interpreter with
 subprocess.call
Message-ID: <1456065583.71.0.292979306373.issue26400@psf.upfronthosting.co.za>


New submission from giumas:

On Windows, I am getting a `SyntaxError` when I try to input commands after having launched a Python 2.7.x interpreter with `subprocess.call`. 

This is a minimal example: 

    import os
    import subprocess
    
    
    def python_env_path(python_path):
        env = os.environ.copy()
        python_scripts = os.path.join(python_path, "Scripts")
        python_bin = os.path.join(python_path, "Library", "bin")
        path_env = "%s;%s;%s;" % (python_path, python_scripts, python_bin)
        env['PATH'] = path_env.encode()
        return env
    
    
    def open_python_prompt(python_path):
        env = python_env_path(python_path)
        prc = subprocess.call(["start", "python"],
                              shell=True, cwd=python_path, env=env)
        if prc != 0:
            print("Unable to open a Python prompt")
            return False
    
        return True
    
    open_python_prompt("C:\Py27x64")

When I try to write whatever simple command for the interpreter I get:

    >>> a = 0
      File "<stdin>", line 1
        a = 0
             ^
    SyntaxError: invalid syntax

I did not find SO questions that solve my issue.
The same code works fine with Python 3.x.
The same Python installation works fine if I open a shell and call the interpreter using a batch file.

----------
components: Extension Modules, Windows
messages: 260612
nosy: giumas, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: SyntaxError when running Python 2.7 interpreter with subprocess.call
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26400>
_______________________________________

From report at bugs.python.org  Sun Feb 21 10:35:43 2016
From: report at bugs.python.org (=?utf-8?b?UmHDumwgTsO6w7FleiBkZSBBcmVuYXM=?=)
Date: Sun, 21 Feb 2016 15:35:43 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
Message-ID: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>


New submission from Ra?l N??ez de Arenas:

According to the documentation, if the 'compile' built-in function encounters NUL bytes in the compiled source, it raises TypeError, but this is not true:

>>> source = '\u0000'
>>> compile(source, '', 'single')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: source code string cannot contain null bytes

It raises ValueError, not TypeError. And IMHO, it's the proper exception to raise...

----------
assignee: docs at python
components: Documentation
messages: 260613
nosy: Ra?l N??ez de Arenas, docs at python
priority: normal
severity: normal
status: open
title: Error in documentation for "compile" built-in function
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 10:40:39 2016
From: report at bugs.python.org (Simon Bernier St-Pierre)
Date: Sun, 21 Feb 2016 15:40:39 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
In-Reply-To: <1456008629.58.0.297729770488.issue26395@psf.upfronthosting.co.za>
Message-ID: <1456069239.01.0.722891259183.issue26395@psf.upfronthosting.co.za>


Simon Bernier St-Pierre added the comment:

I created a patch for it on the asyncio github repo.

https://github.com/python/asyncio/pull/321

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Sun Feb 21 10:47:32 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 21 Feb 2016 15:47:32 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456069652.57.0.283503157531.issue26401@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch.

----------
keywords: +patch
nosy: +SilentGhost
versions: +Python 3.6
Added file: http://bugs.python.org/file41985/issue26401.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:01:48 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 21 Feb 2016 16:01:48 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1456042785.63.0.358232287198.issue26221@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJerX9xq8uC-fiXXQJkBaoUYUjKSrfNPMeT1nNYQfTK8A@mail.gmail.com>


Guido van Rossum added the comment:

S.G.T.M.

On Sunday, February 21, 2016, Chris Angelico <report at bugs.python.org> wrote:

>
> Chris Angelico added the comment:
>
> How about "StopException interacts badly with generators and cannot be
> raised into a Future"?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org <javascript:;>>
> <http://bugs.python.org/issue26221>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:03:36 2016
From: report at bugs.python.org (Jelte Fennema)
Date: Sun, 21 Feb 2016 16:03:36 +0000
Subject: [issue26402] Regression in Python 3.5 http.client,
 raises RemoteDisconnected seemingly randomly.
Message-ID: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>


New submission from Jelte Fennema:

I've been developing an application which uses fuse as in interface to an xmlrpc API. I developed it with python 3.4 and it worked fine. When I used python 3.5 it started randomly raising a specific error when requesting info using the xmlrpc API.

The error in question is the RemoteDisconnected error which was added in 3.5. An example stacktrace is:

Traceback (most recent call last):
  File "/home/jelte/fun/easyfuse/easyfuse/utils.py", line 20, in _convert_error_to_fuse_error
    yield
  File "/home/jelte/fun/easyfuse/easyfuse/filesystem.py", line 276, in children
    self.refresh_children()
  File "dokuwikifuse.py", line 139, in refresh_children
    pages = dw.pages.list(self.full_path, depth=self.full_depth + 2)
  File "/home/jelte/fun/dokuwikifuse/venv/src/dokuwiki-master/dokuwiki.py", line 102, in list
    return self._dokuwiki.send('dokuwiki.getPagelist', namespace, options)
  File "/home/jelte/fun/dokuwikifuse/venv/src/dokuwiki-master/dokuwiki.py", line 55, in send
    return method(*args)
  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1091, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1431, in __request
    verbose=self.__verbose
  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1133, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib64/python3.5/xmlrpc/client.py", line 1146, in single_request
    resp = http_conn.getresponse()
  File "/usr/lib64/python3.5/http/client.py", line 1174, in getresponse
    response.begin()
  File "/usr/lib64/python3.5/http/client.py", line 282, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python3.5/http/client.py", line 251, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response


The program in question can be found here: https://github.com/JelteF/dokuwikifuse
The bug can be initiated by calling running the program as described in the README and doing a couple of file system operations wich do requests. These are things like `ls wiki/*` or calling `head wiki/*.doku`.

----------
components: IO
messages: 260617
nosy: JelteF
priority: normal
severity: normal
status: open
title: Regression in Python 3.5 http.client, raises RemoteDisconnected seemingly randomly.
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:17:26 2016
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 21 Feb 2016 16:17:26 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1456071446.12.0.622011281865.issue26221@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Wording changed, and a simple test added. I'm currently seeing failures in test_site, but that probably means I've messed something up on my system.

----------
Added file: http://bugs.python.org/file41986/no_stop_iter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:19:13 2016
From: report at bugs.python.org (Jelte Fennema)
Date: Sun, 21 Feb 2016 16:19:13 +0000
Subject: [issue26402] Regression in Python 3.5 http.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456071553.56.0.478362229137.issue26402@psf.upfronthosting.co.za>


Jelte Fennema added the comment:

A short look through the stacktrace actually seemed to have gotten me to the issue. It is in the xmlrpc.client library in this piece of code:

         for i in (0, 1):
             try:
                 return self.single_request(host, handler, request_body, verbose)
             except OSError as e:
                 if i or e.errno not in (errno.ECONNRESET, errno.ECONNABORTED,
                                         errno.EPIPE):
                     raise
             except http.client.RemoteDisconnected:
                 if i:
                     raise

As can be seen http.client.RemoteDisconnected error is caught after the OSError one. However http.client.RemoteDisconnected is a subclass of OSError since it's a subclass of ConnectionResetError: https://docs.python.org/3/library/http.client.html#http.client.RemoteDisconnected

A simple fix which seems to work for me is switching the two except branches as I did in the attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file41987/xmlrpc-remote-disconnected.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:24:04 2016
From: report at bugs.python.org (Jelte Fennema)
Date: Sun, 21 Feb 2016 16:24:04 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456071844.92.0.364870538896.issue26402@psf.upfronthosting.co.za>


Changes by Jelte Fennema <pythonbugs-tech at jeltef.nl>:


----------
title: Regression in Python 3.5 http.client, raises RemoteDisconnected seemingly randomly. -> Regression in Python 3.5 xmlrpc.client, raises RemoteDisconnected seemingly randomly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:28:54 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 21 Feb 2016 16:28:54 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456072134.73.0.222308731974.issue26402@psf.upfronthosting.co.za>


SilentGhost added the comment:

The code in question[0] was introduced in issue 3566: perhaps Martin could comment on existing implementation.

[0] https://hg.python.org/cpython/rev/eba80326ba53

----------
components: +Library (Lib) -IO
nosy: +SilentGhost, martin.panter
stage:  -> test needed
type: crash -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:34:38 2016
From: report at bugs.python.org (Jelte Fennema)
Date: Sun, 21 Feb 2016 16:34:38 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456072478.81.0.87332773428.issue26402@psf.upfronthosting.co.za>


Jelte Fennema added the comment:

>From what I can see that change simply replaces the old BadStatusLine exception with the new RemoteDisconnected one. But since BadStatusLine is not a subclass of OSError the correct code path would be taken. Currently the path in execpt RemoteDisconnected is simply a no-op as the exception will be caught first as an OSError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Sun Feb 21 12:15:44 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 21 Feb 2016 17:15:44 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1456071446.12.0.622011281865.issue26221@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJDLe1171c_K58kRKB5rdsFYM4pbUsYRmACuVxdbdNMJw@mail.gmail.com>


Guido van Rossum added the comment:

Would you mind reworking this as a PR for github.com/python/asyncio ?
That's still considered "upstream" for asyncio.

--Guido

On Sun, Feb 21, 2016 at 8:17 AM, Chris Angelico <report at bugs.python.org> wrote:
>
> Chris Angelico added the comment:
>
> Wording changed, and a simple test added. I'm currently seeing failures in test_site, but that probably means I've messed something up on my system.
>
> ----------
> Added file: http://bugs.python.org/file41986/no_stop_iter.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26221>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sun Feb 21 12:23:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Feb 2016 17:23:08 +0000
Subject: [issue26367] importlib.__import__ does not fail for invalid relative
 import
In-Reply-To: <1455584341.33.0.058581047341.issue26367@psf.upfronthosting.co.za>
Message-ID: <1456075388.9.0.264162502413.issue26367@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for spotting those! And just to clarify on terminology, the typos were in the NEWS file, not "What's New" which is a different thing (https://hg.python.org/cpython/file/default/Doc/whatsnew).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26367>
_______________________________________

From report at bugs.python.org  Sun Feb 21 12:29:42 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Feb 2016 17:29:42 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456075782.12.0.698387696763.issue26398@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Sun Feb 21 12:43:02 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Feb 2016 17:43:02 +0000
Subject: [issue26399] CSV Injection Vulnerability
In-Reply-To: <1456052056.17.0.370587788847.issue26399@psf.upfronthosting.co.za>
Message-ID: <1456076582.72.0.824623004138.issue26399@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Tracker bugs should be reported to http://psf.upfronthosting.co.za/roundup/meta/ .

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26399>
_______________________________________

From report at bugs.python.org  Sun Feb 21 12:58:19 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 21 Feb 2016 17:58:19 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456077499.0.0.0751303399988.issue26401@psf.upfronthosting.co.za>


Berker Peksag added the comment:

It would be good to add a versionchanged note. Something like:

   .. versionchanged:: 3.5
      Previously, a :exc:`TypeError` was raised [...]

----------
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 13:00:22 2016
From: report at bugs.python.org (=?utf-8?b?UmHDumwgTsO6w7FleiBkZSBBcmVuYXM=?=)
Date: Sun, 21 Feb 2016 18:00:22 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456077622.47.0.314986781158.issue26401@psf.upfronthosting.co.za>


Ra?l N??ez de Arenas added the comment:

I checked the sources at github and the change was introduced back in 2010, if I recall correctly, so maybe this change happened in 3.2? I can check again and try to determine the exact date and if at all possible the version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 13:11:08 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 21 Feb 2016 18:11:08 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456078268.84.0.763090541833.issue26401@psf.upfronthosting.co.za>


SilentGhost added the comment:

TypeError is raised in 3.4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 13:18:22 2016
From: report at bugs.python.org (=?utf-8?b?UmHDumwgTsO6w7FleiBkZSBBcmVuYXM=?=)
Date: Sun, 21 Feb 2016 18:18:22 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456078702.9.0.0309708187448.issue26401@psf.upfronthosting.co.za>


Ra?l N??ez de Arenas added the comment:

I checked the Mercurial repository directly, and the change was introduced in 2014: http://bugs.python.org/issue22215

So, yes, looks like a 3.5 change and the versionchanged note suggested by Berker is a great idea!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 13:20:29 2016
From: report at bugs.python.org (Alessandro Cucci)
Date: Sun, 21 Feb 2016 18:20:29 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456078829.63.0.0528710165053.issue19475@psf.upfronthosting.co.za>


Alessandro Cucci added the comment:

New patch

----------
Added file: http://bugs.python.org/file41988/issue19475_v13.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Sun Feb 21 13:31:53 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 21 Feb 2016 18:31:53 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456079513.9.0.300220648491.issue26401@psf.upfronthosting.co.za>


SilentGhost added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file41989/issue26401_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:02:35 2016
From: report at bugs.python.org (Michal Niklas)
Date: Sun, 21 Feb 2016 19:02:35 +0000
Subject: [issue26375] Python 2.7.10 and 3.4.4 hang on imaplib.IMAP4_SSL()
In-Reply-To: <1455716357.67.0.858374272161.issue26375@psf.upfronthosting.co.za>
Message-ID: <1456081355.25.0.796203055348.issue26375@psf.upfronthosting.co.za>


Michal Niklas added the comment:

Of course I'm not sure if it is related with RC4 removal, but I have found it in changelog for Python 2.7.10: https://hg.python.org/cpython/raw-file/15c95b7d81dc/Misc/NEWS
Issue #23481: Remove RC4 from the SSL module's default cipher list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26375>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:28:45 2016
From: report at bugs.python.org (desbma)
Date: Sun, 21 Feb 2016 19:28:45 +0000
Subject: [issue26403] Don't call sendto in DatagramRequestHandler if there is
 nothing to send
Message-ID: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>


New submission from desbma:

When using socketserver to create a simple server for Unix Domain sockets (see server_dgram.py), and when sending data with a client that immediately shuts down (without waiting for a response, on Linux I test with 'echo data | nc -Uu -w 0 /tmp/s.socket')  I get this exception:

Exception happened during processing of request from /tmp/nc.XXXXsuGc1C
Traceback (most recent call last):
  File "/usr/lib/python3.4/socketserver.py", line 617, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python3.4/socketserver.py", line 344, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.4/socketserver.py", line 675, in __init__
    self.finish()
  File "/usr/lib/python3.4/socketserver.py", line 752, in finish
    self.socket.sendto(self.wfile.getvalue(), self.client_address)
FileNotFoundError: [Errno 2] No such file or directory

The attached patch fixes this by checking if there is something to send before calling sendto.

Also I am wondering if we should catch FileNotFoundError (and possibly other exceptions) here, because with TCP or UDP, the server does not raise any exception if client is disconnected when finish is called in the handler.

Thank you

----------
components: Macintosh
files: server_dgram.py
messages: 260632
nosy: desbma, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Don't call sendto in DatagramRequestHandler if there is nothing to send
versions: Python 3.5
Added file: http://bugs.python.org/file41990/server_dgram.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:30:06 2016
From: report at bugs.python.org (desbma)
Date: Sun, 21 Feb 2016 19:30:06 +0000
Subject: [issue26403] Don't call sendto in DatagramRequestHandler if there is
 nothing to send
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456083006.33.0.852165977096.issue26403@psf.upfronthosting.co.za>


Changes by desbma <dutch109 at gmail.com>:


----------
components: +Library (Lib) -Macintosh
keywords: +patch
Added file: http://bugs.python.org/file41991/issue26403.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:34:44 2016
From: report at bugs.python.org (desbma)
Date: Sun, 21 Feb 2016 19:34:44 +0000
Subject: [issue26403] Don't call sendto in socketserver.DatagramRequestHandler
 if there is nothing to send
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456083284.59.0.923836824248.issue26403@psf.upfronthosting.co.za>


Changes by desbma <dutch109 at gmail.com>:


----------
title: Don't call sendto in DatagramRequestHandler if there is nothing to send -> Don't call sendto in socketserver.DatagramRequestHandler if there is nothing to send

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:41:24 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 21 Feb 2016 19:41:24 +0000
Subject: [issue26400] SyntaxError when running Python 2.7 interpreter with
 subprocess.call
In-Reply-To: <1456065583.71.0.292979306373.issue26400@psf.upfronthosting.co.za>
Message-ID: <1456083684.18.0.71873535085.issue26400@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The error you're getting indicates that stdin is set to binary mode for some reason. You can see this using the -u command line option:

    C:\>py -2 -u
    Python 2.7.10 (default, May 23 2015, 09:44:00) 
    [MSC v.1500 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> a = 0
      File "<stdin>", line 1
        a = 0
             ^
    SyntaxError: invalid syntax

By any chance do you have PYTHONUNBUFFERED set in the environment?

----------
nosy: +eryksun
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26400>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:00:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Feb 2016 20:00:24 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <20160221200019.1711.21854@psf.io>


Roundup Robot added the comment:

New changeset 0cfac9efd895 by Berker Peksag in branch '3.5':
Issue #26401: Fix compile() documentation
https://hg.python.org/cpython/rev/0cfac9efd895

New changeset 45cf82f424ce by Berker Peksag in branch 'default':
Issue #26401: Fix compile() documentation
https://hg.python.org/cpython/rev/45cf82f424ce

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:01:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 21 Feb 2016 20:01:40 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456084900.76.0.33407698667.issue26401@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:12:58 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Sun, 21 Feb 2016 20:12:58 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1456085578.51.0.848938383879.issue21042@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

I've added a new method to Test_OpenGL_libs as you suggested. I check whether find_library returns an absolute path. Note that I didn't distinguish different systems, as according to the docs, only Linux systems return the file name, other systems return the absolute path. (https://docs.python.org/3.5/library/ctypes.html#ctypes-reference) An other thing to note, that I introduced some code duplication as I use the same code snippet from setUpClass method to figure out the correct parameters to find_library.

The patch uses the same regex as you gave.

By the way, what do I have to do to compile CPython on a 64 bit system in 32 bit mode? I tried ./configure CC="gcc -m32" but it gave me an error. Is it the correct way?

Also, I signed contributor agreement.

----------
Added file: http://bugs.python.org/file41992/find_lib_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:15:45 2016
From: report at bugs.python.org (desbma)
Date: Sun, 21 Feb 2016 20:15:45 +0000
Subject: [issue26403] Don't call sendto in socketserver.DatagramRequestHandler
 if there is nothing to send
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456085745.81.0.335224336513.issue26403@psf.upfronthosting.co.za>


Changes by desbma <dutch109 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:17:03 2016
From: report at bugs.python.org (=?utf-8?b?UmHDumwgTsO6w7FleiBkZSBBcmVuYXM=?=)
Date: Sun, 21 Feb 2016 20:17:03 +0000
Subject: [issue26401] Error in documentation for "compile" built-in function
In-Reply-To: <1456068943.64.0.547733660691.issue26401@psf.upfronthosting.co.za>
Message-ID: <1456085823.77.0.60099866361.issue26401@psf.upfronthosting.co.za>


Ra?l N??ez de Arenas added the comment:

Thanks to you, Berker, and SilentGhost, for applying and preparing the patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26401>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:38:08 2016
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 21 Feb 2016 20:38:08 +0000
Subject: [issue26221] awaiting asyncio.Future swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1456087088.37.0.441999544781.issue26221@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Opened https://github.com/python/asyncio/pull/322

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26221>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:55:10 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sun, 21 Feb 2016 20:55:10 +0000
Subject: [issue26404] socketserver context manager
Message-ID: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

As Martin commented on my patch at issue 26392 the socketserver.server_close is like the file close. That made me think that we should add a context manager to the socketserver.

----------
components: Library (Lib)
files: socketserver_context_manager.patch
keywords: patch
messages: 260639
nosy: martin.panter, palaviv
priority: normal
severity: normal
status: open
title: socketserver context manager
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41993/socketserver_context_manager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Sun Feb 21 16:07:13 2016
From: report at bugs.python.org (rapolas)
Date: Sun, 21 Feb 2016 21:07:13 +0000
Subject: [issue26405] tkinter askopenfilename doubleclick issue on windows
Message-ID: <1456088833.09.0.473464639317.issue26405@psf.upfronthosting.co.za>


New submission from rapolas:

Issue is that doubleclick passes a click down to a parent window, and if it happens that you doubleclicking to select a file directly above some button, that button gets pressed. Here is the code to demonstrate this issue:

import tkinter as tk
from tkinter import filedialog, ttk

class MainWindow(ttk.Frame):
    def __init__(self, root, *args, **kwargs):
        super().__init__(root, *args, **kwargs)
        self.pack()
        btnoptions = {'expand':True, 'fill': 'both'}
        btn = ttk.Button(self, text='Select', command=self.ask_openfile)
        btn.pack(**btnoptions)

    def ask_openfile(self):
        filename = filedialog.askopenfilename()
        return filename

if __name__=='__main__':
    root = tk.Tk()
    root.geometry('600x300')
    MainWindow(root).pack(expand=True, fill='both', side='top')
    root.mainloop()

I observed the same behavior on two different computers, one running win10, another win7, both using the latest python 3.5.1 installation from python.org

----------
components: Tkinter
messages: 260640
nosy: rapolas
priority: normal
severity: normal
status: open
title: tkinter askopenfilename doubleclick issue on windows
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26405>
_______________________________________

From report at bugs.python.org  Sun Feb 21 16:25:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 21:25:31 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456089931.75.0.578521627171.issue26402@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thankyou Jelte for finding this. We made RemoteDisconnected inherit from ConnectionResetError (and therefore OSError) thinking it would help with compatibility, but in this case that has backfired. Your patch looks like a valid fix.

I would like to figure out a concise way to produce the fault so I can add a test case and play with the code. Would I be able to use Python?s XML-RPC server, or would I have to make a custom server that dropped the connection?

Also I suspect both exception handlers in the XML-RPC client could be combined as ?except ConnectionError?, but I want to be sure before making that change.

----------
keywords: +3.5regression

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Sun Feb 21 16:48:41 2016
From: report at bugs.python.org (Jelte Fennema)
Date: Sun, 21 Feb 2016 21:48:41 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456091321.6.0.868485538717.issue26402@psf.upfronthosting.co.za>


Jelte Fennema added the comment:

I don't know much about the server as I only used the client. So I don't know if it is possible to test with Python's XML-RPC server. 

As for your proposed improvement, it seems that should work. Keep in mind though that that would also catch the ConnectionRefusedError, which is currently raised on the first try. I'm not entirely sure when this is raised, but this might be reasonable behaviour as refusal should probably not be a one time thing. So if that is the case the new except should probably look like this:

except ConnectionError:
    if i or isinstance(ConnectionRefusedError):
        raise


This does definitely look cleaner than the two different except blocks IMHO. It also makes it clear why the new class is a subclass of ConnectionError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Sun Feb 21 16:56:51 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Feb 2016 21:56:51 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456091811.54.0.957420532526.issue26398@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I don't think there is anything to be done here. cgi.escape() is documented properly, deprecated in Python 3.x, and changing its implementation is not really an option now.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Sun Feb 21 16:58:13 2016
From: report at bugs.python.org (Alessandro Cucci)
Date: Sun, 21 Feb 2016 21:58:13 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456091893.51.0.092738071003.issue19475@psf.upfronthosting.co.za>


Changes by Alessandro Cucci <alessandro.cucci at gmail.com>:


Added file: http://bugs.python.org/file41994/issue19475_v14.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Sun Feb 21 17:27:15 2016
From: report at bugs.python.org (Sean Gillespie)
Date: Sun, 21 Feb 2016 22:27:15 +0000
Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free
In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za>
Message-ID: <1456093635.97.0.412251854713.issue26000@psf.upfronthosting.co.za>


Sean Gillespie added the comment:

Went ahead and did it since I had the time - the issue is that when doing a token of lookahead to see whether an 'async' at a top-level begins an 'async def' function or if it is an identifier. A shallow copy of the current token is made and given to another call to tok_get, which frees the token's buffer if a decoding error occurs. Since the shallow copy cloned the token's buffer pointer, the still-live token contains a freed pointer to its buffer that gets freed again later on.

By explicitly nulling-out the token's buffer pointer like tok_get does if the copied token's buffer pointer was nulled out, we avoid the double-free issue and present the correct syntax error:

$ ./python vuln.py 
  File "vuln.py", line 1
SyntaxError: Non-UTF-8 code starting with '\xef' in file vuln.py on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

William Bowling's second program is also fixed with this change, with one additional wrinkle: if a token contains a null byte as the
first character, an invalid write occurs when we attempt to replace the null character with a newline. This fix checks to make sure
that this is not the case before performing the newline insertion.

With this change, both of William Bowling's programs pass valgrind and
present the appropriate syntax error. I tried to add this to the couroutine syntax tests, but any way to load the file outside of giving it to ./python itself fails (correctly) because the program contains a null byte.

----------
keywords: +patch
Added file: http://bugs.python.org/file41995/tokenizer_double_free.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26000>
_______________________________________

From report at bugs.python.org  Sun Feb 21 17:32:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 22:32:03 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456093923.21.0.626919391793.issue19475@psf.upfronthosting.co.za>


Martin Panter added the comment:

Left some review suggestions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Sun Feb 21 17:34:04 2016
From: report at bugs.python.org (Amit Saha)
Date: Sun, 21 Feb 2016 22:34:04 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1456094044.75.0.515871414023.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

@haypo : Just a reminder request to please view the updated patch.

----------
nosy: +Amit Saha

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Sun Feb 21 18:18:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Feb 2016 23:18:58 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1456096738.11.0.629387513027.issue26323@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The latest patch looks good to me, but I would prefer to have a review of the maintainer of the unittest.mock module (Michael Ford, voidspace?), or at least a second core developer.

@Robert: Would you mind reviewing the latest patch please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Sun Feb 21 18:25:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 21 Feb 2016 23:25:58 +0000
Subject: [issue26403] Don't call sendto in socketserver.DatagramRequestHandler
 if there is nothing to send
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456097158.23.0.785590880601.issue26403@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This looks like a duplicate of issue 5824. See msg259969 for Martin's analysis in that issue.

There is also a similar patch for 2.7 in issue 1767511: http://bugs.python.org/file9271/DatagramServer.diff

----------
nosy: +berker.peksag, martin.panter -ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Sun Feb 21 18:32:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 21 Feb 2016 23:32:52 +0000
Subject: [issue26403] Don't call sendto in socketserver.DatagramRequestHandler
 if there is nothing to send
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456097572.24.0.825096120016.issue26403@psf.upfronthosting.co.za>


Martin Panter added the comment:

This change has already been proposed in Issue 1767511, which I recently replied to. I think it is valid to send an empty datagram back to the client, and not doing so could break existing code.

Also see Issue 5824 about removing the comment about recvfrom() on Linux.

Your FileNotFoundError is caused by the client removing its receiving socket file. This would also occur if the server was trying to send a non-zero datagram.

IMO this is usually an asynchronous error that is beyond the control of the server. In the TCP case, you can get similar errors if the client disconnected (BrokenPipeError, ConnectionResetError, etc). But these ?error? conditions might only be detected after the server has closed its socket, which is why you don?t always see them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Sun Feb 21 19:18:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 00:18:41 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1456100321.81.0.927151347139.issue21042@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left a suggestion about the duplication in the code review.

I set CC with ?configure? like you said. I also had to run ?make clean? to get rid of the old 64-bit stuff. But it might depend on the GCC that you have installed. On Arch Linux, I have gcc-multilib, which supports 64-bit and 32-bit targets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Sun Feb 21 19:32:11 2016
From: report at bugs.python.org (giumas)
Date: Mon, 22 Feb 2016 00:32:11 +0000
Subject: [issue26400] SyntaxError when running Python 2.7 interpreter with
 subprocess.call
In-Reply-To: <1456065583.71.0.292979306373.issue26400@psf.upfronthosting.co.za>
Message-ID: <1456101131.87.0.107973642017.issue26400@psf.upfronthosting.co.za>


giumas added the comment:

No, I don't. I have just double-checked it. 

Did you try to run my minimal example on your machine? If yes, are you getting the same behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26400>
_______________________________________

From report at bugs.python.org  Sun Feb 21 19:45:39 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Feb 2016 00:45:39 +0000
Subject: [issue26400] SyntaxError when running Python 2.7 interpreter with
 subprocess.call
In-Reply-To: <1456065583.71.0.292979306373.issue26400@psf.upfronthosting.co.za>
Message-ID: <1456101939.96.0.827965133586.issue26400@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Your example worked fine for me with the official 64-bit distribution of 2.7.10 installed in "C:\Program Files\Python27" on Windows 10.  I created a junction from "C:\Py27x64" to the 2.7 installation directory in order to run the example as provided. 

This issue is filed under "Extension Modules". Is this a personal build of Python? What's in "Library\bin" (python_bin)? That's not a standard Windows Python directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26400>
_______________________________________

From report at bugs.python.org  Sun Feb 21 20:26:48 2016
From: report at bugs.python.org (giumas)
Date: Mon, 22 Feb 2016 01:26:48 +0000
Subject: [issue26400] SyntaxError when running Python 2.7 interpreter with
 subprocess.call
In-Reply-To: <1456065583.71.0.292979306373.issue26400@psf.upfronthosting.co.za>
Message-ID: <1456104408.89.0.350172702569.issue26400@psf.upfronthosting.co.za>


giumas added the comment:

It worked also for me with the official 64-bit distribution! I get that buggy behavior with the Anaconda distribution (this was the "Library\bin"). 

I should have checked it as first step! My apologies and thank you so much for your kind help.

----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26400>
_______________________________________

From report at bugs.python.org  Sun Feb 21 22:06:39 2016
From: report at bugs.python.org (Dhiraj)
Date: Mon, 22 Feb 2016 03:06:39 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456110399.46.0.324092653289.issue26398@psf.upfronthosting.co.za>


Dhiraj added the comment:

Hello @Georg Brandl PFA you'll be happy to find that python3.x is still vulnerable to cgi.escape() the module is not able to escape some values and can lead to XSS also.
As @Martin Panter said now cgi.escape() is been replaced to html.escape()
so accordingly cgi.escape() should have a Pr-define value " quote = True "
which is not there in any Version of Python3.x or the module should be removed because we have html.escape() , Because many People still use's CGI in Web-Application.

Thank You

----------
Added file: http://bugs.python.org/file41996/cgi.escape_Dhiraj_Mishra.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Sun Feb 21 22:33:13 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Mon, 22 Feb 2016 03:33:13 +0000
Subject: [issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
Message-ID: <1456111993.44.0.164668159059.issue26406@psf.upfronthosting.co.za>


New submission from A. Jesse Jiryu Davis:

In socketmodule.c we lock around getaddrinfo calls on platforms where getaddrinfo is believed not to be thread-safe. We've verified that it *is* thread-safe, and therefore stopped locking around it, on FreeBSD 5.3+ (#1288833) and Mac OS X 10.5+ (#25924). This ticket intends to do the same for OpenBSD and NetBSD.

OpenBSD 5.4 fixed getaddrinfo's thread safety and announced it 2013-11-01, "getaddrinfo(3) is now thread-safe":

http://www.openbsd.org/plus54.html

NetBSD's fix is older and less publicized. Since ancient times NetBSD's getaddrinfo.c included a comment, "Thread safe-ness must be checked", and the getaddrinfo(3) man page had the same warning as other BSDs, "The implementation of getaddrinfo is not thread-safe." On 2004-05-27 Christos Zoulas committed with the comment "make yp stuff re-entrant", fixing obvious problems like static variables in getaddrinfo:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.c.diff?r1=1.71&r2=1.72&only_with_tag=MAIN

That change was released with NetBSD 3.0, and that alone might convince us to stop locking around getaddrinfo. Later, on 2006-07-18, between NetBSD 3 and 4, Zoulas deleted the comment "Thread safe-ness must be checked" from the source, with the message "Remove comments that do not reflect reality anymore":

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.c.diff?r1=1.82&r2=1.83&only_with_tag=MAIN

The same day, he removed the man page warning:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.3.diff?r1=1.43&r2=1.44&only_with_tag=MAIN

NetBSD 4.0 was released 2007-12-19.

----------
messages: 260655
nosy: emptysquare, gvanrossum, martin.panter, ned.deily, python-dev, ronaldoussoren, yselivanov
priority: normal
severity: normal
status: open
title: getaddrinfo is thread-safe on NetBSD and OpenBSD
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26406>
_______________________________________

From report at bugs.python.org  Sun Feb 21 22:37:12 2016
From: report at bugs.python.org (Amit Saha)
Date: Mon, 22 Feb 2016 03:37:12 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1456112232.18.0.624085830036.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Updated patch

----------
Added file: http://bugs.python.org/file41997/issue26323.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Sun Feb 21 22:40:19 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Mon, 22 Feb 2016 03:40:19 +0000
Subject: [issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
In-Reply-To: <1456111993.44.0.164668159059.issue26406@psf.upfronthosting.co.za>
Message-ID: <1456112419.43.0.75870718642.issue26406@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Patch uploaded.

I've copied the "nosy" list from #25924, if that was bad etiquette please forgive me.

----------
keywords: +patch
Added file: http://bugs.python.org/file41998/26406-getaddrinfo-netbsd-openbsd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26406>
_______________________________________

From report at bugs.python.org  Mon Feb 22 00:12:31 2016
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 22 Feb 2016 05:12:31 +0000
Subject: [issue26380] Add an http method enum
In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za>
Message-ID: <1456117951.07.0.595973725948.issue26380@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> To me, your later throw-in comment about static analyzers might be the most persuasive point you made

Well, we're in agreement there :) As I'd mentioned, at best it's a minor annoyance. I'm entirely on the fence about the use of the enum as well and after reading your response, am more inclined to change this to simple constants as the enum really doesn't add much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26380>
_______________________________________

From report at bugs.python.org  Mon Feb 22 01:32:47 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 22 Feb 2016 06:32:47 +0000
Subject: [issue26307] no PGO for built-in modules with `make profile-opt`
In-Reply-To: <1454938106.72.0.648611247693.issue26307@psf.upfronthosting.co.za>
Message-ID: <1456122767.23.0.560931336816.issue26307@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I've added the patch here also.

----------
keywords: +patch
Added file: http://bugs.python.org/file41999/pgofix-cpython2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26307>
_______________________________________

From report at bugs.python.org  Mon Feb 22 01:32:54 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 22 Feb 2016 06:32:54 +0000
Subject: [issue26307] no PGO for built-in modules with `make profile-opt`
In-Reply-To: <1454938106.72.0.648611247693.issue26307@psf.upfronthosting.co.za>
Message-ID: <1456122774.2.0.453962153409.issue26307@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file42000/pgofix-cpython3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26307>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:28:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 08:28:18 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456129698.33.0.224195335847.issue26402@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is patch with a test case. I kept Jelte?s original fix as it is, because I want to be conservative in the code changes.

Xmlrpc.server only uses HTTP 1.0, without any support of keep-alive connections, so I used http.server instead.

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file42001/xmlrpc-remote-disconnected.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:29:24 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Feb 2016 08:29:24 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1456129764.55.0.719730080899.issue26388@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This seems like a reasonable enhancement to me, but I'd appreciate your thoughts on how it might relate to a couple of other proposed ideas:

* Supporting execution-by-module-name in pdb et al: https://bugs.python.org/issue9325
* Supporting configurable target environments for module execution: https://bugs.python.org/issue19982

My own current assessment is "this RFE neither helps nor hinders those other ideas", so this can also be read as an attempt to get a potential contributor with an interest in runpy to take a look at those long-languishing ideas to see if they pique your interest ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:31:44 2016
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 22 Feb 2016 08:31:44 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
 as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1456129904.9.0.919238743045.issue9325@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:34:02 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Feb 2016 08:34:02 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1456130042.12.0.922237763557.issue26388@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The PSF also has a Contributor Licensing Agreement in place for contributions to CPython, so if you could sign that, that would be great: https://www.python.org/psf/contrib/contrib-form/

Highlights from a contributor point of view:
- the CLA explicitly licenses your contributions under an open source license (typically the Apache License 2.0)
- the CLA grants the PSF authority to relicense your contributions under another open source license (this is currently the Python Software Foundation License)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Mon Feb 22 04:07:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 09:07:41 +0000
Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch
 exiting exceptions
In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za>
Message-ID: <1456132061.92.0.0120405054638.issue23430@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23430>
_______________________________________

From report at bugs.python.org  Mon Feb 22 04:16:18 2016
From: report at bugs.python.org (Filipp Andjelo)
Date: Mon, 22 Feb 2016 09:16:18 +0000
Subject: [issue26387] Crash calling sqlite3_close with invalid pointer
In-Reply-To: <1455818373.79.0.020961668279.issue26387@psf.upfronthosting.co.za>
Message-ID: <1456132578.57.0.741910453733.issue26387@psf.upfronthosting.co.za>


Filipp Andjelo added the comment:

Ok, the race condition seems not to be the real problem, since the patches didn't help. Don't want to do any assumptions anymore, but it seems like the python objects memory is deallocated before the sqlite connection was closed. The thing is, that this problem appears only on very heavy load with 40 parallel python processes and overall memory consumption of more than 240GiB. This high number is due to deactivated GC on our side, due to performance problems, we call it once the complete work is done. Unfortunately, I can't reproduce this error in "small", but here is the crash report (the crash comes from different parts of free(), sometimes with double free, sometimes invalid pointer or similar):

*** glibc detected *** /share/nds-buildtools/python/python-3.4.2-64_5/bin/python: free(): invalid next size (normal): 0x00000000058b72b0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x36e6275f4e]
/lib64/libc.so.6[0x36e6278cf0]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x23918)[0x7f785100a918]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(sqlite3_free+0x63)[0x7f785100b6b6]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x3193d)[0x7f785101893d]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x31a93)[0x7f7851018a93]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x31e6d)[0x7f7851018e6d]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x32735)[0x7f7851019735]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x3115d)[0x7f785101815d]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x3119e)[0x7f785101819e]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x33df2)[0x7f785101adf2]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x36441)[0x7f785101d441]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0x40e21)[0x7f7851027e21]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0xbbddf)[0x7f78510a2ddf]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(+0xbbcff)[0x7f78510a2cff]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(sqlite3_close+0x1d)[0x7f78510a2d23]
/share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so(pysqlite_connection_close+0x79)[0x7f7851002af9]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalFrameEx+0x64e3)[0x4c52e3]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalFrameEx+0x6e38)[0x4c5c38]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalFrameEx+0x6e38)[0x4c5c38]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalFrameEx+0x6e38)[0x4c5c38]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalFrameEx+0x6e38)[0x4c5c38]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalFrameEx+0x6e38)[0x4c5c38]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalCodeEx+0x8a7)[0x4c72a7]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyEval_EvalCode+0x3b)[0x4c736b]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python[0x4e7c61]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyRun_FileExFlags+0x115)[0x4e9a85]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(PyRun_SimpleFileExFlags+0xfa)[0x4eb2ea]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(Py_Main+0xa74)[0x41d8e4]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python(main+0x155)[0x41a465]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x36e621ed5d]
/share/nds-buildtools/python/python-3.4.2-64_5/bin/python[0x41a249]
======= Memory map: ========
00400000-005fe000 r-xp 00000000 00:1a 491451                             /share/nds-buildtools/python/python-3.4.2-64_5/bin/python3.4
007fd000-00857000 rw-p 001fd000 00:1a 491451                             /share/nds-buildtools/python/python-3.4.2-64_5/bin/python3.4
00857000-00872000 rw-p 00000000 00:00 0 
00c84000-0dd92000 rw-p 00000000 00:00 0                                  [heap]
36e5e00000-36e5e20000 r-xp 00000000 fd:00 2964                           /lib64/ld-2.12.so
36e601f000-36e6020000 r--p 0001f000 fd:00 2964                           /lib64/ld-2.12.so
36e6020000-36e6021000 rw-p 00020000 fd:00 2964                           /lib64/ld-2.12.so
36e6021000-36e6022000 rw-p 00000000 00:00 0 
36e6200000-36e638a000 r-xp 00000000 fd:00 3884                           /lib64/libc-2.12.so
36e638a000-36e658a000 ---p 0018a000 fd:00 3884                           /lib64/libc-2.12.so
36e658a000-36e658e000 r--p 0018a000 fd:00 3884                           /lib64/libc-2.12.so
36e658e000-36e658f000 rw-p 0018e000 fd:00 3884                           /lib64/libc-2.12.so
36e658f000-36e6594000 rw-p 00000000 00:00 0 
36e6600000-36e6602000 r-xp 00000000 fd:00 4585                           /lib64/libdl-2.12.so
36e6602000-36e6802000 ---p 00002000 fd:00 4585                           /lib64/libdl-2.12.so
36e6802000-36e6803000 r--p 00002000 fd:00 4585                           /lib64/libdl-2.12.so
36e6803000-36e6804000 rw-p 00003000 fd:00 4585                           /lib64/libdl-2.12.so
36e6a00000-36e6a17000 r-xp 00000000 fd:00 3891                           /lib64/libpthread-2.12.so
36e6a17000-36e6c17000 ---p 00017000 fd:00 3891                           /lib64/libpthread-2.12.so
36e6c17000-36e6c18000 r--p 00017000 fd:00 3891                           /lib64/libpthread-2.12.so
36e6c18000-36e6c19000 rw-p 00018000 fd:00 3891                           /lib64/libpthread-2.12.so
36e6c19000-36e6c1d000 rw-p 00000000 00:00 0 
36e6e00000-36e6e15000 r-xp 00000000 fd:00 8884                           /lib64/libz.so.1.2.3
36e6e15000-36e7014000 ---p 00015000 fd:00 8884                           /lib64/libz.so.1.2.3
36e7014000-36e7015000 r--p 00014000 fd:00 8884                           /lib64/libz.so.1.2.3
36e7015000-36e7016000 rw-p 00015000 fd:00 8884                           /lib64/libz.so.1.2.3
36e7200000-36e7207000 r-xp 00000000 fd:00 7022                           /lib64/librt-2.12.so
36e7207000-36e7406000 ---p 00007000 fd:00 7022                           /lib64/librt-2.12.so
36e7406000-36e7407000 r--p 00006000 fd:00 7022                           /lib64/librt-2.12.so
36e7407000-36e7408000 rw-p 00007000 fd:00 7022                           /lib64/librt-2.12.so
36e7600000-36e7683000 r-xp 00000000 fd:00 10439                          /lib64/libm-2.12.so
36e7683000-36e7882000 ---p 00083000 fd:00 10439                          /lib64/libm-2.12.so
36e7882000-36e7883000 r--p 00082000 fd:00 10439                          /lib64/libm-2.12.so
36e7883000-36e7884000 rw-p 00083000 fd:00 10439                          /lib64/libm-2.12.so
36e7a00000-36e7a1d000 r-xp 00000000 fd:00 5374                           /lib64/libselinux.so.1
36e7a1d000-36e7c1c000 ---p 0001d000 fd:00 5374                           /lib64/libselinux.so.1
36e7c1c000-36e7c1d000 r--p 0001c000 fd:00 5374                           /lib64/libselinux.so.1
36e7c1d000-36e7c1e000 rw-p 0001d000 fd:00 5374                           /lib64/libselinux.so.1
36e7c1e000-36e7c1f000 rw-p 00000000 00:00 0 
36e8200000-36e8216000 r-xp 00000000 fd:00 5071                           /lib64/libresolv-2.12.so
36e8216000-36e8416000 ---p 00016000 fd:00 5071                           /lib64/libresolv-2.12.so
36e8416000-36e8417000 r--p 00016000 fd:00 5071                           /lib64/libresolv-2.12.so
36e8417000-36e8418000 rw-p 00017000 fd:00 5071                           /lib64/libresolv-2.12.so
36e8418000-36e841a000 rw-p 00000000 00:00 0 
36e8600000-36e8616000 r-xp 00000000 fd:00 10440                          /lib64/libgcc_s-4.4.7-20120601.so.1
36e8616000-36e8815000 ---p 00016000 fd:00 10440                          /lib64/libgcc_s-4.4.7-20120601.so.1
36e8815000-36e8816000 rw-p 00015000 fd:00 10440                          /lib64/libgcc_s-4.4.7-20120601.so.1
36e8e00000-36e8e02000 r-xp 00000000 fd:00 18011                          /lib64/libutil-2.12.so
36e8e02000-36e9001000 ---p 00002000 fd:00 18011                          /lib64/libutil-2.12.so
36e9001000-36e9002000 r--p 00001000 fd:00 18011                          /lib64/libutil-2.12.so
36e9002000-36e9003000 rw-p 00002000 fd:00 18011                          /lib64/libutil-2.12.so
36ea600000-36ea602000 r-xp 00000000 fd:00 5005                           /lib64/libkeyutils.so.1.3
36ea602000-36ea801000 ---p 00002000 fd:00 5005                           /lib64/libkeyutils.so.1.3
36ea801000-36ea802000 r--p 00001000 fd:00 5005                           /lib64/libkeyutils.so.1.3
36ea802000-36ea803000 rw-p 00002000 fd:00 5005                           /lib64/libkeyutils.so.1.3
36eaa00000-36eaa03000 r-xp 00000000 fd:00 6725                           /lib64/libcom_err.so.2.1
36eaa03000-36eac02000 ---p 00003000 fd:00 6725                           /lib64/libcom_err.so.2.1
36eac02000-36eac03000 r--p 00002000 fd:00 6725                           /lib64/libcom_err.so.2.1
36eac03000-36eac04000 rw-p 00003000 fd:00 6725                           /lib64/libcom_err.so.2.1
36eb200000-36eb3b9000 r-xp 00000000 fd:00 9400                           /usr/lib64/libcrypto.so.1.0.1e
36eb3b9000-36eb5b8000 ---p 001b9000 fd:00 9400                           /usr/lib64/libcrypto.so.1.0.1e
36eb5b8000-36eb5d3000 r--p 001b8000 fd:00 9400                           /usr/lib64/libcrypto.so.1.0.1e
36eb5d3000-36eb5df000 rw-p 001d3000 fd:00 9400                           /usr/lib64/libcrypto.so.1.0.1e
36eb5df000-36eb5e3000 rw-p 00000000 00:00 0 
36eb600000-36eb641000 r-xp 00000000 fd:00 6869                           /lib64/libgssapi_krb5.so.2.2
36eb641000-36eb841000 ---p 00041000 fd:00 6869                           /lib64/libgssapi_krb5.so.2.2
36eb841000-36eb842000 r--p 00041000 fd:00 6869                           /lib64/libgssapi_krb5.so.2.2
36eb842000-36eb844000 rw-p 00042000 fd:00 6869                           /lib64/libgssapi_krb5.so.2.2
36ec600000-36ec60a000 r-xp 00000000 fd:00 5394                           /lib64/libkrb5support.so.0.1
36ec60a000-36ec809000 ---p 0000a000 fd:00 5394                           /lib64/libkrb5support.so.0.1
36ec809000-36ec80a000 r--p 00009000 fd:00 5394                           /lib64/libkrb5support.so.0.1
36ec80a000-36ec80b000 rw-p 0000a000 fd:00 5394                           /lib64/libkrb5support.so.0.1
36eca00000-36eca29000 r-xp 00000000 fd:00 5413                           /lib64/libk5crypto.so.3.1
36eca29000-36ecc29000 ---p 00029000 fd:00 5413                           /lib64/libk5crypto.so.3.1
36ecc29000-36ecc2a000 r--p 00029000 fd:00 5413                           /lib64/libk5crypto.so.3.1
36ecc2a000-36ecc2b000 rw-p 0002a000 fd:00 5413                           /lib64/libk5crypto.so.3.1
36ecc2b000-36ecc2c000 rw-p 00000000 00:00 0 
36ece00000-36ecedb000 r-xp 00000000 fd:00 6862                           /lib64/libkrb5.so.3.3
36ecedb000-36ed0db000 ---p 000db000 fd:00 6862                           /lib64/libkrb5.so.3.3
36ed0db000-36ed0e5000 r--p 000db000 fd:00 6862                           /lib64/libkrb5.so.3.3
36ed0e5000-36ed0e7000 rw-p 000e5000 fd:00 6862                           /lib64/libkrb5.so.3.3
36ede00000-36ede62000 r-xp 00000000 fd:00 22840                          /usr/lib64/libssl.so.1.0.1e
36ede62000-36ee061000 ---p 00062000 fd:00 22840                          /usr/lib64/libssl.so.1.0.1e
36ee061000-36ee065000 r--p 00061000 fd:00 22840                          /usr/lib64/libssl.so.1.0.1e
36ee065000-36ee06c000 rw-p 00065000 fd:00 22840                          /usr/lib64/libssl.so.1.0.1e
7f783c000000-7f783c021000 rw-p 00000000 00:00 0 
7f783c021000-7f7840000000 ---p 00000000 00:00 0 
7f7842d72000-7f7842db2000 rw-p 00000000 00:00 0 
7f7842f72000-7f7842fb2000 rw-p 00000000 00:00 0 
7f78441b2000-7f7844232000 rw-p 00000000 00:00 0 
7f7846573000-7f78465f3000 rw-p 00000000 00:00 0 
7f7846873000-7f78468b3000 rw-p 00000000 00:00 0 
7f7847033000-7f7847073000 rw-p 00000000 00:00 0 
7f7847673000-7f78476b3000 rw-p 00000000 00:00 0 
7f7847bb4000-7f7847bf4000 rw-p 00000000 00:00 0 
7f7848974000-7f78489b4000 rw-p 00000000 00:00 0 
7f7849134000-7f7849174000 rw-p 00000000 00:00 0 
7f7849234000-7f7849274000 rw-p 00000000 00:00 0 
7f784a6f5000-7f784a775000 rw-p 00000000 00:00 0 
7f784a7b5000-7f784a835000 rw-p 00000000 00:00 0 
7f784acb5000-7f784acf5000 rw-p 00000000 00:00 0 
7f784ae35000-7f784ae75000 rw-p 00000000 00:00 0 
7f784bcb6000-7f784bcf6000 rw-p 00000000 00:00 0 
7f784bd36000-7f784bd76000 rw-p 00000000 00:00 0 
7f784c976000-7f784c9b6000 rw-p 00000000 00:00 0 
7f784c9f6000-7f784ca36000 rw-p 00000000 00:00 0 
7f784cd77000-7f784cdf7000 rw-p 00000000 00:00 0 
7f784d9c5000-7f784da05000 rw-p 00000000 00:00 0 
7f784dd45000-7f784dd85000 rw-p 00000000 00:00 0 
7f784dfc5000-7f784e005000 rw-p 00000000 00:00 0 
7f784e345000-7f784e385000 rw-p 00000000 00:00 0 
7f784e8c5000-7f784e905000 rw-p 00000000 00:00 0 
7f784ea46000-7f784ea86000 rw-p 00000000 00:00 0 
7f784ebc6000-7f784ec06000 rw-p 00000000 00:00 0 
7f784ed86000-7f784edc6000 rw-p 00000000 00:00 0 
7f784f486000-7f784f4c6000 rw-p 00000000 00:00 0 
7f784f546000-7f784f586000 rw-p 00000000 00:00 0 
7f784f646000-7f784f686000 rw-p 00000000 00:00 0 
7f784f805000-7f7850906000 rw-p 00000000 00:00 0 
7f7850906000-7f785091d000 r-xp 00000000 00:1a 484827                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_pickle.cpython-34m.so
7f785091d000-7f7850b1c000 ---p 00017000 00:1a 484827                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_pickle.cpython-34m.so
7f7850b1c000-7f7850b20000 rw-p 00016000 00:1a 484827                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_pickle.cpython-34m.so
7f7850b20000-7f7850d61000 rw-p 00000000 00:00 0 
7f7850d61000-7f7850d66000 r-xp 00000000 00:1a 484828                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_hashlib.cpython-34m.so
7f7850d66000-7f7850f66000 ---p 00005000 00:1a 484828                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_hashlib.cpython-34m.so
7f7850f66000-7f7850f67000 rw-p 00005000 00:1a 484828                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_hashlib.cpython-34m.so
7f7850f67000-7f7850fe7000 rw-p 00000000 00:00 0 
7f7850fe7000-7f785113d000 r-xp 00000000 00:1a 484839                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so
7f785113d000-7f785133c000 ---p 00156000 00:1a 484839                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so
7f785133c000-7f7851345000 rw-p 00155000 00:1a 484839                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_sqlite3.cpython-34m.so
7f7851345000-7f7851346000 rw-p 00000000 00:00 0 
7f7851346000-7f785135f000 r-xp 00000000 00:1a 484811                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/zlib.cpython-34m.so
7f785135f000-7f785155f000 ---p 00019000 00:1a 484811                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/zlib.cpython-34m.so
7f785155f000-7f7851561000 rw-p 00019000 00:1a 484811                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/zlib.cpython-34m.so
7f7851561000-7f7851569000 r-xp 00000000 00:1a 484837                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/binascii.cpython-34m.so
7f7851569000-7f7851768000 ---p 00008000 00:1a 484837                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/binascii.cpython-34m.so
7f7851768000-7f7851769000 rw-p 00007000 00:1a 484837                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/binascii.cpython-34m.so
7f7851769000-7f78517a9000 rw-p 00000000 00:00 0 
7f78517a9000-7f78517ab000 r-xp 00000000 00:1a 484815                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/grp.cpython-34m.so
7f78517ab000-7f78519ab000 ---p 00002000 00:1a 484815                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/grp.cpython-34m.so
7f78519ab000-7f78519ac000 rw-p 00002000 00:1a 484815                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/grp.cpython-34m.so
7f78519ac000-7f78519ec000 rw-p 00000000 00:00 0 
7f78519ec000-7f7851a21000 r-xp 00000000 00:1a 484822                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/pyexpat.cpython-34m.so
7f7851a21000-7f7851c20000 ---p 00035000 00:1a 484822                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/pyexpat.cpython-34m.so
7f7851c20000-7f7851c24000 rw-p 00034000 00:1a 484822                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/pyexpat.cpython-34m.so
7f7851c24000-7f7851c31000 r-xp 00000000 00:1a 484847                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_elementtree.cpython-34m.so
7f7851c31000-7f7851e30000 ---p 0000d000 00:1a 484847                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_elementtree.cpython-34m.so
7f7851e30000-7f7851e32000 rw-p 0000c000 00:1a 484847                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_elementtree.cpython-34m.so
7f7851e32000-7f7852172000 rw-p 00000000 00:00 0 
7f78521a6000-7f78523e6000 rw-p 00000000 00:00 0 
7f78523e6000-7f78523ee000 r-xp 00000000 00:1a 484843                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_struct.cpython-34m.so
7f78523ee000-7f78525ed000 ---p 00008000 00:1a 484843                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_struct.cpython-34m.so
7f78525ed000-7f78525f0000 rw-p 00007000 00:1a 484843                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_struct.cpython-34m.so
7f78525f0000-7f7852670000 rw-p 00000000 00:00 0 
7f7852670000-7f7852681000 r-xp 00000000 00:1a 484823                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_datetime.cpython-34m.so
7f7852681000-7f7852881000 ---p 00011000 00:1a 484823                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_datetime.cpython-34m.so
7f7852881000-7f7852884000 rw-p 00011000 00:1a 484823                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_datetime.cpython-34m.so
7f7852884000-7f785288c000 r-xp 00000000 00:1a 484797                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/math.cpython-34m.so
7f785288c000-7f7852a8c000 ---p 00008000 00:1a 484797                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/math.cpython-34m.so
7f7852a8c000-7f7852a8e000 rw-p 00008000 00:1a 484797                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/math.cpython-34m.so
7f7852a8e000-7f7852ace000 rw-p 00000000 00:00 0 
7f7852ace000-7f7852acf000 r-xp 00000000 00:1a 484830                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_opcode.cpython-34m.so
7f7852acf000-7f7852cce000 ---p 00001000 00:1a 484830                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_opcode.cpython-34m.so
7f7852cce000-7f7852ccf000 rw-p 00000000 00:1a 484830                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_opcode.cpython-34m.so
7f7852ccf000-7f7852d4f000 rw-p 00000000 00:00 0 
7f7852d4f000-7f7852d5e000 r-xp 00000000 00:1a 484792                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_socket.cpython-34m.so
7f7852d5e000-7f7852f5e000 ---p 0000f000 00:1a 484792                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_socket.cpython-34m.so
7f7852f5e000-7f7852f63000 rw-p 0000f000 00:1a 484792                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_socket.cpython-34m.so
7f7852f63000-7f7852f66000 r-xp 00000000 00:1a 484846                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_heapq.cpython-34m.so
7f7852f66000-7f7853165000 ---p 00003000 00:1a 484846                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_heapq.cpython-34m.so
7f7853165000-7f7853168000 rw-p 00002000 00:1a 484846                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/_heapq.cpython-34m.so
7f7853168000-7f785316d000 r-xp 00000000 00:1a 484819                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/time.cpython-34m.so
7f785316d000-7f785336c000 ---p 00005000 00:1a 484819                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/time.cpython-34m.so
7f785336c000-7f785336f000 rw-p 00004000 00:1a 484819                     /share/nds-buildtools/python/python-3.4.2-64_5/lib/python3.4/lib-dynload/time.cpython-34m.so
7f785336f000-7f78533af000 rw-p 00000000 00:00 0 
7f78533b0000-7f7853470000 rw-p 00000000 00:00 0 
7f78534a1000-7f78535e1000 rw-p 00000000 00:00 0 
7f78535e1000-7f7859472000 r--p 00000000 fd:00 34413                      /usr/lib/locale/locale-archive
7f7859472000-7f7859476000 rw-p 00000000 00:00 0 
7f785947d000-7f7859484000 r--s 00000000 fd:00 152113                     /usr/lib64/gconv/gconv-modules.cache
7f7859484000-7f7859485000 rw-p 00000000 00:00 0 
7ffea445d000-7ffea447c000 rw-p 00000000 00:00 0                          [stack]
7ffea44bc000-7ffea44bd000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

----------
title: Race condition in sqlite module -> Crash calling sqlite3_close with invalid pointer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26387>
_______________________________________

From report at bugs.python.org  Mon Feb 22 04:26:51 2016
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 22 Feb 2016 09:26:51 +0000
Subject: [issue19982] Add a "target" parameter to runpy.run_path and
 runpy.run_module
In-Reply-To: <1387027323.14.0.795736210788.issue19982@psf.upfronthosting.co.za>
Message-ID: <1456133211.17.0.790541346025.issue19982@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19982>
_______________________________________

From report at bugs.python.org  Mon Feb 22 04:46:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 09:46:47 +0000
Subject: [issue26390] hashlib's pbkdf2_hmac documentation "rounds" does not
 match source
In-Reply-To: <1455840057.88.0.0946194046166.issue26390@psf.upfronthosting.co.za>
Message-ID: <1456134407.44.0.209962351133.issue26390@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is an updated patch. I also fixed the hash_name parameter, some more minor offences in the documentation, and added a test case.

----------
Added file: http://bugs.python.org/file42002/pbkdf2_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26390>
_______________________________________

From report at bugs.python.org  Mon Feb 22 04:56:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 09:56:15 +0000
Subject: [issue26403] Don't call sendto in socketserver.DatagramRequestHandler
 if there is nothing to send
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456134975.93.0.366619238992.issue26403@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually there is precedent for some asynchronous errors due to the client to be ignored:

* Revision 87d3f91e44d4: Catch socket.error (now OSError) from accept()
* r73819: Catch socket.error (OSError) to handle ENOTCONN from shutdown()
* Revision 7e5d7ef4634d: Catch socket.error from sendall(); apparently Windows decides to locally drop the connection and raises ECONNABORTED

So it might be reasonable to catch FileNotFoundError (ENOENT) from sendto(), for Unix domain datagram servers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:12:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Feb 2016 10:12:13 +0000
Subject: [issue26261] NamedTemporaryFile documentation is vague about the
 `name` attribute
In-Reply-To: <1454347282.51.0.892341568817.issue26261@psf.upfronthosting.co.za>
Message-ID: <20160222101210.1985.51807@psf.io>


Roundup Robot added the comment:

New changeset f1982e1426ce by Martin Panter in branch '3.5':
Issue #26261: Clarify NamedTemporaryFile name attribute vs file.name
https://hg.python.org/cpython/rev/f1982e1426ce

New changeset 837bae8c8ae7 by Martin Panter in branch 'default':
Issue #26261: Merge NamedTemporaryFile docs from 3.5
https://hg.python.org/cpython/rev/837bae8c8ae7

New changeset 27a140558a47 by Martin Panter in branch '2.7':
Issue #26261: Clarify NamedTemporaryFile name attribute vs file.name
https://hg.python.org/cpython/rev/27a140558a47

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26261>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:17:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Feb 2016 10:17:27 +0000
Subject: [issue26268] Update python.org installers to use OpenSSL 1.0.2f
In-Reply-To: <1454441057.55.0.0354413518189.issue26268@psf.upfronthosting.co.za>
Message-ID: <20160222101724.1971.94056@psf.io>


Roundup Robot added the comment:

New changeset 3be29e684ccf by Zachary Ware in branch '2.7':
Issue #26268: Update Windows builds to use OpenSSL 1.0.2f
https://hg.python.org/cpython/rev/3be29e684ccf

New changeset e1187d3204e9 by Zachary Ware in branch '3.5':
Issue #26268: Update the prepare_ssl.py script
https://hg.python.org/cpython/rev/e1187d3204e9

New changeset 82afdf5a8c7b by Zachary Ware in branch '3.5':
Issue #26268: Update Windows builds to use OpenSSL 1.0.2f
https://hg.python.org/cpython/rev/82afdf5a8c7b

New changeset 365ab6287783 by Zachary Ware in branch 'default':
Issue #26268: Merge with 3.5
https://hg.python.org/cpython/rev/365ab6287783

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26268>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:25:46 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 22 Feb 2016 10:25:46 +0000
Subject: [issue26268] Update python.org installers to use OpenSSL 1.0.2f
In-Reply-To: <1454441057.55.0.0354413518189.issue26268@psf.upfronthosting.co.za>
Message-ID: <1456136746.07.0.678902447884.issue26268@psf.upfronthosting.co.za>


Zachary Ware added the comment:

OpenSSL seems to have FUBARed their release process, such that the include/ directory no longer includes anything.  As such I had to update prepare_ssl.py to handle creating include directories for 32 and 64 bit.  This is somewhat wasteful since the only thing really different between the two is opensslconf.h, but this is the simplest approach.

With that update, builds of 2.7 using the old project files in PC/VS9.0 now require Perl to be available to create the makefile.  I don't think this is an undue burden; on the other hand, making prepare_ssl.py handle the requirements of the old build_ssl.py is far more effort than I want to invest.

Steve, would you mind double-checking my work if you get a chance?  I committed in a bit of a hurry at the request of Intel.

----------
resolution:  -> fixed
stage: needs patch -> commit review
status: open -> pending
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26268>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:50:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 10:50:36 +0000
Subject: [issue26392] socketserver.BaseServer.close_server should stop
 serve_forever
In-Reply-To: <1455901217.04.0.582313607927.issue26392@psf.upfronthosting.co.za>
Message-ID: <1456138236.97.0.0906451544633.issue26392@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suggest to reject this. Checking a flag before using a shared file descriptor is a recipe for a race condition, and in this case, unspecified behaviour: <http://man7.org/linux/man-pages/man2/select.2.html#NOTES> (applies to select and poll).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26392>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:55:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 10:55:43 +0000
Subject: [issue26261] NamedTemporaryFile documentation is vague about the
 `name` attribute
In-Reply-To: <1454347282.51.0.892341568817.issue26261@psf.upfronthosting.co.za>
Message-ID: <1456138543.15.0.612340919899.issue26261@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26261>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:56:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Feb 2016 10:56:22 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456138582.93.0.366756559207.issue26404@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would support this change, as long as we aren?t supporting using server_close() to stop the server loop at the same time.

It might be worth updating other example code that uses server_close(), in particular in the xmlrpc.server documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Mon Feb 22 06:59:17 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 22 Feb 2016 11:59:17 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1456142357.28.0.701456349951.issue22234@psf.upfronthosting.co.za>


Antti Haapala added the comment:

I believe `urlparse` should throw a `TypeError` if not isinstance(url, (str, bytes))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Mon Feb 22 07:25:22 2016
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bence_Gedai?=)
Date: Mon, 22 Feb 2016 12:25:22 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1456143922.54.0.791645462266.issue21042@psf.upfronthosting.co.za>


Tam?s Bence Gedai added the comment:

Updated the patch to remove the code duplication, now it stores the values that are calculated in the setUpClass method. It was a good and simple idea, I should have come up with it... :)

I'm pretty sure I got the errors during configuration because of the gcc version I have.

----------
Added file: http://bugs.python.org/file42003/find_lib_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Mon Feb 22 07:38:53 2016
From: report at bugs.python.org (=?utf-8?q?Ilja_Everil=C3=A4?=)
Date: Mon, 22 Feb 2016 12:38:53 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
Message-ID: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>


New submission from Ilja Everil?:

When passing a class implementing the dunder __iter__ that raises to csv.writer.writerows it hides the original exception and raises a TypeError instead.

In the raised TypeError the __context__ and __cause__ both are None.

For example:

>>> class X:
...  def __iter__(self):
...   raise RuntimeError("I'm hidden")
... 
>>> x = X()
>>> list(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __iter__
RuntimeError: I'm hidden
>>> import csv
>>> csv.writer(open('foo.csv', 'w', newline='')).writerows(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: writerows() argument must be iterable
>>> try:
...  csv.writer(open('foo.csv', 'w', newline='')).writerows(x)
... except TypeError as e:
...  e_ = e
>>> e_.__context__ is None
True
>>> e_.__cause__ is None
True

It would seem that for reasons unknown to me either PyObject_GetIter loses the exception context or the call to PyErr_SetString in csv_writerows hides it.

----------
messages: 260673
nosy: Ilja Everil?
priority: normal
severity: normal
status: open
title: csv.writer.writerows masks exceptions from __iter__
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Mon Feb 22 07:50:31 2016
From: report at bugs.python.org (Catalin Gabriel Manciu)
Date: Mon, 22 Feb 2016 12:50:31 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1456145431.61.0.43549566733.issue26249@psf.upfronthosting.co.za>


Catalin Gabriel Manciu added the comment:

Hi all,

Please find below the results from a complete GUPB run on a patched CPython 3.6. In average, an improvement of about 2.1% can be observed. 

I'm also attaching an implementation of the patch for CPython 2.7 and its benchmark results. On GUPB the average performance boost is 1.5%. 
In addition we are also seeing a 2.1% increase in throughput rate from our OpenStack Swift setup as measured by ssbench.

Compared to my proposition in issue #26382, this patch yields slightly better results for CPython 3.6, gaining an average of +0.36% on GUPB,
and similar results for CPython 2.7.


Hardware and OS configuration:
==============================
Hardware:           Intel XEON (Haswell-EP)

BIOS settings:      Intel Turbo Boost Technology: false
                    Hyper-Threading: false                  

OS:                 Ubuntu 14.04.2 LTS

OS configuration:   Address Space Layout Randomization (ASLR) disabled to reduce run
                    to run variation by echo 0 > /proc/sys/kernel/randomize_va_space
                    CPU frequency set fixed at 2.3GHz

Repository info:
================
CPython2 : 2d8e8d0e7162 (2.7)
CPython3 : f9391e2b74a5 tip

Results
=======

Table 1: CPython 3 GUPB results
-------------------------------
unpickle_list           22.74%
mako_v2                 9.13%
nqueens                 6.32%
meteor_contest          5.61%
fannkuch                5.34%
simple_logging          5.28%
formatted_logging       5.06%
fastunpickle            4.37%
json_dump_v2            3.10%
regex_compile           3.01%
raytrace                2.95%
pathlib                 2.43%
tornado_http            2.22%
django_v3               1.94%
telco                   1.65%
pickle_list             1.59%
chaos                   1.50%
etree_process           1.48%
fastpickle              1.34%
silent_logging          1.12%
2to3                    1.09%
float                   1.01%
nbody                   0.89%
normal_startup          0.86%
startup_nosite          0.79%
richards                0.67%
regex_v8                0.61%
etree_generate          0.57%
hexiom2                 0.54%
pickle_dict             0.20%
call_simple             0.18%
spectral_norm           0.17%
regex_effbot            0.16%
unpack_sequence         0.00%
call_method_unknown    -0.04%
chameleon_v2           -0.07%
json_load              -0.08%
etree_parse            -0.09%
pidigits               -0.15%
go                     -0.16%
etree_iterparse        -0.22%
call_method_slots      -0.49%
call_method            -0.97%


Table 2: CPython 2 GUPB results
-------------------------------
unpickle_list           16.88%
json_load               11.74%
fannkuch                8.11%
mako_v2                 6.91%
meteor_contest          6.27%
slowpickle              4.81%
nqueens                 4.46%
html5lib_warmup         3.53%
chaos                   2.67%
regex_v8                2.56%
html5lib                2.34%
fastunpickle            2.32%
tornado_http            2.23%
rietveld                2.15%
simple_logging          1.82%
normal_startup          1.57%
call_method_slots       1.53%
telco                   1.49%
regex_compile           1.47%
spectral_norm           1.36%
hg_startup              1.27%
regex_effbot            1.18%
nbody                   1.02%
2to3                    1.01%
pybench                 0.99%
chameleon_v2            0.98%
slowunpickle            0.93%
startup_nosite          0.92%
pickle_list             0.89%
richards                0.56%
django_v3               0.48%
json_dump_v2            0.41%
raytrace                0.38%
unpack_sequence         0.00%
float                  -0.05%
slowspitfire           -0.07%
go                     -0.24%
hexiom2                -0.26%
spambayes              -0.27%
pickle_dict            -0.30%
etree_parse            -0.32%
pidigits               -0.41%
etree_iterparse        -0.47%
bzr_startup            -0.55%
fastpickle             -0.74%
etree_process          -0.96%
formatted_logging      -1.01%
call_simple            -1.08%
pathlib                -1.12%
silent_logging         -1.22%
etree_generate         -1.23%
call_method_unknown    -2.14%
call_method            -2.22%

Table 3: OpenStack Swift ssbench results
----------------------------------------
ssbench                 2.11%

----------
nosy: +catalin.manciu
Added file: http://bugs.python.org/file42004/pymem_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Mon Feb 22 07:56:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Feb 2016 12:56:33 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1456145793.88.0.656552687759.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Compared to my proposition in issue #26382, this patch yields slightly better results for CPython 3.6, gaining an average of +0.36% on GUPB,
and similar results for CPython 2.7.

IMHO this change is too young to be backported to Python 2.7. I wrote it for Python 3.6 only. For Python 2.7, I suggest to write patches with narrow scope, as you did for the patch only modifying the list type.

"""
Table 1: CPython 3 GUPB results
-------------------------------
unpickle_list           22.74%
mako_v2                 9.13%
nqueens                 6.32%
meteor_contest          5.61%
fannkuch                5.34%
simple_logging          5.28%
formatted_logging       5.06%
"""

I surprised to see slow-down, but I prefer to think that changes smaller than 5% are pure noise.

The good news is the long list of benchmarks with speedup larger than 5.0% :-) 22% on unpick list is nice to have too!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Mon Feb 22 08:24:39 2016
From: report at bugs.python.org (thefourtheye)
Date: Mon, 22 Feb 2016 13:24:39 +0000
Subject: [issue26408] pep-8 requires few corrections
Message-ID: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>


New submission from thefourtheye:

1. It doesn't have the Reference 4 used anywhere in the doc.

2. The `if` condition is not properly ended in the Programming Recommendation section.

3. Apart from that few grammatical changes are necessary I believe.

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 260676
nosy: docs at python, thefourtheye
priority: normal
severity: normal
status: open
title: pep-8 requires few corrections
type: enhancement
Added file: http://bugs.python.org/file42005/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 08:35:56 2016
From: report at bugs.python.org (thefourtheye)
Date: Mon, 22 Feb 2016 13:35:56 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>
Message-ID: <1456148156.66.0.263011998823.issue26408@psf.upfronthosting.co.za>


Changes by thefourtheye <thechargingvolcano at gmail.com>:


----------
title: pep-8 requires few corrections -> pep-8 requires a few corrections

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 08:36:26 2016
From: report at bugs.python.org (Aivar Annamaa)
Date: Mon, 22 Feb 2016 13:36:26 +0000
Subject: [issue26409] Support latest Tcl/Tk on future versions of Mac installer
Message-ID: <1456148186.12.0.689143317593.issue26409@psf.upfronthosting.co.za>


New submission from Aivar Annamaa:

Currently Mac installer can create only Tk 8.5 compatible Tkinter, even if Tcl/Tk 8.6 is installed.

Unofficial distributions doesn't seem to have problems with Tk 8.6 on Mac. I think official installer should be upgraded as well.

Best option for users would be bundling Tcl/Tk 8.6 with installer, just like Windows installer does.

----------
components: Installation, Macintosh, Tkinter
messages: 260677
nosy: Aivar.Annamaa, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Support latest Tcl/Tk on future versions of Mac installer
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26409>
_______________________________________

From report at bugs.python.org  Mon Feb 22 08:42:56 2016
From: report at bugs.python.org (Catalin Gabriel Manciu)
Date: Mon, 22 Feb 2016 13:42:56 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1456148576.79.0.583524556966.issue26382@psf.upfronthosting.co.za>


Catalin Gabriel Manciu added the comment:

Our Haswell-EP OpenStack Swift setup shows a 1% improvement in throughput rate using CPython 2.7 (5715a6d9ff12) with this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Mon Feb 22 08:43:37 2016
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Feb 2016 13:43:37 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>
Message-ID: <1456148617.33.0.561447391948.issue26408@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I can't really comment on the grammar changes, but the rest looks good to me.

This is not very smooth, in both versions:

-Consistency within one module or function is most important.
+Consistency within one module or function is the most important thing.
 
-But most importantly: know when to be inconsistent -- sometimes the
-style guide just doesn't apply.  When in doubt, use your best
+But more importantly: know when to be inconsistent -- sometimes the
+style guide just isn't applicable.  When in doubt, use your best

(Consistency is already *most* important, but then comes something *more* important?)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 08:58:04 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Feb 2016 13:58:04 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>
Message-ID: <1456149484.38.0.266162577159.issue26408@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 09:02:47 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Feb 2016 14:02:47 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>
Message-ID: <1456149767.29.0.391042878964.issue26408@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: docs at python -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 09:03:04 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Feb 2016 14:03:04 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>
Message-ID: <1456149784.09.0.126121444271.issue26408@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Thanks!  I like some of the changes, and may tweak a few others.  Thanks for the contribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 09:04:09 2016
From: report at bugs.python.org (Catalin Gabriel Manciu)
Date: Mon, 22 Feb 2016 14:04:09 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1456149849.88.0.243844177335.issue26249@psf.upfronthosting.co.za>


Catalin Gabriel Manciu added the comment:

I've just posted the results to an OpenStack Swift benchmark run using the patch from my proposition, issue #26382. 
Victor's patch, applied to CPython 2.7, adds an extra 1% compared to mine (which improved throughput by 1%), effectively doubling the performance gain. Swift is a highly complex real-world workload, so this result is quite significant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Mon Feb 22 09:05:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Feb 2016 14:05:52 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>
Message-ID: <20160222140549.2200.26657@psf.io>


Roundup Robot added the comment:

New changeset 43d612fc6b12 by Barry Warsaw in branch 'default':
Gramatical and other improvements given by thefourtheye.
https://hg.python.org/peps/rev/43d612fc6b12

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 09:20:48 2016
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Feb 2016 14:20:48 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456147479.45.0.358658656612.issue26408@psf.upfronthosting.co.za>
Message-ID: <1456150848.11.0.582401983242.issue26408@psf.upfronthosting.co.za>


Georg Brandl added the comment:

-Consistency within one module or function is most important.
+Consistency within one module or function is the most important.

You left out "thing" from the patch; is that intended?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 10:11:34 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 22 Feb 2016 15:11:34 +0000
Subject: [issue25080] The example-code for making XML-RPC requests through
 proxy, fail!
In-Reply-To: <1442059715.67.0.31958758043.issue25080@psf.upfronthosting.co.za>
Message-ID: <1456153894.48.0.806598233289.issue25080@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This has been fixed in cf842a8ccb77. Thank you for reporting this, Kostis!

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25080>
_______________________________________

From report at bugs.python.org  Mon Feb 22 10:15:16 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Mon, 22 Feb 2016 15:15:16 +0000
Subject: [issue26410] "incompatible pointer type" while compiling Python3.5.1
Message-ID: <1456154116.48.0.737124559195.issue26410@psf.upfronthosting.co.za>


New submission from Devyn Johnson:

When compiling Python3.5.1 on Ubuntu 15.10 (64-bit), I see three "incompatible pointer type" warnings (copy-pasted below). I understand that they can be ignored. However, from my experience with programming (in C STD-2011), "weird bugs" and other odd behavior disappears when warnings like this are fixed.

Environment flags (such as CFLAGS) and the configure settings do not appear to influence that warning (i.e. my settings are irrelevant to this bug report).

I hope that this bug report is found to be helpful. Also, thank you Python-developers for making and maintaining Python as open-source software.

Python/ceval_gil.h: In function drop_gil:
Python/ceval_gil.h:181:9: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
         _Py_atomic_store_relaxed(&gil_last_holder, tstate);
         ^
Python/ceval_gil.h: In function take_gil:
Python/ceval_gil.h:243:9: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
         _Py_atomic_store_relaxed(&gil_last_holder, tstate);
         ^
Python/pystate.c: In function PyThreadState_Swap:
Python/pystate.c:509:5: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
     _Py_atomic_store_relaxed(&_PyThreadState_Current, newts);

----------
components: Build
messages: 260685
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: "incompatible pointer type" while compiling Python3.5.1
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26410>
_______________________________________

From report at bugs.python.org  Mon Feb 22 10:22:59 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Mon, 22 Feb 2016 15:22:59 +0000
Subject: [issue26411] Suggestion concerning compile-time warnings
Message-ID: <1456154579.82.0.723903517664.issue26411@psf.upfronthosting.co.za>


New submission from Devyn Johnson:

I understand that compile-time warnings can typically be ignored. However, from my experience with programming (C STD-2011, for instance), "weird bugs", non-easily-replicable bugs, and odd behaviors disappear when warnings like this are fixed. I also understand that it will be time-consuming to fix each and every minor warning.

I have also noticed (in my own coding-projects) that fixing all warnings generated by -Wextra (and the many other warning flags) allows the compiler to more easily apply various optimizations.

----------
components: Interpreter Core
messages: 260686
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Suggestion concerning compile-time warnings
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26411>
_______________________________________

From report at bugs.python.org  Mon Feb 22 10:46:16 2016
From: report at bugs.python.org (Simon Bernier St-Pierre)
Date: Mon, 22 Feb 2016 15:46:16 +0000
Subject: [issue26395] asyncio does not support yielding from recvfrom
 (socket/udp)
In-Reply-To: <1456008629.58.0.297729770488.issue26395@psf.upfronthosting.co.za>
Message-ID: <1456155976.07.0.812356530617.issue26395@psf.upfronthosting.co.za>


Changes by Simon Bernier St-Pierre <sbernierstpierre at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26395>
_______________________________________

From report at bugs.python.org  Mon Feb 22 11:14:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Feb 2016 16:14:47 +0000
Subject: [issue26410] "incompatible pointer type" while compiling Python3.5.1
In-Reply-To: <1456154116.48.0.737124559195.issue26410@psf.upfronthosting.co.za>
Message-ID: <1456157687.08.0.73878140509.issue26410@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue is a duplicate of the issue #26161, waybe we can backport the changeset ff68ffcc6244 to the Python 3.5 branch.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26410>
_______________________________________

From report at bugs.python.org  Mon Feb 22 11:29:09 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Feb 2016 16:29:09 +0000
Subject: [issue26408] pep-8 requires a few corrections
In-Reply-To: <1456150848.11.0.582401983242.issue26408@psf.upfronthosting.co.za>
Message-ID: <20160222112905.3a97be83@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On Feb 22, 2016, at 02:20 PM, Georg Brandl wrote:

>Georg Brandl added the comment:
>
>-Consistency within one module or function is most important.
>+Consistency within one module or function is the most important.
>
>You left out "thing" from the patch; is that intended?

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26408>
_______________________________________

From report at bugs.python.org  Mon Feb 22 11:43:07 2016
From: report at bugs.python.org (Anish Shah)
Date: Mon, 22 Feb 2016 16:43:07 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1456159387.85.0.351452405565.issue22234@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Mon Feb 22 11:45:36 2016
From: report at bugs.python.org (Anish Shah)
Date: Mon, 22 Feb 2016 16:45:36 +0000
Subject: [issue26396] Create json.JSONType
In-Reply-To: <1456015468.57.0.0882861590724.issue26396@psf.upfronthosting.co.za>
Message-ID: <1456159536.8.0.741902549498.issue26396@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy: +anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26396>
_______________________________________

From report at bugs.python.org  Mon Feb 22 11:53:07 2016
From: report at bugs.python.org (Anish Shah)
Date: Mon, 22 Feb 2016 16:53:07 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
In-Reply-To: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>
Message-ID: <1456159987.25.0.362042432524.issue26281@psf.upfronthosting.co.za>


Anish Shah added the comment:

Hi Brett, I'm looking for some issues to solve. Is this issue confirmed? Can I work on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26281>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:08:01 2016
From: report at bugs.python.org (Payden Comer)
Date: Mon, 22 Feb 2016 17:08:01 +0000
Subject: [issue26412] Segmentation Fault: 11
Message-ID: <1456160879.85.0.401353388041.issue26412@psf.upfronthosting.co.za>


New submission from Payden Comer:

A "Segmentation Fault:11" crash occurs on OS X El Captain when using `return pysodium.sodium.crypto_box_beforenm(clientpub, serverprivatekey)`, with args as None, serverprivatekey, rather than a traceback dissallowing a NoneType Argument.

Crash Log attached.

----------
components: Macintosh
files: Python_2016-02-22-110201_Shuros-MacBook-Pro.crash
messages: 260690
nosy: ned.deily, ronaldoussoren, thecheater887
priority: normal
severity: normal
status: open
title: Segmentation Fault: 11
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file42006/Python_2016-02-22-110201_Shuros-MacBook-Pro.crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26412>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:13:41 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Feb 2016 17:13:41 +0000
Subject: [issue26412] Segmentation Fault: 11
In-Reply-To: <1456160879.85.0.401353388041.issue26412@psf.upfronthosting.co.za>
Message-ID: <1456161221.6.0.893368199554.issue26412@psf.upfronthosting.co.za>


Christian Heimes added the comment:

pysodium is not part of Python's standard library. Please report 3rd party bugs in the project's bug tracker.

----------
nosy: +christian.heimes
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26412>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:41:02 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Feb 2016 17:41:02 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
In-Reply-To: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>
Message-ID: <1456162862.68.0.141762781887.issue26281@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Sorry, this has not been decided upon yet. Since it's a change in semantics either I just need to make a decision or convince someone else to provide an opinion as to whether this change makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26281>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:42:35 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 22 Feb 2016 17:42:35 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1456162955.44.0.767184952201.issue25910@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:43:38 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 22 Feb 2016 17:43:38 +0000
Subject: [issue26411] Suggestion concerning compile-time warnings
In-Reply-To: <1456154579.82.0.723903517664.issue26411@psf.upfronthosting.co.za>
Message-ID: <1456163018.56.0.666016811971.issue26411@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26411>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:44:01 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 22 Feb 2016 17:44:01 +0000
Subject: [issue26405] tkinter askopenfilename doubleclick issue on windows
In-Reply-To: <1456088833.09.0.473464639317.issue26405@psf.upfronthosting.co.za>
Message-ID: <1456163041.6.0.998827730058.issue26405@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components: +Windows
nosy: +gpolo, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26405>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:45:10 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 22 Feb 2016 17:45:10 +0000
Subject: [issue25801] ResourceWarning in test_zipfile64
In-Reply-To: <1449268595.5.0.95531754857.issue25801@psf.upfronthosting.co.za>
Message-ID: <1456163110.41.0.102312049173.issue25801@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25801>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:50:59 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Feb 2016 17:50:59 +0000
Subject: [issue26411] Suggestion concerning compile-time warnings
In-Reply-To: <1456154579.82.0.723903517664.issue26411@psf.upfronthosting.co.za>
Message-ID: <1456163459.21.0.809113930603.issue26411@psf.upfronthosting.co.za>


Brett Cannon added the comment:

We happily accept patches that silence compile-time warnings. Unfortunately most of the ones I come across are cross-platform ones like some discrepancy between OS X and Linux on the size of some POSIX header, so they are low priority and annoying to fix in a way that doesn't affect other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26411>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:51:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Feb 2016 17:51:41 +0000
Subject: [issue26411] Suggestion concerning compile-time warnings
In-Reply-To: <1456154579.82.0.723903517664.issue26411@psf.upfronthosting.co.za>
Message-ID: <1456163501.1.0.814211515565.issue26411@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26411>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:53:10 2016
From: report at bugs.python.org (Andrei Dorian Duma)
Date: Mon, 22 Feb 2016 17:53:10 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456163590.89.0.391800758522.issue19475@psf.upfronthosting.co.za>


Changes by Andrei Dorian Duma <andrei.duma.dorian at gmail.com>:


----------
nosy:  -andrei.duma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:53:27 2016
From: report at bugs.python.org (Andrei Dorian Duma)
Date: Mon, 22 Feb 2016 17:53:27 +0000
Subject: [issue15216] Support setting the encoding on a text stream after
 creation
In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za>
Message-ID: <1456163607.65.0.165066578551.issue15216@psf.upfronthosting.co.za>


Changes by Andrei Dorian Duma <andrei.duma.dorian at gmail.com>:


----------
nosy:  -andrei.duma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15216>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:57:24 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Feb 2016 17:57:24 +0000
Subject: [issue25136] Python doesn't find Xcode 7 stub libraries
In-Reply-To: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za>
Message-ID: <1456163844.97.0.0595572355145.issue25136@psf.upfronthosting.co.za>


Brett Cannon added the comment:

We should update the devguide to specify that the command-line tools need to be installed and either explain or point to documentation on how to install the tools.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25136>
_______________________________________

From report at bugs.python.org  Mon Feb 22 13:15:41 2016
From: report at bugs.python.org (Alessandro Cucci)
Date: Mon, 22 Feb 2016 18:15:41 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456164941.94.0.409000011121.issue19475@psf.upfronthosting.co.za>


Alessandro Cucci added the comment:

New patch after @martin.panter comments on Rietveld. I left only this:

- ``'milliseconds'``: Append the hours, minutes, seconds and milliseconds.

> vadmium 2016/02/21 23:30:20
> I think this should explain that fractions are truncated to zero, never 
> rounded
> up. At least for fractions of milliseconds, although this could apply 
> to the
> other options as well.

I think is quite obvious that a datetime.now() can't be rounded to the future if microseconds are 999500.

----------
Added file: http://bugs.python.org/file42007/issue19475_v15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Mon Feb 22 13:38:50 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Mon, 22 Feb 2016 18:38:50 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456166330.74.0.455870192943.issue26404@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Only closing the server :).
1. Did the changes requested in the CR.
2. Changed the example's in xmlrpc.server, http.server to use context manager.
3. Changed the xmlrpc.server, http.server server implementation when running python -m {xmlrpc.server, http.server} to use context manager.

----------
Added file: http://bugs.python.org/file42008/socketserver_context_manager2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Mon Feb 22 15:30:03 2016
From: report at bugs.python.org (Sam Yeager)
Date: Mon, 22 Feb 2016 20:30:03 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1456173003.51.0.573122507443.issue26376@psf.upfronthosting.co.za>


Sam Yeager added the comment:

Ran script on Terminal. The issue disappears, and everything works normally.

Running through IDLE, the issue returns. Sorry, Terry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Mon Feb 22 15:33:50 2016
From: report at bugs.python.org (Sam Yeager)
Date: Mon, 22 Feb 2016 20:33:50 +0000
Subject: [issue26377] Tkinter dialogs will not close if root window not packed.
In-Reply-To: <1455721620.42.0.0590186130956.issue26377@psf.upfronthosting.co.za>
Message-ID: <1456173230.21.0.918745733215.issue26377@psf.upfronthosting.co.za>


Sam Yeager added the comment:

Updated script with the adding 'parent-Rootwin' to messagebox() arguments. The issue persists.

Following advice in #26376:
Ran script on Terminal. The issue disappears, and everything works normally.
Running through IDLE, the issue returns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26377>
_______________________________________

From report at bugs.python.org  Mon Feb 22 15:43:01 2016
From: report at bugs.python.org (desbma)
Date: Mon, 22 Feb 2016 20:43:01 +0000
Subject: [issue1767511] SocketServer.DatagramRequestHandler with empty response
Message-ID: <1456173781.14.0.544090249268.issue1767511@psf.upfronthosting.co.za>


Changes by desbma <dutch109 at gmail.com>:


----------
nosy: +desbma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767511>
_______________________________________

From report at bugs.python.org  Mon Feb 22 15:54:21 2016
From: report at bugs.python.org (desbma)
Date: Mon, 22 Feb 2016 20:54:21 +0000
Subject: [issue26403] Don't call sendto in socketserver.DatagramRequestHandler
 if there is nothing to send
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456174461.44.0.834581068366.issue26403@psf.upfronthosting.co.za>


desbma added the comment:

OK, so first part of this issue (sendto called even if no data has been written) is indeed a duplicate of https://bugs.python.org/issue1767511 sorry for that.

For the second part of the issue (the exception not silenced), I have attached a new patch.

----------
Added file: http://bugs.python.org/file42009/issue26403_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Mon Feb 22 15:55:30 2016
From: report at bugs.python.org (desbma)
Date: Mon, 22 Feb 2016 20:55:30 +0000
Subject: [issue26403] Catch FileNotFoundError in
 socketserver.DatagramRequestHandler
In-Reply-To: <1456082925.77.0.767922099224.issue26403@psf.upfronthosting.co.za>
Message-ID: <1456174530.93.0.00841568107282.issue26403@psf.upfronthosting.co.za>


Changes by desbma <dutch109 at gmail.com>:


----------
title: Don't call sendto in socketserver.DatagramRequestHandler if there is nothing to send -> Catch FileNotFoundError in socketserver.DatagramRequestHandler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26403>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:00:20 2016
From: report at bugs.python.org (Mike)
Date: Mon, 22 Feb 2016 22:00:20 +0000
Subject: [issue26413] python 3.5.1 uses wrong registry in system-wide
 installation
Message-ID: <1456178420.73.0.449144850072.issue26413@psf.upfronthosting.co.za>


New submission from Mike:

The installer for python 3.5.1 (observed with the x64-86 executable installer, assumed to happen with all installers) allows users to install python either just for themselves or do a system-wide installation (provided they have sufficient privileges).

However, when selecting a system-wide installation, the uninstall information is registered to a key under HKEY_CURRENT_USER.

The result of this is that any user can run python 3.5.1; however, the entry in the "uninstall programs" list shows only for the original user that installed it.

This is in contrast to previous versions of python (e.g. 3.4.4) where any user could uninstall it (provided they have sufficient privileges). It is also in contrast to pylauncher of the same version (i.e. 3.5.1) which properly registers itself under HKEY_LOCAL_MACHINE when selected to be installed for all users.

The key in question is at this path:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{b8440650-9dbe-4b7d-8167-6e0e3dcdf5d0}

I believe it should be here:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{b8440650-9dbe-4b7d-8167-6e0e3dcdf5d0}

----------
components: Installation
messages: 260700
nosy: mray
priority: normal
severity: normal
status: open
title: python 3.5.1 uses wrong registry in system-wide installation
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26413>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:02:04 2016
From: report at bugs.python.org (Mike Kaplinskiy)
Date: Mon, 22 Feb 2016 22:02:04 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1456178524.04.0.218168281743.issue26388@psf.upfronthosting.co.za>


Mike Kaplinskiy added the comment:

Looks like by signed CLA just made it through, so that should be settled.

For the other bugs, it seems that overloading run_module & run_path seems to be getting a bit cumbersome, so it might make sense to have some sort of Runner object that has things like `Runner(module=..., code=..., path=...)` and then has properties like `argv = ...`, `module_dict = ...` and maybe attributes for the loader and the filepath. "Advanced" usage can use that over the vanilla run_module & run_path.

Either way, I think that's outside the scope of this change. Unfortunately this is already shaving a yak for me (https://github.com/facebook/buck/pull/651#issuecomment-185030156) and I'd rather not go deeper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:08:10 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Feb 2016 22:08:10 +0000
Subject: [issue26413] python 3.5.1 uses wrong registry in system-wide
 installation
In-Reply-To: <1456178420.73.0.449144850072.issue26413@psf.upfronthosting.co.za>
Message-ID: <1456178890.06.0.27863336801.issue26413@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Windows AllUsers installation places uninstaller in user profile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26413>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:16:11 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 22 Feb 2016 22:16:11 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ0gb3ZlciA=?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1456179371.42.0.264638558569.issue26366@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

If no one is planning to propose specific new markup for more fine-grained version annotations, this issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:50:17 2016
From: report at bugs.python.org (John Beck)
Date: Mon, 22 Feb 2016 22:50:17 +0000
Subject: [issue26414] os.defpath too permissive
Message-ID: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za>


New submission from John Beck:

A bug has been filed against Solaris' internal version of Python, which is
largely the same (including in this case) as the base version we get from
python.org.  The bug is that os.defpath starts with ':' and thus any Python
script run with a null PATH environment variable will use the current
working directory as its first entry.  This is generally considered to
be bad practice, and especially dangerous for anyone running with root
privileges on a Unix box.  So we intend to change Solaris' version of
Python to elide this, i.e., to apply the attached patch to our 2.7 version
and comparable patches to our 3.4 and 3.5 versions

As a precaution, I queried the security list before filing this bug, asking:

* Is this intentional?  (Seems like it but I couldn't find any documentation
  to confirm.)
* If so, why?  (Feel free to point me to any docs I missed.)
* If it is intentional, and we were to change our version anyway, do you know
  of any gotchas we should look out for?  There were no regressions when I
  ran the Python test suite.

and got the following reply:

---
From: Guido van Rossum <guido at python.org>
Date: Sat, 20 Feb 2016 09:29:11 -0800
Subject: Re: [PSRT] os.defpath too permissive

Wow. That looks like something really old. I think you can just file
an issue with a patch for this at bugs.python.org. I agree that it
should be fixed. I don't think there are many users that would be
vulnerable, nor do I think that much code would break; the only use in
the stdlib has os.environ.get("PATH", os.defpath) so in all practical
cases it would get the user's $PATH variable (which is presumably
safe) anyway.
---

So I am now filing this bug as suggested.

----------
components: Library (Lib)
files: 2.7-defpath.patch
keywords: patch
messages: 260703
nosy: jbeck
priority: normal
severity: normal
status: open
title: os.defpath too permissive
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42010/2.7-defpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26414>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:55:47 2016
From: report at bugs.python.org (Danek Duvall)
Date: Mon, 22 Feb 2016 22:55:47 +0000
Subject: [issue26414] os.defpath too permissive
In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za>
Message-ID: <1456181747.44.0.224343794479.issue26414@psf.upfronthosting.co.za>


Changes by Danek Duvall <duvall at comfychair.org>:


----------
nosy: +dhduvall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26414>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:57:47 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Feb 2016 22:57:47 +0000
Subject: [issue26414] os.defpath too permissive
In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za>
Message-ID: <1456181867.82.0.963493334854.issue26414@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26414>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:06:20 2016
From: report at bugs.python.org (A. Skrobov)
Date: Mon, 22 Feb 2016 23:06:20 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
Message-ID: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>


New submission from A. Skrobov:

I have a one-line module that assigns a tuple->int dictionary:

holo_table = {(0, 0, 0, 0, 0, 0, 1, 41, 61, 66, 89): 9, (0, 0, 0, 70, 88, 98, 103, 131, 147, 119, 93): 4, [35MB skipped], (932, 643, 499, 286, 326, 338, 279, 200, 280, 262, 115): 5}

When I try to import this module, Python grinds 100% of my CPU for like half an hour, then ultimately crashes with a MemoryError.

How much memory does it need to parse 35MB of data, of a rather simple structure?

Attaching the module, zipped to 10MB.

----------
components: Interpreter Core
files: crash.zip
messages: 260704
nosy: A. Skrobov
priority: normal
severity: normal
status: open
title: Out of memory, trying to parse a 35MB dict
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file42011/crash.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:06:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Feb 2016 23:06:45 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
Message-ID: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>


New submission from Brett Cannon:

In the thread at https://mail.python.org/pipermail/speed/2016-February/000272.html it came up that the regex_v8, telco, and spectral_norm benchmarks are all very inconsistent. That means they should be deprecated.

----------
components: Benchmarks
messages: 260705
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate the regex_v8, telco, and spectral_norm benchmarks
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:12:38 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Feb 2016 23:12:38 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456182758.3.0.453704020034.issue26416@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:02:13 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 23 Feb 2016 00:02:13 +0000
Subject: [issue26335] Make mmap.write return the number of bytes written like
 other write methods
In-Reply-To: <1455144937.95.0.515520937166.issue26335@psf.upfronthosting.co.za>
Message-ID: <1456185733.49.0.521510255875.issue26335@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Jakub. I don't use mmap module much so I don't have an opinion about the feature, but it sounds reasonable.

I left some review comments on Rietveld: http://bugs.python.org/review/26335/

----------
components: +Extension Modules -IO, Library (Lib)
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26335>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:49:25 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Feb 2016 01:49:25 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ0gb3ZlciA=?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1456192165.41.0.931204587166.issue26366@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Fred, thanks for chiming in.  Let's do close this one.

----------
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:50:29 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Feb 2016 01:50:29 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1456192229.67.0.128899251882.issue26323@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:32:57 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 23 Feb 2016 04:32:57 +0000
Subject: =?utf-8?b?W2lzc3VlMjYzNjZdIFVzZSDigJwuLiB2ZXJzaW9uYWRkZWTigJ0gb3ZlciA=?=
 =?utf-8?b?4oCcLi4gdmVyc2lvbmNoYW5nZWTigJ0gd2hlcmUgYXBwcm9wcmlhdGU=?=
In-Reply-To: <1455551359.29.0.702516130467.issue26366@psf.upfronthosting.co.za>
Message-ID: <1456201977.04.0.943145615865.issue26366@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

For anyone following along only via the tracker, it's worth noting that proposals for new markup are welcome on the docs mailing list.  More information is available at:

    https://mail.python.org/mailman/listinfo/docs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26366>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:49:12 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Feb 2016 04:49:12 +0000
Subject: [issue26417] Default IDLE 2.7.11 configuration files are out-of-sync
 on OS X framework installs
Message-ID: <1456202952.38.0.718952125759.issue26417@psf.upfronthosting.co.za>


New submission from Ned Deily:

On OS X framework installs, the Mac-specific sub-makefiles do some important tailoring of IDLE/s config-extensions.def and config-main.def files, among other things changing Tk some Tk events for more appropriate keyboard bindings (e.g. "<Alt-" to "<Opt-".  On Python 2, this tailoring is performed by Mac/IDLE/Makefile.in replacing the standard Lib/idlelib/config-extensions.def and Lib/idlelib/config-main.def files with pre-edited versions from Mac/IDLE (Mac/IDLE/config-extensions.def and Mac/IDLE/config-main.def).  Unfortunately, over the years, the Mac-specific files have not been kept in sync with the standard ones.  For Python 2.7.11, this results in the problem described in Issue25313 still being present for OS X framework installs, such as provided by the python.org OS X installers and other third-party distributors.  (The symptoms are warning messages during IDLE startup of the form:

 Warning: configHandler.py - IdleConf.GetOption -
 problem retrieving configuration option 'name2'
 from section 'Theme'.
 returning default value: ''
)

For Python 3, the Mac Makefile installation of IDLE was substantially revised including eliminating the Mac-specific copies of the two .def files.  Instead, the Python 3 Makefile edits the default idlelib .def files during installation so that this kind of sync problem doesn't occur.  Ideally, the 2.7 Mac/IDLE/Makefile.in should be changed to do what Python 3 does and the redundant .def files removed.  At a minimum the 2.7 Mac files should be synced.  Patch to follow.

----------
assignee: ned.deily
components: Build, IDLE, Macintosh
messages: 260709
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Default IDLE 2.7.11 configuration files are out-of-sync on OS X framework installs
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26417>
_______________________________________

From report at bugs.python.org  Tue Feb 23 03:19:46 2016
From: report at bugs.python.org (rapolas)
Date: Tue, 23 Feb 2016 08:19:46 +0000
Subject: [issue26405] tkinter askopenfilename doubleclick issue on windows
In-Reply-To: <1456088833.09.0.473464639317.issue26405@psf.upfronthosting.co.za>
Message-ID: <1456215586.14.0.455425470157.issue26405@psf.upfronthosting.co.za>


rapolas added the comment:

Just tried this on Python 2.7.11 and the issue is not present.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26405>
_______________________________________

From report at bugs.python.org  Tue Feb 23 03:21:20 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Feb 2016 08:21:20 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456215680.1.0.751943466905.issue26416@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 03:27:16 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Feb 2016 08:27:16 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456216036.61.0.701229798532.issue26416@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm not sure what "inconsistent" means. If the results are unstable between runs, it may mean the operations being measured themselves are unstable (for example because of hashing differences or cache aliasing effects from run to run).

I'd rather like benchmarks to be judged on their usefulness:
- spectral_norm really looks pointless as nobody would write scientific code in Python like that
- telco, AFAIU, is a widely-used benchmark for decimals (but perhaps Stefan can shed some light)
- regex_v8 claims to be drawn from real-world use of regular expressions by popular Web pages, so it sounds useful as well

(note that telco apparently loads a file in the main loop, perhaps that can be pulled out of the loop and into the init phase)

----------
nosy: +haypo, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:07:38 2016
From: report at bugs.python.org (=?utf-8?q?Ilja_Everil=C3=A4?=)
Date: Tue, 23 Feb 2016 09:07:38 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
In-Reply-To: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>
Message-ID: <1456218458.37.0.00563825944082.issue26407@psf.upfronthosting.co.za>


Ilja Everil? added the comment:

After doing some reading on https://docs.python.org/dev/c-api/exceptions.html it seems that this is possibly "as designed" or such, since csv_writerows explicitly calls PyErr_SetString on receiving NULL from PyObject_GetIter.

Still, it feels like this could either let the original exception fall through (since it has nothing in the way of handling it) or form the chain in PY3 for easier debugging of the real cause.

To give this thing some context we ran in to this while passing SQLAlchemy Query objects to csv_writerows. The Query object is compiled during call to __iter__ and the current behaviour masks possible SQL errors etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:43:40 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Feb 2016 09:43:40 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456220620.2.0.0976619633004.issue26416@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Telco is a real world workload devised by Mike Cowlishaw. Some fixes
need to me made for the version in the benchmark suite; in particular,
the amount of input seems insufficient for _decimal (#26284).

I'm not a fan of weeding out real world benchmarks until our test suite
looks stable -- does Intel for example apply the techniques described
by Victor in another issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:46:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Feb 2016 09:46:56 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456220816.84.0.23886734488.issue26416@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I opened the issue #26275 to try to make benchmarks more reliable.

My notes to tune the Linux kernel to reduce the "noise" from the operating system:
http://haypo-notes.readthedocs.org/microbenchmark.html#reliable-micro-benchmarks

On the speed mailing list, it was also suggested to use the geometric mean rather than the minimum or the average.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:47:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Feb 2016 09:47:13 +0000
Subject: [issue26417] Default IDLE 2.7.11 configuration files are out-of-sync
 on OS X framework installs
In-Reply-To: <1456202952.38.0.718952125759.issue26417@psf.upfronthosting.co.za>
Message-ID: <20160223094704.1703.76597@psf.io>


Roundup Robot added the comment:

New changeset 13826ff147e4 by Ned Deily in branch '2.7':
Issue #26417: Prevent spurious errors and incorrect defaults when
https://hg.python.org/cpython/rev/13826ff147e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26417>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:47:20 2016
From: report at bugs.python.org (renlifeng)
Date: Tue, 23 Feb 2016 09:47:20 +0000
Subject: [issue26418] multiprocessing.pool.ThreadPool eats up memories
Message-ID: <1456220840.03.0.74121216833.issue26418@psf.upfronthosting.co.za>


New submission from renlifeng:

If func creates lots objects and appends them to a list, and runs over and over, pool.map(func...) will eventually eat up all memories. Cleaning the list at the end of func does not help.

One can reproduce by running the attached file.

By contrast, after replacing ThreadPool with the theading module (see the commented out lines), memory usage will not grow continuously.

By the way, I used what's in Debian stretch, i.e. python 2.7.11 and 3.5.1.

----------
components: Library (Lib)
files: cvtest5.py
messages: 260716
nosy: renlifeng
priority: normal
severity: normal
status: open
title: multiprocessing.pool.ThreadPool eats up memories
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42012/cvtest5.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26418>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:50:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 23 Feb 2016 09:50:38 +0000
Subject: [issue26414] os.defpath too permissive
In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za>
Message-ID: <1456221038.43.0.231620068862.issue26414@psf.upfronthosting.co.za>


Martin Panter added the comment:

Digging through the history, it has been this way since at least revision d5b67d2ec7ee (1994).

Removing the colon is definitely a good idea. Maybe this might be a more proper way to get the default PATH:

>>> os.confstr("CS_PATH")
'/bin:/usr/bin'

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26414>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:57:27 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Feb 2016 09:57:27 +0000
Subject: [issue26417] Default IDLE 2.7.11 configuration files are out-of-sync
 on OS X framework installs
In-Reply-To: <1456202952.38.0.718952125759.issue26417@psf.upfronthosting.co.za>
Message-ID: <1456221447.77.0.693951694323.issue26417@psf.upfronthosting.co.za>


Ned Deily added the comment:

For 2.7.12 I've committed changes to the Mac/IDLE Makefile so that it now edits the defaults files in place on install just like the 3.x Makefiles do.  Framework installs of IDLE 2.7 on OS X no longer output startup warnings and, since the defaults are now in sync, also now properly use the newer default font.  The whole approach is less than ideal since the OS X tailoring is still hidden away in the Mac Makefiles rather than in idlelib code.  Issue20580 addresses the broader issue of platform-specific configuration files for IDLE.

----------
nosy: +terry.reedy -ronaldoussoren
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26417>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:58:09 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Feb 2016 09:58:09 +0000
Subject: [issue26275] perf.py: calibrate benchmarks using time,
 not using a fixed number of iterations
In-Reply-To: <1454495929.85.0.601853644385.issue26275@psf.upfronthosting.co.za>
Message-ID: <1456221489.77.0.557921880065.issue26275@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
dependencies: +Fix telco benchmark

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26275>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:01:52 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Feb 2016 10:01:52 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456221712.4.0.877324942188.issue26416@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> On the speed mailing list, it was also suggested to use the geometric mean rather than the minimum or the average.

This should be considered a bit more carefully.

First, geometric mean is only useful when you are agregating heterogenous numbers. Here, we are agregating homogenous numbers (results from a single benchmark), so the arithmetic mean should be preferred.

Second, there still is the issue of weeding out outliars (due to e.g. background activity). So perhaps the 20% slowest runs should be discarded.

Third, to get enough precision in the arithmetic mean, the number of individual runs (separate process invocations, to smoothen variabilities due to cache aliasing etc.) should be raised to a sufficient number. See the central limit theorem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:03:51 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Feb 2016 10:03:51 +0000
Subject: [issue20580] IDLE should support platform-specific default config
 defaults
In-Reply-To: <1392027551.21.0.533992391985.issue20580@psf.upfronthosting.co.za>
Message-ID: <1456221831.69.0.454429675879.issue20580@psf.upfronthosting.co.za>


Ned Deily added the comment:

See Issue26417 for further discussion about the OS X specific tailoring of IDLE config files and changes to the 2.7 Makefiles to better match the 3.x Makefiles to reduce the risk of inadvertent platform differences.

----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20580>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:05:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Feb 2016 10:05:51 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1456221951.51.0.450709111059.issue26376@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I was running from IDLE when I said no problem on Windows, so this is OSX specific.  Are you running same version of python  (splash message) and tcl/tk?  (on IDLE, Help => About IDLE).  Does Python on OSX have equivalent of pythonw.exe?  If you start IDLE at terminal and then run from IDLE, do you see and error message in the terminal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:06:16 2016
From: report at bugs.python.org (Michael Foord)
Date: Tue, 23 Feb 2016 10:06:16 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1456221976.18.0.327688558625.issue26323@psf.upfronthosting.co.za>


Michael Foord added the comment:

There have been persistent calls for an "assert_called" method over the lifetime of mock. In the past I've rejected them because you can easily get it by asserting the call count is non-zero and I want to avoid the proliferation of a thousand assert methods. The demand is certainly consistent, so it would seem that people feel there is a use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:10:01 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Feb 2016 10:10:01 +0000
Subject: [issue26409] Support latest Tcl/Tk on future versions of Mac installer
In-Reply-To: <1456148186.12.0.689143317593.issue26409@psf.upfronthosting.co.za>
Message-ID: <1456222201.6.0.558870287073.issue26409@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the suggestion.  Moving the OS X installers to using Tcl/Tk 8.6 is the subject of Issue15663.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Investigate providing Tcl/Tk 8.6 with OS X installers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26409>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:15:19 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Tue, 23 Feb 2016 10:15:19 +0000
Subject: [issue26375] Python 2.7.10 and 3.4.4 hang on imaplib.IMAP4_SSL()
In-Reply-To: <1455716357.67.0.858374272161.issue26375@psf.upfronthosting.co.za>
Message-ID: <1456222519.51.0.926527986911.issue26375@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26375>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:21:40 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Tue, 23 Feb 2016 10:21:40 +0000
Subject: [issue26399] CSV Injection Vulnerability
In-Reply-To: <1456052056.17.0.370587788847.issue26399@psf.upfronthosting.co.za>
Message-ID: <1456222900.0.0.17898976658.issue26399@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

Closing in favor of http://psf.upfronthosting.co.za/roundup/meta/issue580

----------
nosy: +maciej.szulik
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26399>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:33:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 23 Feb 2016 10:33:09 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456223589.29.0.552668579404.issue19475@psf.upfronthosting.co.za>


Martin Panter added the comment:

About rounding: I?m not too sure what people would expect. Obviously it is much easier to implement truncating to zero. But it is different to many other rounding cases in Python; that is why I thought to make it explicit.

>>> datetime.fromtimestamp(59.9999999).isoformat(timespec="microseconds")
'1970-01-01T00:01:00.000000'
>>> datetime.fromtimestamp(59.999999).isoformat(timespec="milliseconds")
'1970-01-01T00:00:59.999'
>>> format(59.999999, ".3f")
'60.000'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Tue Feb 23 06:10:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Feb 2016 11:10:55 +0000
Subject: [issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
In-Reply-To: <1456111993.44.0.164668159059.issue26406@psf.upfronthosting.co.za>
Message-ID: <20160223111051.1549.25067@psf.io>


Roundup Robot added the comment:

New changeset 52a8c1965750 by Ned Deily in branch '2.7':
Issue #26406: Avoid unnecessary serialization of getaddrinfo(3) calls on
https://hg.python.org/cpython/rev/52a8c1965750

New changeset 419d20551d26 by Ned Deily in branch '3.5':
Issue #26406: Avoid unnecessary serialization of getaddrinfo(3) calls on
https://hg.python.org/cpython/rev/419d20551d26

New changeset 5ffebeb3e91d by Ned Deily in branch 'default':
Issue #26406: merge from 3.5
https://hg.python.org/cpython/rev/5ffebeb3e91d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26406>
_______________________________________

From report at bugs.python.org  Tue Feb 23 06:15:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Feb 2016 11:15:30 +0000
Subject: [issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
In-Reply-To: <1456111993.44.0.164668159059.issue26406@psf.upfronthosting.co.za>
Message-ID: <1456226130.9.0.930945928428.issue26406@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the additional patch, Jesse. Since we don't have a NetBSD buildbot and I don't have any NetBSD or OpenBSD systems at hand to do any testing, I'll take your word for the version checks.  If anyone runs into any problems because of these changes, feel free to re-open this issue.  Pushed for release in 2.7.12, 3.5.2, and 3.6.0.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26406>
_______________________________________

From report at bugs.python.org  Tue Feb 23 06:24:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Feb 2016 11:24:50 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1456221976.18.0.327688558625.issue26323@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa0c1cOOhqknoc9fZQ6KXr2Uwd4x4XpSOEmDJB04qMVRA@mail.gmail.com>


STINNER Victor added the comment:

> In the past I've rejected them because you can easily get it by asserting the call count is non-zero and I want to avoid the proliferation of a thousand assert methods

Yeah, I understand that.

IMHO having to check if a function was called is a common need. Mock
has already assert_not_called() for example.

I like the detection of spelling typos for methods starting with assert_ :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Tue Feb 23 08:06:53 2016
From: report at bugs.python.org (Dhiraj)
Date: Tue, 23 Feb 2016 13:06:53 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456232813.61.0.618916582492.issue26398@psf.upfronthosting.co.za>


Dhiraj added the comment:

Even the IDLE of Python is Vulnerable to CGI.ESCAPE() Please have a look on attachments , I hope this would be Patch Soon.

Thank You

----------
nosy: +dstufft, gregory.p.smith
type:  -> security
Added file: http://bugs.python.org/file42013/Python-IDLE-CGI-Vulnerable.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Tue Feb 23 08:27:11 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 23 Feb 2016 13:27:11 +0000
Subject: [issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
In-Reply-To: <1456111993.44.0.164668159059.issue26406@psf.upfronthosting.co.za>
Message-ID: <1456234031.02.0.732363199573.issue26406@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26406>
_______________________________________

From report at bugs.python.org  Tue Feb 23 08:27:52 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 23 Feb 2016 13:27:52 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1456234072.28.0.436775249731.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Related to #26406, a fix for NetBSD and OpenBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25924>
_______________________________________

From report at bugs.python.org  Tue Feb 23 08:56:56 2016
From: report at bugs.python.org (Sergei Lebedev)
Date: Tue, 23 Feb 2016 13:56:56 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1456235816.67.0.468801536204.issue8844@psf.upfronthosting.co.za>


Sergei Lebedev added the comment:

Is it possible to backport this patch to 2.7?

----------
nosy: +superbobry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Tue Feb 23 09:01:05 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 23 Feb 2016 14:01:05 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1456236065.55.0.0246428565131.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Ping! ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Tue Feb 23 09:16:32 2016
From: report at bugs.python.org (Dhiraj)
Date: Tue, 23 Feb 2016 14:16:32 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1456236992.35.0.488501568732.issue26039@psf.upfronthosting.co.za>


Dhiraj added the comment:

Please ha Look on issue 11980

http://bugs.python.org/issue11980
Already have been Patched

----------
nosy: +DhirajMishra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Tue Feb 23 09:24:34 2016
From: report at bugs.python.org (Tatsunori Uchino)
Date: Tue, 23 Feb 2016 14:24:34 +0000
Subject: [issue26420] IDEL for Python 3.5.1 for x64 Windows exits when pasted
 a string with non-BMP characters
Message-ID: <1456237474.93.0.941468320226.issue26420@psf.upfronthosting.co.za>


New submission from Tatsunori Uchino:

On Windows Server 2012 R2 with Update(which is compatible with Windows 8.1 Update 1), I copied a character U+20BB7 and pasted it on IDLE.  After that, IDLE suddenly exited with no messages, notices, or errors.

  Then, I tried to input some non-BMP charactors by the Google Japanese IME other than ? such as U+1F444, U+1F468 and found that the IDLE exited as the same way.

  I suppose that these phenomena could be due to a failure when treating surrogate pairs in input or pasted strings.

----------
components: IDLE
messages: 260736
nosy: Tats.U.
priority: normal
severity: normal
status: open
title: IDEL for Python 3.5.1 for x64 Windows exits when pasted a string with non-BMP characters
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26420>
_______________________________________

From report at bugs.python.org  Tue Feb 23 09:32:00 2016
From: report at bugs.python.org (Tatsunori Uchino)
Date: Tue, 23 Feb 2016 14:32:00 +0000
Subject: [issue26420] IDEL for Python 3.5.1 for x64 Windows exits when pasted
 a string with non-BMP characters
In-Reply-To: <1456237474.93.0.941468320226.issue26420@psf.upfronthosting.co.za>
Message-ID: <1456237920.28.0.235945396373.issue26420@psf.upfronthosting.co.za>


Tatsunori Uchino added the comment:

P.S.
  ? is explained as U+20BB7 in UCS-4.  And the characters that is explaind as U+1F444(?) and U+1F468(?) are both what are said emojis(explains the mouth and man)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26420>
_______________________________________

From report at bugs.python.org  Tue Feb 23 09:49:58 2016
From: report at bugs.python.org (yuriy_levchenko)
Date: Tue, 23 Feb 2016 14:49:58 +0000
Subject: [issue26421] string_richcompare invalid check Py_NotImplemented
Message-ID: <1456238998.85.0.782373518975.issue26421@psf.upfronthosting.co.za>


New submission from yuriy_levchenko:

i have object with flag Py_TPFLAGS_STRING_SUBCLASS

stringobject.c (line 1192) in function string_richcompare

we have check string PyString_Check

but,

#define PyString_Check(op) \
                 PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_STRING_SUBCLASS)

i successful check this. But my type is not PyStringObject

Maybe need replace this check on PyString_CheckExact?

----------
messages: 260738
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: string_richcompare invalid check Py_NotImplemented
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26421>
_______________________________________

From report at bugs.python.org  Tue Feb 23 10:25:09 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Feb 2016 15:25:09 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456241109.82.0.749685964014.issue26416@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

We now have speed.python.org up, so I'd keep spectral_norm to make sure we don't accidentally harm the performance of int/floats operations.  It also helped me to discover that PyLong_AsDouble was unnecessary slow, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 12:41:45 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 23 Feb 2016 17:41:45 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456249305.4.0.543853713874.issue26398@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

As pointed out, this is working as intended and is documented as such.  That it isn't what you want is why Python 3 has html.escape() instead.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> cgi.escape Can Lead To XSS Vulnerabilities
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Tue Feb 23 12:45:03 2016
From: report at bugs.python.org (Dhiraj)
Date: Tue, 23 Feb 2016 17:45:03 +0000
Subject: [issue26398] cgi.escape() Can Lead To XSS and HTML Vulnerabilities
In-Reply-To: <1456047959.51.0.622191858918.issue26398@psf.upfronthosting.co.za>
Message-ID: <1456249503.33.0.000845737162394.issue26398@psf.upfronthosting.co.za>


Changes by Dhiraj <mishra.dhiraj95 at gmail.com>:


----------
resolution: duplicate -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26398>
_______________________________________

From report at bugs.python.org  Tue Feb 23 13:38:51 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Tue, 23 Feb 2016 18:38:51 +0000
Subject: [issue26392] socketserver.BaseServer.close_server should stop
 serve_forever
In-Reply-To: <1455901217.04.0.582313607927.issue26392@psf.upfronthosting.co.za>
Message-ID: <1456252731.04.0.873063951635.issue26392@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I understand the problem and why this patch should be rejected.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26392>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:22:19 2016
From: report at bugs.python.org (Anthony Foglia)
Date: Tue, 23 Feb 2016 19:22:19 +0000
Subject: [issue25136] Python doesn't find Xcode 7 stub libraries
In-Reply-To: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za>
Message-ID: <1456255339.5.0.325080684998.issue25136@psf.upfronthosting.co.za>


Changes by Anthony Foglia <afoglia at gmail.com>:


----------
nosy: +afoglia

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25136>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:55:39 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Feb 2016 19:55:39 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1456257339.05.0.30306052235.issue26360@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I've found OS X 10.10 and OS X 10.11 machines to test on. I'm able to reproduce on 10.10, but not on 10.11. This adds to the plausibility of the "Apple bug" explanation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:55:48 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Feb 2016 19:55:48 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9,
 10.10
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1456257348.29.0.773874826134.issue26360@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
title: Deadlock in thread.join on Python 2.7/Mac OS X 10.9 -> Deadlock in thread.join on Python 2.7/Mac OS X 10.9, 10.10

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Tue Feb 23 15:56:26 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Feb 2016 20:56:26 +0000
Subject: [issue26284] Fix telco benchmark
In-Reply-To: <1454596081.41.0.621997504219.issue26284@psf.upfronthosting.co.za>
Message-ID: <1456260986.29.0.239235679688.issue26284@psf.upfronthosting.co.za>


Brett Cannon added the comment:

If you think the string conversion should go back in, Stefan, feel free to put it back (unless Victor wants to say why he took it out).

----------
assignee:  -> skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26284>
_______________________________________

From report at bugs.python.org  Tue Feb 23 15:57:12 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Feb 2016 20:57:12 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456261032.42.0.463127784231.issue26416@psf.upfronthosting.co.za>


Brett Cannon added the comment:

OK, so everyone says to keep what we have.

----------
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 16:25:46 2016
From: report at bugs.python.org (John Taylor)
Date: Tue, 23 Feb 2016 21:25:46 +0000
Subject: [issue26422] printing 1e23 and up is incorrect
Message-ID: <1456262746.09.0.528501038499.issue26422@psf.upfronthosting.co.za>


New submission from John Taylor:

The print statement does not display accurate results.

code:
    print("%35d" % (1e21))
    print("%35d" % (1e22))
    print("%35d" % (1e23))
    print("%35d" % (1e24))
    print("%35d" % (1e25))
    print("%35d" % (1e26))
    print("%35d" % (1e27))
    print("%35d" % (1e28))
    print("%35d" % (1e29))
    print("%35d" % (1e30))
    print("%35d" % (1e31))

result:
             1000000000000000000000
            10000000000000000000000
            99999999999999991611392
           999999999999999983222784
         10000000000000000905969664
        100000000000000004764729344
       1000000000000000013287555072
       9999999999999999583119736832
      99999999999999991433150857216
    1000000000000000019884624838656
    9999999999999999635896294965248

Platforms:
Windows 10 x64, Python 3.5.1
Debian 8 (jessie), Python 3.5.1

----------
messages: 260745
nosy: jftuga
priority: normal
severity: normal
status: open
title: printing 1e23 and up is incorrect
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26422>
_______________________________________

From report at bugs.python.org  Tue Feb 23 16:36:52 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Feb 2016 21:36:52 +0000
Subject: [issue26416] Deprecate the regex_v8, telco,
 and spectral_norm benchmarks
In-Reply-To: <1456182405.89.0.810278260076.issue26416@psf.upfronthosting.co.za>
Message-ID: <1456263412.4.0.52949823665.issue26416@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution: postponed -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26416>
_______________________________________

From report at bugs.python.org  Tue Feb 23 16:52:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 23 Feb 2016 21:52:13 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1456264333.71.0.0484289568742.issue26039@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the pointer Dhiraj. I prefer the open(mode="w") version proposed here, as being more flexible. This way you could wrap the writer object in e.g. TextIOWrapper. The other patch requires passing in a file reader object.

Having another look at zipfile-open-w4.patch, I have some thoughts about locking and the writing-while-reading restriction:

The lock seems to be designed to serialize reads and writes (which operate on the common underlying file object). See revision 4973ccd46e32, and <https://bugs.python.org/issue14099#msg234142>, although it would be good to document this, or at the minimum add a comment explaining the purpose and scope of the lock.

Currently, it appears that write() and writestr() acquire the lock, so I presume it is intended that these methods can be called multiple times concurrently, and also while the zip file is being read. With the patch, writestr() still preserves the lock usage, but write() does not because it is now implemented in terms of the new open(mode="w") method.

I think it would be good to clarify that the lock does _not_ protect concurrent writes via open(mode="w").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Tue Feb 23 17:14:27 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 23 Feb 2016 22:14:27 +0000
Subject: [issue26422] printing 1e23 and up is incorrect
In-Reply-To: <1456262746.09.0.528501038499.issue26422@psf.upfronthosting.co.za>
Message-ID: <1456265667.68.0.237309352732.issue26422@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Please see https://docs.python.org/3.5/tutorial/floatingpoint.html for a discussion of why this is not a bug.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26422>
_______________________________________

From report at bugs.python.org  Tue Feb 23 17:23:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Feb 2016 22:23:24 +0000
Subject: [issue26284] Fix telco benchmark
In-Reply-To: <1454596081.41.0.621997504219.issue26284@psf.upfronthosting.co.za>
Message-ID: <1456266204.6.0.570786195977.issue26284@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Unfortunately, replacing io.BytesIO(data) with indexing does not make the benchmark faster or more stable on my machine.

Ah, I didn't check. I expected BytesIO.read() to be slower than bytes string slicing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26284>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:04:48 2016
From: report at bugs.python.org (Dave Hibbitts)
Date: Tue, 23 Feb 2016 23:04:48 +0000
Subject: [issue26423] __len__() returns 32 bit int on windows leading to
 overflows
Message-ID: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>


New submission from Dave Hibbitts:

__len__() always returns an int which on windows machines is tied to the size of a c long and is always 32 bits even if it's compiled for 64 bit. len() however returns an int for values less than sys.maxint and a long above that. 

Returning an int in __len__() causes it to return negative lengths for objects of size greater than sys.maxint, below you can see a quick test on how to reproduce it.

And here's an explanation from \u\Rhomboid on Reddit of why we believe the issue happens.

"You'll only see that on Windows. The issue is that, confusingly, the range of the Python int type is tied to the range of the C long type. On Windows long is always 32 bits even on x64 systems, whereas on Unix systems it's the native machine word size. You can confirm this by checking sys.maxint, which will be 2**31 - 1 even with a 64 bit interpreter on Windows.

The difference in behavior of foo.__len__ vs len(foo) is that the former goes through an attribute lookup which goes through the slot lookup stuff, finally ending in Python/typeobject.c:wrap_lenfunc(). The error is casting Py_ssize_t to long, which truncates on Windows x64 as Py_ssize_t is a proper signed 64 bit integer. And then it compounds the injury by creating a Python int object with PyInt_FromLong(), so this is hopelessly broken. In the case of len(foo), you end up in Python/bltinmodule.c:builtin_len() which skips all the attribute lookup stuff and uses the object protocol directly, calling PyObject_Size() and creating a Python object of the correct type via PyInt_FromSsize_t() which figures out whether a Python int or long is necessary.

This is definitely a bug that should be reported. In 3.x the int/long distinction is gone and all integers are Python longs, but the bogus cast to a C long still exists in wrap_lenfunc():

    return PyLong_FromLong((long)res);

That means the bug still exists even though the reason for its existence is gone! Oops. That needs to be updated to get rid of the cast and call PyLong_FromSsize_t()."

Python 2.7.8 |Anaconda 2.1.0 (64-bit)| (default, Jul  2 2014, 15:12:11) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://binstar.org
>>> a = 'a'*2500000000
>>> a.__len__()
-1794967296
>>> len(a)
2500000000L
>>> a = [1]*2500000000
>>> len(a)
2500000000L
>>> a.__len__()
-1794967296

----------
components: Windows
messages: 260749
nosy: Dave Hibbitts, georg.brandl, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: __len__() returns 32 bit int on windows leading to overflows
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:39:34 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Tue, 23 Feb 2016 23:39:34 +0000
Subject: [issue26335] Make mmap.write return the number of bytes written like
 other write methods
In-Reply-To: <1455144937.95.0.515520937166.issue26335@psf.upfronthosting.co.za>
Message-ID: <1456270774.15.0.709966957428.issue26335@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

Oops, sorry for the silliness in the C code, thanks for reviewing. I modified as suggested, please find the new patch attached.

----------
Added file: http://bugs.python.org/file42014/mmap_write_return_count2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26335>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:39:42 2016
From: report at bugs.python.org (Sam Yeager)
Date: Tue, 23 Feb 2016 23:39:42 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1456270782.34.0.116169733279.issue26376@psf.upfronthosting.co.za>


Sam Yeager added the comment:

It's almost certainly only found on OSX. I'm currently taking a Python class of approximately 150 students, and at least two of us independently found this issue on our respective Macs.

IDLE and Python are the same version (v3.4.4). The info window lists Tk as version 8.5.18, which matches the version ActiveTcl.

I'm not familiar with pythonw.exe as I've been using Mac.

Entering "idle 3.4" at Terminal opens IDLE as a separate app and Terminal waits until the app is closed. While running the script in the app, the issue persists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:46:07 2016
From: report at bugs.python.org (Eric Snow)
Date: Tue, 23 Feb 2016 23:46:07 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
In-Reply-To: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>
Message-ID: <1456271167.47.0.582238645819.issue26281@psf.upfronthosting.co.za>


Eric Snow added the comment:

(Note that PathFinder.invalidate_caches() loops over sys.path_importer_cache and invalidates the cache of each path entry finder therein.  What you're suggesting is clearing sys.path_importer_cache after the loop finishes.)

Hmm.  The distinction is between clearing the cache of each finder and clearing the caches in the import machinery, sort of.  sys.path_importer_cache effectively belongs to PathFinder, just like sys.path_hooks.  I expect they are part of sys only as a historical artifact (i.e. pre-importlib).  So I'd say there isn't any conceptual problem in that regard.

The point of importlib.invalidate_caches() is to allow finders to pick up out-of-band events.  In the case of sys.path_importer_cache, it would allow new entries in sys.path_hooks to have a shot and old entries to have another chance.  That seems reasonable.

The only caveat I see is that sys.path_importer_cache is not an "internal" cache (as the importlib.invalidate_caches() docs refer to them).  Furthermore, it has some established semantics attached:

  * a path hook will only be called once for a path entry (entries in the cache are fixed in place once added)
  * None is a sentinel for not-found

Consequently,someone may inject None into the cache to prevent finding a spec/loader. With this chance, calls to importlib.invalidate_caches() could cause them problems.  In this regard there may be a backward-compatibility issue.

Other than that, I consider clearing sys.path_importer_cache in PathFinder.invalidate_caches() to be a reasonable change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26281>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:59:15 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Feb 2016 23:59:15 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
In-Reply-To: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>
Message-ID: <1456271955.79.0.388585352148.issue26281@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Damn, good point about the backwards-compatibility issue. Then I think a doc note for importlib.invalidate_caches() saying that there is also sys.path_importer_cache would be good enough.

----------
assignee:  -> brett.cannon
components: +Documentation -Library (Lib)
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26281>
_______________________________________

From report at bugs.python.org  Tue Feb 23 19:00:23 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Feb 2016 00:00:23 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
In-Reply-To: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>
Message-ID: <1456272023.85.0.229072681387.issue26281@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Or another option is to add a keyword-only argument to importlib.invalidate_caches() to also clear the the cache of importers itself on top of the caches of the importers themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26281>
_______________________________________

From report at bugs.python.org  Tue Feb 23 20:19:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 01:19:15 +0000
Subject: [issue22088] base64 module still ignores non-alphabet characters
In-Reply-To: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za>
Message-ID: <20160224011907.1640.75414@psf.io>


Roundup Robot added the comment:

New changeset c62526580ff0 by Martin Panter in branch '2.7':
Issue #22088: Clarify base-64 alphabets and which characters are discarded
https://hg.python.org/cpython/rev/c62526580ff0

New changeset c8933fbc9171 by Martin Panter in branch '3.5':
Issue #22088: Clarify base-64 alphabets and which characters are discarded
https://hg.python.org/cpython/rev/c8933fbc9171

New changeset 5ad27dcd5a97 by Martin Panter in branch 'default':
Issue #22088: Merge base64 docs from 3.5
https://hg.python.org/cpython/rev/5ad27dcd5a97

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22088>
_______________________________________

From report at bugs.python.org  Tue Feb 23 20:51:26 2016
From: report at bugs.python.org (Eric Snow)
Date: Wed, 24 Feb 2016 01:51:26 +0000
Subject: [issue26281] Clear sys.path_importer_cache from
 importlib.invalidate_caches()
In-Reply-To: <1454533860.47.0.453601441471.issue26281@psf.upfronthosting.co.za>
Message-ID: <1456278686.29.0.653236426071.issue26281@psf.upfronthosting.co.za>


Eric Snow added the comment:

Re: the kw-only arg, it seems weird to accommodate the implementation of one meta-path finder in the signature of importlib.invalidate_caches().

Here's an alternative:

Use a different sys.path_importer_cache sentinel internally (in PathFinder) and never clear None when clearing the cache.

Here's another alternative:

Deprecate sys.path_importer_cache and move/alias it to an internal cache of PathFinder. *  Then add methods to PathFinder to cover the use cases that folks have for interacting with sys.path_importer_cache directly.  In this case it may also make sense to expose the active PathFinder instance as an importlib attribute, for easier access to this key finder.  Doing the same on ImportState will be part of my (eventual) proposal. :)

Of course, neither of those alternatives addresses the case where someone expects sys.path_importer_cache entries to remain fixed once in place.  However, that's a tenuous implicit guarantee already. :)


* The same could be done with sys.path_hooks...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26281>
_______________________________________

From report at bugs.python.org  Tue Feb 23 20:53:45 2016
From: report at bugs.python.org (Frazer McLean)
Date: Wed, 24 Feb 2016 01:53:45 +0000
Subject: [issue26423] __len__() returns 32 bit int on windows leading to
 overflows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456278825.52.0.393774172495.issue26423@psf.upfronthosting.co.za>


Changes by Frazer McLean <frazer at frazermclean.co.uk>:


----------
nosy: +RazerM

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Tue Feb 23 20:59:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Feb 2016 01:59:14 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456279154.45.0.22267977904.issue26404@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks, the patch looks pretty good to me. I left some comments about minor things. Also, someone will need to write a What?s New entry.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Tue Feb 23 20:59:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Feb 2016 01:59:58 +0000
Subject: [issue22088] base64 module still ignores non-alphabet characters
In-Reply-To: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za>
Message-ID: <1456279198.42.0.689922679463.issue22088@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22088>
_______________________________________

From report at bugs.python.org  Tue Feb 23 21:16:33 2016
From: report at bugs.python.org (Shawn)
Date: Wed, 24 Feb 2016 02:16:33 +0000
Subject: [issue26414] os.defpath too permissive
In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za>
Message-ID: <1456280193.78.0.800128138027.issue26414@psf.upfronthosting.co.za>


Changes by Shawn <binarycrusader at gmail.com>:


----------
nosy: +swalker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26414>
_______________________________________

From report at bugs.python.org  Tue Feb 23 21:18:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Feb 2016 02:18:11 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1456280291.56.0.750448748675.issue26385@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is my proposed version for Python 2.

----------
Added file: http://bugs.python.org/file42015/issue26385_4_py2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Tue Feb 23 21:28:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Feb 2016 02:28:37 +0000
Subject: [issue26335] Make mmap.write return the number of bytes written like
 other write methods
In-Reply-To: <1455144937.95.0.515520937166.issue26335@psf.upfronthosting.co.za>
Message-ID: <1456280917.79.0.974869275456.issue26335@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks okay to me. I guess it would be good to write a What?s New entry as well.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26335>
_______________________________________

From report at bugs.python.org  Tue Feb 23 21:41:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Feb 2016 02:41:15 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1456281675.1.0.962054947558.issue26372@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Tue Feb 23 21:42:51 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Feb 2016 02:42:51 +0000
Subject: [issue25671] Fix venv activate.fish to maintain $status
In-Reply-To: <1447946690.19.0.336666934208.issue25671@psf.upfronthosting.co.za>
Message-ID: <1456281771.24.0.509016676915.issue25671@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +vinay.sajip
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25671>
_______________________________________

From report at bugs.python.org  Wed Feb 24 01:30:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 06:30:20 +0000
Subject: [issue5824] SocketServer.DatagramRequestHandler Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <20160224063016.1958.69012@psf.io>


Roundup Robot added the comment:

New changeset 92ae4a305858 by Martin Panter in branch '2.7':
Issue #5824: Fix DatagramRequestHandler tests by binding the client socket
https://hg.python.org/cpython/rev/92ae4a305858

New changeset 0d9d8fdd9736 by Martin Panter in branch '3.5':
Issue #5824: Fix DatagramRequestHandler tests by binding the client socket
https://hg.python.org/cpython/rev/0d9d8fdd9736

New changeset 113e9c6fd64d by Martin Panter in branch 'default':
Issue #5824: Merge socketserver tests from 3.5
https://hg.python.org/cpython/rev/113e9c6fd64d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________

From report at bugs.python.org  Wed Feb 24 02:14:08 2016
From: report at bugs.python.org (Mike Kaplinskiy)
Date: Wed, 24 Feb 2016 07:14:08 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1456298048.18.0.297407532752.issue26388@psf.upfronthosting.co.za>


Mike Kaplinskiy added the comment:

So how might I get this patch committed? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________

From report at bugs.python.org  Wed Feb 24 02:46:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 07:46:54 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1456300014.76.0.700792736467.issue26376@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If the problem is that the window is too small to contain the close icon, this is not Python issue. May be this is Tk issue or end application issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Wed Feb 24 02:59:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 07:59:32 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1456300772.17.0.931130058173.issue26372@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is just the bug I reported in msg236951.

Text streams are buffered, thus setting bufsize=0 does not help if universal_newlines=True.

Added comments on Rietveld.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:03:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 08:03:01 +0000
Subject: [issue25770] expose name, args, and kwargs from methodcaller
In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za>
Message-ID: <1456300981.87.0.369585385015.issue25770@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't like the name "keywords". May be I'm not right. Needed opinions of other core developers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25770>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:16:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 08:16:53 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1456301813.49.0.429370421748.issue22836@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Surely changing the behavior of repr() can be made only in the default branch. this issue needs the patch for all versions.

I don't know whether this is the best solution, but the patch looks good enough to me at this moment. If you have no doubts feel free to commit it Martin.

----------
assignee:  -> martin.panter
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:19:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 08:19:11 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1456301951.19.0.417313280969.issue26302@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Do you want to commit the patch Jason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26302>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:24:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 08:24:07 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1456302247.08.0.529714697297.issue26049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide a microbenchmark that exposes the benefit of this optimization?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:26:09 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Feb 2016 08:26:09 +0000
Subject: [issue26422] printing 1e23 and up is incorrect
In-Reply-To: <1456262746.09.0.528501038499.issue26422@psf.upfronthosting.co.za>
Message-ID: <1456302369.21.0.0254816652324.issue26422@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26422>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:39:21 2016
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Wed, 24 Feb 2016 08:39:21 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1456303161.74.0.556242562919.issue26049@psf.upfronthosting.co.za>


C?dric Krier added the comment:

Is there an infrastructure already in place for such microbenchmark?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:44:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 08:44:22 +0000
Subject: [issue16823] Python quits on running tkinter code with threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1456303462.37.0.0988085694897.issue16823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't know. I'm unable to reproduce the bug on Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16823>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:51:11 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Feb 2016 08:51:11 +0000
Subject: [issue26423] __len__() returns 32 bit int on windows leading to
 overflows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456303871.71.0.133517112345.issue26423@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

If I understand the report correctly, this affects Python 3, too. Adding 3.5 and 3.6 to the versions.

----------
nosy: +mark.dickinson
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:02:59 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Wed, 24 Feb 2016 09:02:59 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456304579.66.0.976652053598.issue26404@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Updated the patch:
1. Did the changes requested in the CR.
2. Changed the example's in wsgiref.simple_server to use context manager.
3. Added What's New entry.

----------
Added file: http://bugs.python.org/file42016/socketserver_context_manager3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:03:25 2016
From: report at bugs.python.org (MARTA Roggero)
Date: Wed, 24 Feb 2016 09:03:25 +0000
Subject: [issue26424] QPyNullVariant
Message-ID: <1456304605.68.0.937952212287.issue26424@psf.upfronthosting.co.za>


New submission from MARTA Roggero:

Good morning,

I use the latest version of QGIS (Lyon) in MAC and have se the default Python version 2.7. Moreover, I have installed all the required python modules and GDAL.

It was working before, but now, when I click on the "Browse" button in Vector-> Geoprocessing->Union, it returns the following error (actually, it returns this error whenever I click on any "browse" button in QGIS):

Error during execution of Python code :

TypeError: QgsEncodingFileDialog(QWidget parent=None, QString caption=QString(), QString directory=QString(), QString filter=QString(), QString encoding=QString()): argument 3 has unexpected type 'QPyNullVariant' 
Traceback (most recent call last):
  File "/Applications/QGIS.app/Contents/Resources/python/plugins/fTools/tools/doGeoprocessing.py", line 125, in outFile
    (self.shapefileName, self.encoding) = ftools_utils.saveDialog(self)
  File "/Applications/QGIS.app/Contents/Resources/python/plugins/fTools/tools/ftools_utils.py", line 327, in saveDialog
    fileDialog = QgsEncodingFileDialog(parent, QCoreApplication.translate("fTools", "Save output shapefile"), dirName, filtering, encode)
TypeError: QgsEncodingFileDialog(QWidget parent=None, QString caption=QString(), QString directory=QString(), QString filter=QString(), QString encoding=QString()): argument 3 has unexpected type 'QPyNullVariant'


Versione Python: 2.7.10 (default, Oct 23 2015, 18:05:06) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] 
Versione di QGIS: 2.12.1-Lyon Lyon, exported 


I cannot enter the path manually. It does not allow me to click in the blank field.

Thanks for every answer,
Marta

----------
components: Macintosh
messages: 260772
nosy: MARTA Roggero, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: QPyNullVariant
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26424>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:04:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 09:04:55 +0000
Subject: [issue26423] __len__() returns 32 bit int on windows leading to
 overflows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456304695.66.0.48837009637.issue26423@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> __len__() always returns an int which on windows machines is tied to the size of a c long and is always 32 bits even if it's compiled for 64 bit.

Hum, I don't understand this statement. It looks like the code uses Py_ssize_t everywhere and Py_ssize_t is supposed to be able to store a whole pointer, so be 64-bit when Python is compiled in 64-bit mode.

> Python 2.7.8 |Anaconda 2.1.0 (64-bit)| (default, Jul  2 2014, 15:12:11) [MSC v.1500 64 bit (AMD64)] on win32

This is a 32-bit build ("win32"), no? max.size is 2147483647 on 32-bit mode if I recall correctly. On 64-bit, it's 9223372036854775807. By the way, on 64-bit, sys.maxsize == sys.maxint.


In Python 2:

len(obj) => builtin_len() => PyObject_Size() which returns a Py_ssize_t

For string, PyObject_Size() => string_length() => Py_SIZE(obj) => ((PyVarObject *)obj)->ob_size

PyVarObject.ob_size has the type Py_ssize_t.

builtin_len() gets a Py_ssize_t which is converted to a Python int or long with PyInt_FromSsize_t().

PyInt_FromSsize_t() creates an int if the value fits into a C long, or it calls _PyLong_FromSsize_t().


Difference in Python 3:

builtin_len() also gets a Py_ssize_t, but it calls PyLong_FromSsize_t() (since Python short integers as gone, long became int in Python 3).

string_length() is replaced with unicode_length() => PyUnicode_GET_LENGTH() => (PyASCIIObject *)obj)->length and PyASCIIObject.length type is Py_ssize_t.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:16:10 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Feb 2016 09:16:10 +0000
Subject: [issue26423] __len__() returns 32 bit int on windows leading to
 overflows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456305370.21.0.444663980946.issue26423@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> This is a 32-bit build ("win32"), no?

No. "win32" appears for both 32-bit and 64-bit builds on Windows. This is a 64-bit build. `sys.maxint` is 2**31 - 1, and `sys.maxsize` is 2**63 - 1. They're not equal.

I can reproduce the issue with a stock Python, on both 2.7 and 3.5.

----------
components: +Interpreter Core
priority: normal -> high
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:21:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 09:21:39 +0000
Subject: [issue26423] __len__() returns 32 bit int on windows leading to
 overflows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456305699.45.0.976584034339.issue26423@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I tested Python 2.7 on Windows, downloaded from python.org:

* 32-bit:

  - 'x'*(2**31+5) fails with OverflowError as expected
  - len('x' * (sys.maxsize // 2)) returns 2**30-1 as a Python int
  - for length larger with 'x' * (sys.maxsize // 2), I get a MemoryError, probably because of a integer overflow in the C code, or maybe because malloc() failed, I don't know

* 64-bit:

  - len('x' * (2**32 + 5)) returns 2**32 + 5 (a positive number) as a Pyhon long
  - len('x' * (2**31 + 5)) returns 2**31 + 5 (a positive number) as a Pyhon long
  - len('x' * (2**31 - 5)) returns 2**31 - 5 (a positive number) as a Pyhon int

Limits :

* 32-bit: sys.maxint == 2**31-1, sys.maxsize == 2**31-1 == sys.maxint
* 64-bit: sys.maxint == 2**31-1, sys.maxsize == 2**63-1


It looks like the issue is specific to Python compiled by Continuum ("Anaconda" flavor)?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:22:44 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Feb 2016 09:22:44 +0000
Subject: [issue26423] __len__() returns 32 bit int on windows leading to
 overflows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456305764.95.0.162503384317.issue26423@psf.upfronthosting.co.za>


Georg Brandl added the comment:

You need to call `x.__len__()` explicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:23:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 09:23:50 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456305830.02.0.120172402389.issue26423@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: __len__() returns 32 bit int on windows leading to overflows -> Integer overflow in wrap_lenfunc() on 64-bit build of Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:24:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 09:24:57 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456305897.73.0.441257622167.issue26423@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> You need to call `x.__len__()` explicitly.

Ah ok :-) I didn't read carefully the initial message.

Attached patch should fix the issue on Python 2.7. It uses the same function than builtin_len() to cast the C Py_ssize_t to a Python int or long.

----------
keywords: +patch
Added file: http://bugs.python.org/file42017/wrap_lenfunc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:25:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 09:25:17 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456305917.48.0.760284370347.issue26423@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Integer overflow in wrap_lenfunc() on 64-bit build of Windows -> Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:54:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 09:54:28 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1456307668.74.0.727231543996.issue22836@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed unraisable-continue.v4.patch, comments on Rietveld.

Would it be possible to include at least the name of the exception type in the error message? It's less likely than writing Py_TYPE(obj)->tp_name failed, than error in exc.__str() no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:57:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 09:57:15 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1456307835.14.0.553448413051.issue22836@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I like the idea of enhance code writing exception reports, I'm strongly opposed to modify repr() to ignore exceptions. I would to be noticed when repr() fails badly.

I like how the logging module catchs any formating error and logs an error when the formatting fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:57:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 09:57:22 +0000
Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle
In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za>
Message-ID: <1456307842.82.0.727846954536.issue26386@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is the patch with tests.

But I like the idea to make the selection_*() methods conforming with the delete() and detach() methods in 3.6.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file42018/ttk_treeview_selection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26386>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:08:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 10:08:34 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <20160224100825.1549.55464@psf.io>


Roundup Robot added the comment:

New changeset ce5bf3290621 by Serhiy Storchaka in branch '3.5':
Issue #25913: Leading <~ is optional now in base64.a85decode() with adobe=True.
https://hg.python.org/cpython/rev/ce5bf3290621

New changeset 90d5473b8673 by Serhiy Storchaka in branch 'default':
Issue #25913: Leading <~ is optional now in base64.a85decode() with adobe=True.
https://hg.python.org/cpython/rev/90d5473b8673

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25913>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:13:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 10:13:00 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <1456308780.46.0.227059984078.issue25913@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Soren for your report, thank you Swati for your patch, and thank you Martin for your review.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25913>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:14:39 2016
From: report at bugs.python.org (Konrad)
Date: Wed, 24 Feb 2016 10:14:39 +0000
Subject: [issue26425] 'TypeError: object of type 'NoneType' has no len()' in
 'splitdrive'
Message-ID: <1456308879.88.0.0764113291168.issue26425@psf.upfronthosting.co.za>


New submission from Konrad:

Hello,

when trying to build the 'bsddb3' extension (from https://pypi.python.org/pypi/bsddb3/6.1.1) which is necessary for Gramps ( https://gramps-project.org/wiki/index.php?title=Install_latest_BSDDB )I get the error 'TypeError: object of type 'NoneType' has no len()'. MinGW32 which I've installed for this purpose seems to work.

Here is the Traceback:

Detected Berkeley DB version 6.0 from db.h
running build
running build_py
running build_ext
building 'bsddb3._pybsddb' extension
c:\temp\mingw\bin\gcc.exe -mdll -O -Wall -IC:/Temp/BerkelyDB/include/ -Ic:\temp\
python34\include -Ic:\temp\python34\include -c Modules/_bsddb.c -o build\temp.wi
n32-3.4\Release\modules\_bsddb.o
writing build\temp.win32-3.4\Release\modules\_pybsddb.def
Traceback (most recent call last):
  File "setup3.py", line 527, in <module>
    'Programming Language :: Python :: 3.4',
  File "c:\temp\python34\lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "c:\temp\python34\lib\distutils\dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "c:\temp\python34\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "c:\temp\python34\lib\distutils\command\build.py", line 126, in run
    self.run_command(cmd_name)
  File "c:\temp\python34\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "c:\temp\python34\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "c:\temp\python34\lib\site-packages\setuptools\command\build_ext.py", line 49, in run
    _build_ext.run(self)
  File "c:\temp\python34\lib\distutils\command\build_ext.py", line 339, in run
    self.build_extensions()
  File "c:\temp\python34\lib\distutils\command\build_ext.py", line 448, in build_extensions
    self.build_extension(ext)
  File "c:\temp\python34\lib\site-packages\setuptools\command\build_ext.py", line 174, in build_extension
    _build_ext.build_extension(self, ext)
  File "c:\temp\python34\lib\distutils\command\build_ext.py", line 535, in build_extension
    target_lang=language)
  File "c:\temp\python34\lib\distutils\ccompiler.py", line 717, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "c:\temp\python34\lib\distutils\cygwinccompiler.py", line 248, in link
    target_lang)
  File "c:\temp\python34\lib\distutils\unixccompiler.py", line 157, in link
    libraries)
  File "c:\temp\python34\lib\distutils\ccompiler.py", line 1092, in gen_lib_options
    opt = compiler.runtime_library_dir_option(dir)
  File "c:\temp\python34\lib\distutils\unixccompiler.py", line 224, in runtime_library_dir_option
    compiler = os.path.basename(sysconfig.get_config_var("CC"))
  File "c:\temp\python34\lib\ntpath.py", line 246, in basename
    return split(p)[1]
  File "c:\temp\python34\lib\ntpath.py", line 217, in split
    d, p = splitdrive(p)
  File "c:\temp\python34\lib\ntpath.py", line 159, in splitdrive
    if len(p) > 1:
TypeError: object of type 'NoneType' has no len()

This behavior possibly relates to other issues (http://bugs.python.org/issue21336, http://bugs.python.org/issue22587) but I'm not sure about it.

Sorry for my poor understanding of these things.

Thanks,

Konrad

----------
components: Windows
messages: 260783
nosy: Konrad, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 'TypeError: object of type 'NoneType' has no len()' in 'splitdrive'
type: compile error
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26425>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:23:17 2016
From: report at bugs.python.org (Anish Shah)
Date: Wed, 24 Feb 2016 10:23:17 +0000
Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle
In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za>
Message-ID: <1456309397.11.0.0195304168343.issue26386@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy:  -anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26386>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:40:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Feb 2016 10:40:27 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <1456310427.39.0.650140127903.issue25995@psf.upfronthosting.co.za>


Martin Panter added the comment:

The change seems to be causing some Windows buildbot failures <http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/666/steps/test/logs/stdio>:

======================================================================
ERROR: test_walk_bad_dir (test.test_os.BytesWalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.5.kloth-win64\build\lib\test\test_os.py", line 931, in test_walk_bad_dir
    root, dirs, files = next(walk_it)
  File "C:\buildbot.python.org\3.5.kloth-win64\build\lib\test\test_os.py", line 1027, in walk
    for broot, bdirs, bfiles in os.walk(os.fsencode(top), **kwargs):
  File "C:\buildbot.python.org\3.5.kloth-win64\build\lib\os.py", line 372, in walk
    entries = list(scandir(top))
TypeError: os.scandir() doesn't support bytes path on Windows, use Unicode instead

======================================================================
ERROR: test_walk_bottom_up (test.test_os.BytesWalkTests)
ERROR: test_walk_prune (test.test_os.BytesWalkTests)

Was this line

entries = list(scandir(top))

meant to be

entries = list(scandir_it)

----------
nosy: +martin.panter
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25995>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:40:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 10:40:44 +0000
Subject: [issue26405] tkinter askopenfilename doubleclick issue on windows
In-Reply-To: <1456088833.09.0.473464639317.issue26405@psf.upfronthosting.co.za>
Message-ID: <1456310444.71.0.445540676697.issue26405@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Can't reproduce the bug on Linux.

Try to run pure Tcl/Tk script (install ActiveTcl and use the "wish" command). If the bug is reproduced, this is Tk bug.

----------
nosy: +terry.reedy
Added file: http://bugs.python.org/file42019/issue26405.tcl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26405>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:42:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 10:42:31 +0000
Subject: [issue25801] ResourceWarning in test_zipfile64
In-Reply-To: <1449268595.5.0.95531754857.issue25801@psf.upfronthosting.co.za>
Message-ID: <1456310551.94.0.656337087691.issue25801@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25801>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:02:48 2016
From: report at bugs.python.org (rapolas)
Date: Wed, 24 Feb 2016 11:02:48 +0000
Subject: [issue26405] tkinter askopenfilename doubleclick issue on windows
In-Reply-To: <1456088833.09.0.473464639317.issue26405@psf.upfronthosting.co.za>
Message-ID: <1456311768.86.0.960715642525.issue26405@psf.upfronthosting.co.za>


rapolas added the comment:

I tried on Linux as well, issue wasn't present. Attached tcl script has the same behavior.

And I found this already reported on tk tracker:

https://core.tcl.tk/tk/tktview?name=faf37bd379

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26405>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:05:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 11:05:05 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <20160224110453.1723.43937@psf.io>


Roundup Robot added the comment:

New changeset 9bffe39e8273 by Serhiy Storchaka in branch '3.5':
Fixed a bug in os.walk() with bytes path on Windows caused by merging fixes
https://hg.python.org/cpython/rev/9bffe39e8273

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25911>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:05:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 11:05:05 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <20160224110453.1723.21212@psf.io>


Roundup Robot added the comment:

New changeset 9bffe39e8273 by Serhiy Storchaka in branch '3.5':
Fixed a bug in os.walk() with bytes path on Windows caused by merging fixes
https://hg.python.org/cpython/rev/9bffe39e8273

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25995>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:05:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 11:05:58 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <1456311958.72.0.930102743943.issue25995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Martin!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25995>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:08:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 11:08:18 +0000
Subject: [issue26405] tkinter askopenfilename doubleclick issue on windows
In-Reply-To: <1456088833.09.0.473464639317.issue26405@psf.upfronthosting.co.za>
Message-ID: <1456312098.95.0.896526800797.issue26405@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thus this is not Python bug.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26405>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:13:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 11:13:19 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1456312399.12.0.155785992182.issue26049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is no special infrastructure. You can just provide two files. One script should implement simple server that produces large output. Other script should implement the client that makes a number of requests and measure the time. Of course you can implement this in one file using multiprocessing if you prefer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:51:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 11:51:48 +0000
Subject: [issue26425] 'TypeError: object of type 'NoneType' has no len()' in
 'splitdrive'
In-Reply-To: <1456308879.88.0.0764113291168.issue26425@psf.upfronthosting.co.za>
Message-ID: <1456314708.04.0.320470784866.issue26425@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not related to issue22587. The problem is that sysconfig.get_config_var("CC") returns None. This may be a bug in the distutils package, in the bsddb3 extension, in MinGW32, or in user configuration.

----------
components: +Distutils
nosy: +dstufft, eric.araujo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26425>
_______________________________________

From report at bugs.python.org  Wed Feb 24 07:03:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 12:03:45 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456315425.78.0.730784021917.issue26423@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you write a test? May be on 3.x you can use range(sys.maxsize).__len__().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 07:05:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 12:05:44 +0000
Subject: [issue26421] string_richcompare invalid check Py_NotImplemented
In-Reply-To: <1456238998.85.0.782373518975.issue26421@psf.upfronthosting.co.za>
Message-ID: <1456315544.07.0.246595693559.issue26421@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If your type is not PyStringObject, why it has the Py_TPFLAGS_STRING_SUBCLASS flag set?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26421>
_______________________________________

From report at bugs.python.org  Wed Feb 24 07:08:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 12:08:51 +0000
Subject: [issue26420] IDEL for Python 3.5.1 for x64 Windows exits when pasted
 a string with non-BMP characters
In-Reply-To: <1456237474.93.0.941468320226.issue26420@psf.upfronthosting.co.za>
Message-ID: <1456315731.23.0.635123001173.issue26420@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as a duplicate of issue13153.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26420>
_______________________________________

From report at bugs.python.org  Wed Feb 24 07:09:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 12:09:40 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456315780.48.0.0470728921731.issue26415@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Wed Feb 24 07:11:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 12:11:37 +0000
Subject: [issue26387] Crash calling sqlite3_close with invalid pointer
In-Reply-To: <1455818373.79.0.020961668279.issue26387@psf.upfronthosting.co.za>
Message-ID: <1456315897.5.0.125065953781.issue26387@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26387>
_______________________________________

From report at bugs.python.org  Wed Feb 24 07:16:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 12:16:33 +0000
Subject: [issue26387] Crash calling sqlite3_close with invalid pointer
In-Reply-To: <1455818373.79.0.020961668279.issue26387@psf.upfronthosting.co.za>
Message-ID: <1456316193.2.0.295380045987.issue26387@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> test needed
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26387>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:37:42 2016
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 24 Feb 2016 13:37:42 +0000
Subject: [issue26426] email examples: incorrect use of
 email.headerregistry.Address
Message-ID: <1456321062.13.0.278509193885.issue26426@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

https://docs.python.org/3/library/email-examples.html#examples-using-the-provisional-api contains the following code:

from email.headerregistry import Address
...
msg['From'] = Address("Pep? Le Pew", "pepe at example.com")
msg['To'] = (Address("Penelope Pussycat", "penelope at example.com"),
             Address("Fabrette Pussycat", "fabrette at example.com"))

But Address takes just the username, not the whole email address, as the second argument. So this should be written as:

msg['From'] = Address("Pep? Le Pew", "pepe", "example.com")
...

or:

msg['From'] = Address("Pep? Le Pew", addr_spec="pepe at example.com")
...

----------
assignee: docs at python
components: Documentation
messages: 260796
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: email examples: incorrect use of email.headerregistry.Address

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26426>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:45:47 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 24 Feb 2016 13:45:47 +0000
Subject: [issue26426] email examples: incorrect use of
 email.headerregistry.Address
In-Reply-To: <1456321062.13.0.278509193885.issue26426@psf.upfronthosting.co.za>
Message-ID: <1456321547.6.0.55578810816.issue26426@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. This is a duplicate of issue 26176. Would you like to send a patch?

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> EmailMessage example doesn't work

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26426>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:46:34 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 24 Feb 2016 13:46:34 +0000
Subject: [issue26424] QPyNullVariant
In-Reply-To: <1456304605.68.0.937952212287.issue26424@psf.upfronthosting.co.za>
Message-ID: <1456321594.35.0.805355793672.issue26424@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

This appears to be an issue with the QGis application and not a problem with Python itself.

See the following URL for support on QGis: <http://www.qgis.org/en/site/forusers/support.html>

Regards,

  Ronald

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26424>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:47:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 13:47:09 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456321629.21.0.908871531404.issue26423@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Could you write a test?

Done.

----------
Added file: http://bugs.python.org/file42020/wrap_lenfunc-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:47:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 13:47:49 +0000
Subject: [issue26424] QPyNullVariant
In-Reply-To: <1456304605.68.0.937952212287.issue26424@psf.upfronthosting.co.za>
Message-ID: <1456321669.53.0.466972188041.issue26424@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Not a bug in *Python*.

----------
nosy: +haypo
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26424>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:51:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 13:51:43 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <20160224135140.1958.3329@psf.io>


Roundup Robot added the comment:

New changeset 758cb13aaa2c by Anish Shah <anish.shah> in branch '3.5':
Issue #26302: Correctly identify comma as an invalid character for a cookie (correcting regression in Python 3.5).
https://hg.python.org/cpython/rev/758cb13aaa2c

New changeset 91eb7ae951a1 by Jason R. Coombs in branch 'default':
Issue #26302: merge from 3.5
https://hg.python.org/cpython/rev/91eb7ae951a1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26302>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:53:53 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Feb 2016 13:53:53 +0000
Subject: [issue26426] email examples: incorrect use of
 email.headerregistry.Address
In-Reply-To: <1456321062.13.0.278509193885.issue26426@psf.upfronthosting.co.za>
Message-ID: <1456322033.64.0.249822040169.issue26426@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26426>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:54:01 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 24 Feb 2016 13:54:01 +0000
Subject: [issue26302] cookies module allows commas in keys
In-Reply-To: <1454735930.3.0.423422750364.issue26302@psf.upfronthosting.co.za>
Message-ID: <1456322041.34.0.269734427549.issue26302@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Thanks Anish for the patch, now slated for Python 3.5.2 and Python 3.6.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26302>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:54:05 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Feb 2016 13:54:05 +0000
Subject: [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1456322045.72.0.09365909679.issue26176@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:00:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 14:00:18 +0000
Subject: [issue25136] Python doesn't find Xcode 7 stub libraries
In-Reply-To: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za>
Message-ID: <20160224140005.1568.18360@psf.io>


Roundup Robot added the comment:

New changeset 59d797915dca by Ned Deily in branch '2.7':
Issue #25136: Support Apple Xcode 7's new textual SDK stub libraries.
https://hg.python.org/cpython/rev/59d797915dca

New changeset b0490b8af7aa by Ned Deily in branch '3.5':
Issue #25136: Support Apple Xcode 7's new textual SDK stub libraries.
https://hg.python.org/cpython/rev/b0490b8af7aa

New changeset db6c1308eb31 by Ned Deily in branch 'default':
Issue #25136: merge from 3.5
https://hg.python.org/cpython/rev/db6c1308eb31

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25136>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:36:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Feb 2016 14:36:03 +0000
Subject: [issue25136] Python doesn't find Xcode 7 stub libraries
In-Reply-To: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za>
Message-ID: <20160224143550.1695.2875@psf.io>


Roundup Robot added the comment:

New changeset 157eb9d40bf9 by Ned Deily in branch '2.7':
Issue #25136: Add reference to 'xcode-select --install' to Mac README.
https://hg.python.org/cpython/rev/157eb9d40bf9

New changeset 61752c7ea9c7 by Ned Deily in branch '3.5':
Issue #25136: Add reference to 'xcode-select --install' to Mac README.
https://hg.python.org/cpython/rev/61752c7ea9c7

New changeset 2c4448bbed1f by Ned Deily in branch 'default':
Issue #25136: merge from 3.5
https://hg.python.org/cpython/rev/2c4448bbed1f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25136>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:44:52 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Feb 2016 14:44:52 +0000
Subject: [issue25136] Python doesn't find Xcode 7 SDK stub libraries
In-Reply-To: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za>
Message-ID: <1456325092.51.0.770125589194.issue25136@psf.upfronthosting.co.za>


Ned Deily added the comment:

I've committed Tim's patches with some additional comments for release in 2.7.12, 3.5,2, and 3.6.0 and have added a note about using 'xcode-select --install' to the Mac/README files.  (The Developer's Guide already documents this.)  Thanks again, Tim.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Python doesn't find Xcode 7 stub libraries -> Python doesn't find Xcode 7 SDK stub libraries
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25136>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:46:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 14:46:23 +0000
Subject: [issue26384] UnboundLocalError in socket._sendfile_use_sendfile
In-Reply-To: <1455810652.46.0.743197751136.issue26384@psf.upfronthosting.co.za>
Message-ID: <1456325183.12.0.125540618653.issue26384@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This issue can be tested without moking os.fstat():

        class F:
            def fileno(self):
                return fd
        with socket.socket() as sock:
            fd = os.open(os.curdir, os.O_RDONLY)
            os.close(fd)
            self.assertRaises(socket._GiveupOnSendfile,
                              sock._sendfile_use_sendfile, F())

os.fstat() can raise not only OSError. It may be worth to test also with fd = 2**1000 and fd = None.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26384>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:46:27 2016
From: report at bugs.python.org (Victor Halperin)
Date: Wed, 24 Feb 2016 14:46:27 +0000
Subject: [issue26427] w* format in PyArg_ParseTupleAndKeywords for optional
 argument
Message-ID: <1456325186.34.0.457786949535.issue26427@psf.upfronthosting.co.za>


New submission from Victor Halperin:

Two functions read the format string in Python/getargs.c: convertitem() for present arguments and skipitem() for missing ones. They must agree on the format; in fact, a comment to this effect is written right above convertitem(). Nevertheless, skipitem() only allows '*' modifier with 's' and 'z' formats, unlike convertitem(), that correctly processes 'w*'. As a result, 'w*' works if an array arguments is supplied, and fails if it is omitted. Suggested fix: add c == 'w' comparison to the line with *format == '*' in skipitem().

----------
components: Interpreter Core
files: getargs.c
messages: 260807
nosy: VHalperin
priority: normal
severity: normal
status: open
title: w* format in PyArg_ParseTupleAndKeywords for optional argument
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42021/getargs.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26427>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:50:57 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 24 Feb 2016 14:50:57 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1456325457.36.0.931214183712.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

My initial patch would have allowed passing a readable file-like object into zipfile. I was persuaded that allowing ZipFile.open() to return a writable object was a more intuitive and flexible API.

Concurrent writes with zf.open(mode='w') should be impossible, because it only allows one open handle at a time. It still uses the lock inside _ZipWriteFile, so concurrent writes to a single handle should be serialised.

I would not recommend anyone try to do concurrent access to a single ZipFile object from multiple threads or coroutines. It's quite stateful, there is no mention of concurrency in the docs, and no tests I can see that try concurrent access. The only thing that might be safe is reading from two files inside the zip file (which shouldn't be changed by this), but I wouldn't want to guarantee even that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:54:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 14:54:40 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456325680.2.0.13031098047.issue26423@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Using a bigmem test for this issue looks excessive. Could we use the xrange() object for testing? Or weakref?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:57:00 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 24 Feb 2016 14:57:00 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1456325820.02.0.725757455257.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Oh, I see test_interleaved now, which does test overlapping reads of two files from the same zip file.

Do you want that clarified in the docs - which don't currently mention the lock at all - or in a comment in the module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:59:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 14:59:48 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456325988.79.0.360045497401.issue26423@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Could we use the xrange() object for testing?

xrange() constructor is implemented in C and looks to use C long for parameters. This issue is specific to 64-bit Windows with 32-bit C long, so xrange() doesn't seem to work here.


> Or weakref?

What do you mean? Which object? weakref.ref() has no length.


> Using a bigmem test for this issue looks excessive.

Well, I was too lazy to develop a C extension (add something to _testcapi) just for this tiny bug.

I also like tests really testing the final feature (the bug reported in this issue).

I failed to find an existing Python object with __len__() implemented in C which doesn't need to allocate 2^31 bytes to test this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:16:35 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Feb 2016 15:16:35 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456326995.05.0.165999639886.issue26423@psf.upfronthosting.co.za>


Eryk Sun added the comment:

mmap.mmap(-1, 2**31 + 5) could be used here. If the pages are never touched it won't increase the working set size. It merely maps the address range with demand-zero pages.

Unpatched:

    >>> mmap.mmap(-1, 2**31 + 5).__len__()
    -2147483643

Patched:

    >>> mmap.mmap(-1, 2**31 + 5).__len__()
    2147483653L

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:30:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 15:30:36 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456327836.79.0.395098546462.issue26423@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> mmap.mmap(-1, 2**31 + 5) could be used here.

Yeah, I hesitated to use mmap, but I'm not really a big fan of using directly a mmap object in test_descr. Unit tests are supposed to only test one thing.


> If the pages are never touched it won't increase the working set size. It merely maps the address range with demand-zero pages.

It depends on the Kernel configuration. On Solaris, overcommit is disable by default.

I prefer to use a regular Python str. Or maybe use a custom Python object for which we can control the output of __len__()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:42:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 15:42:43 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456325988.79.0.360045497401.issue26423@psf.upfronthosting.co.za>
Message-ID: <42835982.u32zig0k74@xarax>


Serhiy Storchaka added the comment:

> xrange() constructor is implemented in C and looks to use C long for
> parameters. This issue is specific to 64-bit Windows with 32-bit C long, so
> xrange() doesn't seem to work here.

What about xrange(-1, 2**31-1)? In any case the fact that xrange works not 
with Py_ssize_t, but with long, looks as a bug. I'll open a separate issue for 
this.

> > Or weakref?
> 
> What do you mean? Which object? weakref.ref() has no length.

I see that the sq_length slot in the weakproxy type is set to proxy_length.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:56:58 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Feb 2016 15:56:58 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456329418.81.0.588109560058.issue26423@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> the sq_length slot in the weakproxy type is set to proxy_length.

Nice. Its tp_getattro gets in the way of using __len__ directly, but this can be side stepped by manually binding the descriptor:

    class Test(object):
        def __len__(self):
            return 2**31 + 5

    >>> t = Test()
    >>> p = weakref.proxy(t)
    >>> p.__len__()
    2147483653L
    >>> type(p).__len__.__get__(p)()
    -2147483643

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 11:40:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 16:40:46 +0000
Subject: [issue26428] The range for xrange() is too narrow
Message-ID: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The xrange() object works with integers in the range of C long, not Py_ssize_t. Thus the idiomatic expression xrange(len(seq)) can fail for real sequences if sys.maxint < sys.maxsize (e.g on 64-bit Windows).

Proposed patch changes the xrange() implementation to use Py_ssize_t instead of C long.

----------
components: Interpreter Core
files: xrange_py_ssize_t.patch
keywords: patch
messages: 260816
nosy: benjamin.peterson, haypo, mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: The range for xrange() is too narrow
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42022/xrange_py_ssize_t.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 11:41:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 16:41:55 +0000
Subject: [issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of
 Windows with len > 2**31-1
In-Reply-To: <1456268688.08.0.284414420897.issue26423@psf.upfronthosting.co.za>
Message-ID: <1456332115.7.0.689221910621.issue26423@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With fixed issue26428 you could use xrange() for testing this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26423>
_______________________________________

From report at bugs.python.org  Wed Feb 24 11:47:31 2016
From: report at bugs.python.org (Sam Yeager)
Date: Wed, 24 Feb 2016 16:47:31 +0000
Subject: [issue26376] Tkinter root window won't close if packed.
In-Reply-To: <1455721245.86.0.235285513904.issue26376@psf.upfronthosting.co.za>
Message-ID: <1456332451.84.0.156361711785.issue26376@psf.upfronthosting.co.za>


Sam Yeager added the comment:

This occurs even when the window is large and/or packed with multiple elements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26376>
_______________________________________

From report at bugs.python.org  Wed Feb 24 11:49:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 16:49:06 +0000
Subject: [issue26427] w* format in PyArg_ParseTupleAndKeywords for optional
 argument
In-Reply-To: <1456325186.34.0.457786949535.issue26427@psf.upfronthosting.co.za>
Message-ID: <1456332546.24.0.63496384347.issue26427@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue23927.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> getargs.c skipitem() doesn't skip 'w*'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26427>
_______________________________________

From report at bugs.python.org  Wed Feb 24 12:45:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Feb 2016 17:45:49 +0000
Subject: [issue26428] The range for xrange() is too narrow on Windows 64-bit
In-Reply-To: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>
Message-ID: <1456335949.31.0.369179107023.issue26428@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> (e.g on 64-bit Windows)

Platforms with sizeof(long) < sizeof(size_t), I only know one platform: Windows 64-bit.

Since this change only impacts Windows 64-bit, we must compile (to check for compilation warnings) and run tests with this patch on Windows 64-bit.

Many other similar issues has been fixed in Python 3. I'm not sure that it's worth to spend too much time on supporting the full 64-bit range on Python 2, it's almost a new feature no?

Examples:

* issue #9611: FileIO not 64-bit safe under Windows  (Python 2 fixed)
* issue #9566: Compilation warnings under x64 Windows  (not fixed in Python 2)
* issue #16367: io.FileIO.readall() is not 64-bit safe on Windows  (Python 2 fixed)
* issue #17931: PyLong_FromPid() is not correctly defined on Windows 64-bit (not fixed in Python 2?)
* issue #15792: Fix compiler options for x64 builds on Windows  (not fixed in Python 2)
* etc.

----------
title: The range for xrange() is too narrow -> The range for xrange() is too narrow on Windows 64-bit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 12:46:08 2016
From: report at bugs.python.org (Chaitanya Mannem)
Date: Wed, 24 Feb 2016 17:46:08 +0000
Subject: [issue26429] os.path.dirname returns empty string instead of "." when
 file is in current directory
Message-ID: <1456335968.05.0.295325544141.issue26429@psf.upfronthosting.co.za>


New submission from Chaitanya Mannem:

Don't know if this is for windows compatibility or whatever but I think it makes more sense if os.path.dirname would return "." if the file passed in was in the current directory.

----------
components: Library (Lib)
messages: 260821
nosy: Chaitanya Mannem
priority: normal
severity: normal
status: open
title: os.path.dirname returns empty string instead of "." when file is in current directory
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26429>
_______________________________________

From report at bugs.python.org  Wed Feb 24 12:46:51 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Feb 2016 17:46:51 +0000
Subject: [issue26428] The range for xrange() is too narrow on Windows 64-bit
In-Reply-To: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>
Message-ID: <1456336011.3.0.267675613343.issue26428@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I hate to say it, but I think this would count as an enhancement rather than a bugfix: there's nothing documented about the range of `xrange`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 13:07:15 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 24 Feb 2016 18:07:15 +0000
Subject: [issue26429] os.path.dirname returns empty string instead of "." when
 file is in current directory
In-Reply-To: <1456335968.05.0.295325544141.issue26429@psf.upfronthosting.co.za>
Message-ID: <1456337235.28.0.28271035984.issue26429@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Changing to just 3.6, since that's the only place we could change the behavior.

That said, I'd be -1 on making such a change. It would no doubt break some existing code.

----------
nosy: +eric.smith
type:  -> enhancement
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26429>
_______________________________________

From report at bugs.python.org  Wed Feb 24 13:16:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 18:16:00 +0000
Subject: [issue26429] os.path.dirname returns empty string instead of "." when
 file is in current directory
In-Reply-To: <1456335968.05.0.295325544141.issue26429@psf.upfronthosting.co.za>
Message-ID: <1456337760.21.0.842869278174.issue26429@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is documented behavior and changing this will break existing code (for example see the implementation of glob.glob()).

If you need this, a workaround is simple and idiomatic: ``os.path.dirname(path) or os.curdir``.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26429>
_______________________________________

From report at bugs.python.org  Wed Feb 24 13:21:34 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Feb 2016 18:21:34 +0000
Subject: [issue26429] os.path.dirname returns empty string instead of "." when
 file is in current directory
In-Reply-To: <1456335968.05.0.295325544141.issue26429@psf.upfronthosting.co.za>
Message-ID: <1456338094.28.0.865562051818.issue26429@psf.upfronthosting.co.za>


Eryk Sun added the comment:

os.path.dirname is documented as the first element of os.path.split, which in turn is documented to be empty when there's no slash in the path. 

An empty string is treated as the current directory by os.path.abspath. This is in line with an empty element in the PATH environment variable. Also, Python's sys.path uses an empty string for the current directory. If you want a dot for display and logging purposes, normalize via os.path.normpath:

    >>> os.path.normpath('')
    '.'

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26429>
_______________________________________

From report at bugs.python.org  Wed Feb 24 14:13:36 2016
From: report at bugs.python.org (quetzal)
Date: Wed, 24 Feb 2016 19:13:36 +0000
Subject: [issue26430] quote marks problem on loaded file
Message-ID: <1456341216.28.0.891493532956.issue26430@psf.upfronthosting.co.za>


New submission from quetzal:

impossible to match a string pattern with a quotation mark in an opened file 
[code]
file = '''it's an opened file made of "strings"'''
if '''"string"''' in file:
____print('ok')
else:
____print('none')
[/code]
in iddle, it works with no difficulties...
but if the file comes from an file = open(fileadress).read()

the same code return nothing... it do not find the pattern string, and just because of double quote marks (i've not tried with some other marks)

for me it's a bug, because it do works well, if their no quotation marks

----------
messages: 260826
nosy: quetzal
priority: normal
severity: normal
status: open
title: quote marks problem on loaded file
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26430>
_______________________________________

From report at bugs.python.org  Wed Feb 24 14:16:56 2016
From: report at bugs.python.org (quetzal)
Date: Wed, 24 Feb 2016 19:16:56 +0000
Subject: [issue26430] quote marks problem on loaded file
In-Reply-To: <1456341216.28.0.891493532956.issue26430@psf.upfronthosting.co.za>
Message-ID: <1456341416.34.0.286494019173.issue26430@psf.upfronthosting.co.za>


quetzal added the comment:

the word "string" got an "s" for sure, or it will not match it... but the problem is not about typography :D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26430>
_______________________________________

From report at bugs.python.org  Wed Feb 24 14:21:26 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 24 Feb 2016 19:21:26 +0000
Subject: [issue26430] quote marks problem on loaded file
In-Reply-To: <1456341216.28.0.891493532956.issue26430@psf.upfronthosting.co.za>
Message-ID: <1456341686.01.0.305893161366.issue26430@psf.upfronthosting.co.za>


SilentGhost added the comment:

Could you please upload the test file that would allow us to reproduce this behaviour.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26430>
_______________________________________

From report at bugs.python.org  Wed Feb 24 14:33:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Feb 2016 19:33:41 +0000
Subject: [issue26428] The range for xrange() is too narrow on Windows 64-bit
In-Reply-To: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>
Message-ID: <1456342421.83.0.0397733405759.issue26428@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I agree that it's a new feature since xrange() still functions if you give it a value larger than `long` (right?) and there's nothing saying it has to support the full size of an index.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 14:42:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 19:42:09 +0000
Subject: [issue24229] pathlib.Path should have a copy() method
In-Reply-To: <1431966913.98.0.0205729823841.issue24229@psf.upfronthosting.co.za>
Message-ID: <1456342929.85.0.437854118646.issue24229@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24229>
_______________________________________

From report at bugs.python.org  Wed Feb 24 14:55:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 19:55:29 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1456343729.06.0.25668212047.issue1757072@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Wed Feb 24 15:00:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Feb 2016 20:00:26 +0000
Subject: [issue26428] The range for xrange() is too narrow on Windows 64-bit
In-Reply-To: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>
Message-ID: <1456344026.67.0.243225743721.issue26428@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 15:03:29 2016
From: report at bugs.python.org (quetzal)
Date: Wed, 24 Feb 2016 20:03:29 +0000
Subject: [issue26430] quote marks problem on loaded file
In-Reply-To: <1456341216.28.0.891493532956.issue26430@psf.upfronthosting.co.za>
Message-ID: <1456344209.0.0.881959156405.issue26430@psf.upfronthosting.co.za>


quetzal added the comment:

well, silentghost... a .txt file, or an .html and that's all... if there's some text into... just find a pattern with some  - " - 

import the file in python(iddle)

and type :

if '''pattern''' in file:
__ print('ok')
else:
__ print('none')

i don't think that a file is really necessary... you'll do certainly better than me in testing...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26430>
_______________________________________

From report at bugs.python.org  Wed Feb 24 15:03:58 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Feb 2016 20:03:58 +0000
Subject: [issue26428] The range for xrange() is too narrow on Windows 64-bit
In-Reply-To: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>
Message-ID: <1456344238.33.0.98298658669.issue26428@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> xrange() still functions if you give it a value larger than `long`

What do you mean? Did you mean to write range() instead of xrange()? Both range and xrange in Python 2 use a C long for the start, stop, step, and length values. With how they get used this generally isn't a problem, which is why no one previously created an issue for this.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 15:07:52 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 24 Feb 2016 20:07:52 +0000
Subject: [issue26430] quote marks problem on loaded file
In-Reply-To: <1456341216.28.0.891493532956.issue26430@psf.upfronthosting.co.za>
Message-ID: <1456344472.91.0.0195071014298.issue26430@psf.upfronthosting.co.za>


SilentGhost added the comment:

OK, sorry, but this is just nonsense. What most likely happens in your case is that the file doesn't contain a standard ASCII double quote, but one of it's fancy siblings.

For the note: I did test and naturally wasn't able to reproduce this.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26430>
_______________________________________

From report at bugs.python.org  Wed Feb 24 15:32:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Feb 2016 20:32:43 +0000
Subject: [issue5824] SocketServer.DatagramRequestHandler Broken under Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1456345963.01.0.209801475298.issue5824@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5824>
_______________________________________

From report at bugs.python.org  Wed Feb 24 16:22:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Feb 2016 21:22:07 +0000
Subject: [issue26428] The range for xrange() is too narrow on Windows 64-bit
In-Reply-To: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>
Message-ID: <1456348927.13.0.000417395627855.issue26428@psf.upfronthosting.co.za>


Brett Cannon added the comment:

No, I meant to write xrange(). My point is there is no crasher if this change didn't occur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 16:29:50 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 24 Feb 2016 21:29:50 +0000
Subject: [issue26428] The range for xrange() is too narrow on Windows 64-bit
In-Reply-To: <1456332045.09.0.811032800198.issue26428@psf.upfronthosting.co.za>
Message-ID: <1456349390.14.0.408174200278.issue26428@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> No, I meant to write xrange(). My point is there is no crasher 
> if this change didn't occur.

Oh, by 'still functions' you meant that it doesn't cause an access violation that crashes the process, as opposed to raising an OverflowError that can be handled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26428>
_______________________________________

From report at bugs.python.org  Wed Feb 24 16:49:15 2016
From: report at bugs.python.org (quetzal)
Date: Wed, 24 Feb 2016 21:49:15 +0000
Subject: [issue26430] quote marks problem on loaded file
In-Reply-To: <1456341216.28.0.891493532956.issue26430@psf.upfronthosting.co.za>
Message-ID: <1456350555.25.0.436192289523.issue26430@psf.upfronthosting.co.za>


quetzal added the comment:

thanks silentghost for tested it... i'm gonna try to see what happened be there...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26430>
_______________________________________

From report at bugs.python.org  Wed Feb 24 21:59:09 2016
From: report at bugs.python.org (Amit Saha)
Date: Thu, 25 Feb 2016 02:59:09 +0000
Subject: [issue26323] Add assert_called() and assert_called_once() methods for
 mock objects
In-Reply-To: <1455062445.23.0.2044896551.issue26323@psf.upfronthosting.co.za>
Message-ID: <1456369149.69.0.0293804752451.issue26323@psf.upfronthosting.co.za>


Amit Saha added the comment:

Thanks Michael, so looks like we are all set for merging this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26323>
_______________________________________

From report at bugs.python.org  Wed Feb 24 22:37:08 2016
From: report at bugs.python.org (Greg McCoy)
Date: Thu, 25 Feb 2016 03:37:08 +0000
Subject: [issue26431] string template substitute tests
Message-ID: <1456371428.77.0.845294692706.issue26431@psf.upfronthosting.co.za>


New submission from Greg McCoy:

Wrote test for string template substitute

----------
components: Tests
files: mywork.patch
keywords: patch
messages: 260837
nosy: Greg McCoy
priority: normal
severity: normal
status: open
title: string template substitute tests
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42023/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26431>
_______________________________________

From report at bugs.python.org  Thu Feb 25 00:12:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Feb 2016 05:12:52 +0000
Subject: [issue26431] string template substitute tests
In-Reply-To: <1456371428.77.0.845294692706.issue26431@psf.upfronthosting.co.za>
Message-ID: <1456377172.64.0.310997967794.issue26431@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This already is tested in test_pep292.py.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26431>
_______________________________________

From report at bugs.python.org  Thu Feb 25 00:40:29 2016
From: report at bugs.python.org (quetzal)
Date: Thu, 25 Feb 2016 05:40:29 +0000
Subject: [issue26430] quote marks problem on loaded file
In-Reply-To: <1456341216.28.0.891493532956.issue26430@psf.upfronthosting.co.za>
Message-ID: <1456378829.93.0.0782796178404.issue26430@psf.upfronthosting.co.za>


quetzal added the comment:

solution found.
as Silentghost was saying, the problem was in the encoding of the quotemarks... and somes other /ecute and web encoding... unseeabble directly in my navigator, and not directly in free-access by a simple xxx.replace(a,b)... 
the translation was not complete, and i omit to verify it before to come here... sorry... but it was really weird

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26430>
_______________________________________

From report at bugs.python.org  Thu Feb 25 01:08:53 2016
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 25 Feb 2016 06:08:53 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456380533.75.0.854399798664.issue26415@psf.upfronthosting.co.za>


A. Skrobov added the comment:

A practical note: if, instead of importing crash.py, I do a json.loads, with a few extra transformations:

with open("crash.py") as f: holo_table={tuple(int(z) for z in k.split(', ')):v for k,v in json.loads(f.readlines()[0][13:].replace('(','"').replace(')','"')).iteritems()}

--the whole data structure loads in a jiffy.

Makes me wonder why this roundabout approach is so much more efficient than the native parsing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 01:13:00 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Feb 2016 06:13:00 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456380780.33.0.932258688473.issue26415@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 01:26:51 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Feb 2016 06:26:51 +0000
Subject: [issue25770] expose name, args, and kwargs from methodcaller
In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za>
Message-ID: <1456381611.72.0.251679109292.issue25770@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Now that partial() has started down the path of using "keywords", it seems reasonable to stick with that name.  In pure python code, we mostly use **kwds or **kwargs but there are other variants and not much consistency, so spelling out keywords isn't unreasonable in that regard.  That said, if it feels weird to you, ask Guido what his thoughts are.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25770>
_______________________________________

From report at bugs.python.org  Thu Feb 25 02:11:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Feb 2016 07:11:41 +0000
Subject: [issue25770] expose name, args, and kwargs from methodcaller
In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za>
Message-ID: <1456384301.29.0.897355218993.issue25770@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

functools.partial is not the only precedence.

The "kwargs" attribute is used in following classes:

concurrent.futures.process._CallItem
concurrent.futures.process._WorkItem
concurrent.futures.thread._WorkItem
inspect.BoundArguments
sched.Event
threading.Timer
unittest.mock._patch
weakref.finalize._Info

The "kwds" attribute is used in following class: contextlib._GeneratorContextManager.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25770>
_______________________________________

From report at bugs.python.org  Thu Feb 25 03:16:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Feb 2016 08:16:04 +0000
Subject: [issue26432] Add partial.kwargs
Message-ID: <1456388164.52.0.992584911868.issue26432@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Most Python classes that exposes a dictionary of keyword arguments as an attribute, name this attribute "kwargs":

concurrent.futures.process._CallItem
concurrent.futures.process._WorkItem
concurrent.futures.thread._WorkItem
inspect.BoundArguments
sched.Event
threading.Timer
unittest.mock._patch
weakref.finalize._Info

The only exceptions are classes contextlib._GeneratorContextManager with the "kwds" attribute and functools.partial and functools.partialmethod with the "keywords" attribute.

Proposed patch adds the "kwargs" alias to the the "keywords" attribute in functools.partial and functools.partialmethod.

There are precedences for adding aliases in the stdlib.

----------
components: Library (Lib)
files: partial_kwargs.patch
keywords: patch
messages: 260843
nosy: gvanrossum, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add partial.kwargs
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42024/partial_kwargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26432>
_______________________________________

From report at bugs.python.org  Thu Feb 25 04:13:47 2016
From: report at bugs.python.org (Paolo Veglia)
Date: Thu, 25 Feb 2016 09:13:47 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1456391627.32.0.879215947922.issue24291@psf.upfronthosting.co.za>


Paolo Veglia added the comment:

I had the same issue as Jonathan with Python 3.5.1, big chunks of data get truncated (to ~85KB).

The problem disappears when splitting original data into smaller chunks:

    def _write(self,data):
        chunk_size = 1024
        for chunk in (data[i:i+chunk_size] for i in range(0, len(data), chunk_size)):
            self.stdout.write(chunk)

----------
nosy: +Paolo Veglia
versions:  -Python 2.7, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Thu Feb 25 04:48:39 2016
From: report at bugs.python.org (=?utf-8?q?Thomas_G=C3=BCttler?=)
Date: Thu, 25 Feb 2016 09:48:39 +0000
Subject: [issue26433] urllib.urlencode() does not explain how to handle unicode
Message-ID: <1456393719.44.0.187138588042.issue26433@psf.upfronthosting.co.za>


New submission from Thomas G?ttler:

The current docs for Python2, don't explain how to handle unicode:

https://docs.python.org/2/library/urllib.html#urllib.urlencode

It seems to be a common problem. See http://stackoverflow.com/questions/6480723/urllib-urlencode-doesnt-like-unicode-values-how-about-this-workaround

It would be nice to document the most pythonic way to handle unicode in urllib.urlencode()

----------
assignee: docs at python
components: Documentation
messages: 260845
nosy: Thomas G?ttler, docs at python
priority: normal
severity: normal
status: open
title: urllib.urlencode() does not explain how to handle unicode
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26433>
_______________________________________

From report at bugs.python.org  Thu Feb 25 04:56:47 2016
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 25 Feb 2016 09:56:47 +0000
Subject: [issue26434] multiprocessing cannot spawn grandchild from a Windows
 service
Message-ID: <1456394207.49.0.123218861266.issue26434@psf.upfronthosting.co.za>


New submission from Marc Schlaich:

This is a follow up of #5162.

There are some occasions where you can still run into this issue. One example is if you want to spawn a new multiprocessing.Process as a child of a multiprocessing.Process:

    pythonservice.exe
      - multiprocessing.Process
        - multiprocessing.Process (does not start!)


Attached is a test case. If you run this in pywin32 service debug mode, you see that the process crashes with:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Python27\lib\multiprocessing\forking.py", line 380, in main
        prepare(preparation_data)
      File "C:\Python27\lib\multiprocessing\forking.py", line 503, in prepare
        file, path_name, etc = imp.find_module(main_name, dirs)
    ImportError: No module named PythonService


In get_preparation_data is the following state:

  WINSERVICE: False
  WINEXE: False
  _python_exe: C:\Python27\python.exe


And so you get as preparation data:

  {'authkey': '...', 'sys_path': [...], 'name': 'test', 'orig_dir': '...', 'sys_argv': ['C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe'], 'main_path': 'C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe', 'log_to_stderr': False}


A workaround for me is patching `get_preparation_data` as follows:

    import multiprocessing.forking

    _org_get_preparation_data = multiprocessing.forking.get_preparation_data

    def _get_preparation_data(*args):
        data = _org_get_preparation_data(*args)
        main_path = data.get('main_path')
        if main_path is not None and main_path.endswith('exe'):
            data.pop('main_path')
        return data

    multiprocessing.forking.get_preparation_data = _get_preparation_data


BTW, the test case does not run on Python 3.5, but starting the service manually did work. So this is probably a Python 2 issue only.

----------
components: Library (Lib), Windows
files: test_mp_service.py
messages: 260846
nosy: paul.moore, schlamar, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: multiprocessing cannot spawn grandchild from a Windows service
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file42025/test_mp_service.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26434>
_______________________________________

From report at bugs.python.org  Thu Feb 25 05:05:33 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Thu, 25 Feb 2016 10:05:33 +0000
Subject: [issue26335] Make mmap.write return the number of bytes written like
 other write methods
In-Reply-To: <1455144937.95.0.515520937166.issue26335@psf.upfronthosting.co.za>
Message-ID: <1456394733.92.0.767811241466.issue26335@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

Thank you. I didn't know whether to add an entry to Doc/whatsnew/3.6.rst, Misc/NEWS or both so I chose both, feel free to modify/remove as needed.

The new patch also doesn't have a typo in the versionchanged directive present in the version 2. I noticed more typos like this (single colon instead of double colon), I'll create a separate issue.

----------
Added file: http://bugs.python.org/file42026/mmap_write_return_count3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26335>
_______________________________________

From report at bugs.python.org  Thu Feb 25 05:09:01 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Thu, 25 Feb 2016 10:09:01 +0000
Subject: [issue26435] Fix versionadded/versionchanged documentation directives
Message-ID: <1456394940.93.0.16954708831.issue26435@psf.upfronthosting.co.za>


New submission from Jakub Stasiak:

A double colon seems to be required for a directive to work, please find a patch attached.

----------
assignee: docs at python
components: Documentation
files: typos.patch
keywords: patch
messages: 260848
nosy: docs at python, jstasiak
priority: normal
severity: normal
status: open
title: Fix versionadded/versionchanged documentation directives
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42027/typos.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26435>
_______________________________________

From report at bugs.python.org  Thu Feb 25 06:16:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Feb 2016 11:16:36 +0000
Subject: [issue25801] ResourceWarning in test_zipfile64
In-Reply-To: <1449268595.5.0.95531754857.issue25801@psf.upfronthosting.co.za>
Message-ID: <20160225111633.1978.77963@psf.io>


Roundup Robot added the comment:

New changeset baec3e2e1b1f by Serhiy Storchaka in branch '3.5':
Issue #25801: Fixed resource warnings in test_zipfile64.
https://hg.python.org/cpython/rev/baec3e2e1b1f

New changeset 32051701a49d by Serhiy Storchaka in branch '2.7':
Issue #25801: Fixed resource warnings in test_zipfile64.
https://hg.python.org/cpython/rev/32051701a49d

New changeset 2193f8b956de by Serhiy Storchaka in branch 'default':
Issue #25801: Fixed resource warnings in test_zipfile64.
https://hg.python.org/cpython/rev/2193f8b956de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25801>
_______________________________________

From report at bugs.python.org  Thu Feb 25 06:23:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Feb 2016 11:23:49 +0000
Subject: [issue25801] ResourceWarning in test_zipfile64
In-Reply-To: <1449268595.5.0.95531754857.issue25801@psf.upfronthosting.co.za>
Message-ID: <1456399429.33.0.552393941144.issue25801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your patch SilentGhost.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: languishing -> closed
type:  -> resource usage
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25801>
_______________________________________

From report at bugs.python.org  Thu Feb 25 06:35:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 25 Feb 2016 11:35:01 +0000
Subject: [issue26435] Fix versionadded/versionchanged documentation directives
In-Reply-To: <1456394940.93.0.16954708831.issue26435@psf.upfronthosting.co.za>
Message-ID: <1456400101.68.0.195835095512.issue26435@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for finding these. I presume they are also applicable to 3.5.

There is a similar problem with the range() documentation:

./Doc/library/stdtypes.rst:1301:   .. data: start
./Doc/library/stdtypes.rst:1306:   .. data: stop
./Doc/library/stdtypes.rst:1310:   .. data: step

Unfortunately it looks like this error causes the text to be silently dropped from the output. There are scripts that check for other errors (make -C Doc/ suspicious check), but it seems this error is not picked up.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26435>
_______________________________________

From report at bugs.python.org  Thu Feb 25 06:42:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 25 Feb 2016 11:42:52 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1456400572.04.0.982337759388.issue24291@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Thu Feb 25 07:12:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 25 Feb 2016 12:12:01 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1456402321.15.0.658891183975.issue26039@psf.upfronthosting.co.za>


Martin Panter added the comment:

When you say concurrent writes should be impossible, I guess that only applies to a single-threaded program. There is no lock protecting the ?self._fileRefCnt > 1? check and related manipulation (not that I am saying there should be).

For serializing concurrent writes to a single handle, if that is intended it should be documented. If it is not intended, maybe it should be removed (my preference)?

It would be good to wait if Serhiy can explain the purpose of the lock, seeing he was involved in adding it and probably knows a lot more about this module than I.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Thu Feb 25 07:16:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Feb 2016 12:16:45 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <20160225121642.1980.53710@psf.io>


Roundup Robot added the comment:

New changeset d668b5595534 by Martin Panter in branch '3.5':
Issue #26402: Fix XML-RPC client retrying after server disconnection
https://hg.python.org/cpython/rev/d668b5595534

New changeset 70bf0d764939 by Martin Panter in branch 'default':
Issue #26402: Merge XML-RPC client fix from 3.5
https://hg.python.org/cpython/rev/70bf0d764939

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Thu Feb 25 07:17:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Feb 2016 12:17:37 +0000
Subject: [issue26436] Add the regex-dna benchmark
Message-ID: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds the regex-dna benchmark from The Computer Language Benchmarks Game (http://benchmarksgame.alioth.debian.org/). This is artificial but well known benchmark.

The patch is based on regex-dna Python 3 #5 program and fasta Python 3 #3 program (for generating input).

----------
components: Benchmarks
files: bm_regex_dna.patch
keywords: patch
messages: 260854
nosy: brett.cannon, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add the regex-dna benchmark
type: enhancement
Added file: http://bugs.python.org/file42028/bm_regex_dna.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Thu Feb 25 08:04:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 25 Feb 2016 13:04:03 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1456405443.77.0.695339317916.issue22836@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a new patch with Victor?s suggestions. The reports now look like

>>> raise BrokenStrException()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
__main__.BrokenStrException: <exception str() failed>
>>> o = VeryBroken()
>>> del o
Exception ignored in: <object repr() failed>
Traceback (most recent call last):
  File "<stdin>", line 9, in __del__
__main__.BrokenStrException: <exception str() failed>

----------
Added file: http://bugs.python.org/file42029/unraisable-continue.v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Thu Feb 25 08:06:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 25 Feb 2016 13:06:56 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456405616.57.0.964720107398.issue26402@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for reporting this Jelte

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Thu Feb 25 08:51:59 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 25 Feb 2016 13:51:59 +0000
Subject: [issue26437] asyncio create_server() not always accepts the 'port'
 parameter as str
Message-ID: <1456408319.2.0.804697554696.issue26437@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

create_server() used to accept the 'port' parameter as a string before in all cases (until last december at least).
The following session shows the difference in behavior when the listening address is INADDR_ANY and '127.0.0.1':

============================
$ python
Python 3.6.0a0 (default:47fa003aa9f1, Feb 24 2016, 13:09:02) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from asyncio import *
>>> loop = get_event_loop()
>>> coro = loop.create_server(Protocol(), '', '12345')
>>> loop.run_until_complete(coro)
<Server sockets=[<socket.socket fd=7, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('0.0.0.0', 12345)>, <socket.socket fd=9, family=AddressFamily.AF_INET6, type=2049, proto=6, laddr=('::', 12345, 0, 0)>]>
>>> coro = loop.create_server(Protocol(), '127.0.0.1', '12345')
>>> loop.run_until_complete(coro)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/asyncio/base_events.py", line 373, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.6/asyncio/futures.py", line 274, in result
    raise self._exception
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 240, in _step
    result = coro.send(None)
  File "/usr/local/lib/python3.6/asyncio/base_events.py", line 946, in create_server
    sock.bind(sa)
TypeError: an integer is required (got type str)
============================

IMPHO python should consistently either accept 'port' as str or require 'port' as int.

----------
components: Library (Lib)
messages: 260857
nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, xdegaye, yselivanov
priority: normal
severity: normal
status: open
title: asyncio create_server() not always accepts the 'port' parameter as str
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26437>
_______________________________________

From report at bugs.python.org  Thu Feb 25 08:57:57 2016
From: report at bugs.python.org (heha37)
Date: Thu, 25 Feb 2016 13:57:57 +0000
Subject: [issue26438] Complete your registration to Python tracker --
 key4g5ti2VWPYCbHm4wBLtl92LNQ9nzndqi
Message-ID: <tencent_204237003DE9E7343243169B@qq.com>


New submission from heha37:

is ok

---Original---
From: "Python tracker"<report at bugs.python.org>
Date: 2016/2/25 21:55:19
To: "zhanghanqun"<zhanghanqun at unitedstack.com>;
Subject: Complete your registration to Python tracker -- key4g5ti2VWPYCbHm4wBLtl92LNQ9nzndqi

To complete your registration of the user "heha37" with
Python tracker, please do one of the following:

- send a reply to report at bugs.python.org and maintain the subject line as is (the
reply's additional "Re:" is ok),

- or visit the following URL:

http://bugs.python.org/?@action=confrego&otk=4g5ti2VWPYCbHm4wBLtl92LNQ9nzndqi

----------
messages: 260858
nosy: heha37
priority: normal
severity: normal
status: open
title: Complete your registration to Python tracker -- key4g5ti2VWPYCbHm4wBLtl92LNQ9nzndqi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26438>
_______________________________________

From report at bugs.python.org  Thu Feb 25 09:00:54 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 25 Feb 2016 14:00:54 +0000
Subject: [issue26438] Complete your registration to Python tracker --
 key4g5ti2VWPYCbHm4wBLtl92LNQ9nzndqi
In-Reply-To: <tencent_204237003DE9E7343243169B@qq.com>
Message-ID: <1456408854.16.0.30413522403.issue26438@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26438>
_______________________________________

From report at bugs.python.org  Thu Feb 25 09:13:16 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 25 Feb 2016 14:13:16 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456409596.42.0.762956011933.issue26415@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It takes about 12 seconds to byte compile crash.py on my computer and less than half a second to import about 28 MB of byte code:


$ rm -rf crash.pyc __pycache__/
$ time python2.7 -c 'import crash'

real    0m11.930s
user    0m9.859s
sys     0m2.085s
$ time python2.7 -c 'import crash'

real    0m0.484s
user    0m0.401s
sys     0m0.083s
$ time python3.4 -c 'import crash'

real    0m12.327s
user    0m10.106s
sys     0m2.236s
$ time python3.4 -c 'import crash'

real    0m0.435s
user    0m0.367s
sys     0m0.069s

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 09:16:07 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 25 Feb 2016 14:16:07 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456409767.35.0.866169051853.issue26415@psf.upfronthosting.co.za>


Christian Heimes added the comment:

$ python2.7 --version
Python 2.7.10
$ python3.4 --version
Python 3.4.3
$ uname -r -o
4.3.5-300.fc23.x86_64 GNU/Linux

Intel(R) Core(TM) i7-4900MQ CPU @ 2.80GHz

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 10:10:23 2016
From: report at bugs.python.org (Michael Felt)
Date: Thu, 25 Feb 2016 15:10:23 +0000
Subject: [issue26439] ctypes.util.find_library fails ALWAYS when gcc is not
 used
Message-ID: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>


New submission from Michael Felt:

I have successful enough with python 2.7.10 (for building cloud-init), including it finding openssl libraries during the installation od setuptools (before installing pip).

I have also been able to assemble saltstack - BUT - salt-master and salt-minion fail to start because ctypes.util.find_library() always returns 'None'.
======== EXCERPT ====
  File "/opt/lib/python2.7/site-packages/salt/crypt.py", line 37, in <module>
    import salt.utils.rsax931
  File "/opt/lib/python2.7/site-packages/salt/utils/rsax931.py", line 69, in <module>
    libcrypto = _init_libcrypto()
  File "/opt/lib/python2.7/site-packages/salt/utils/rsax931.py", line 47, in _init_libcrypto
    libcrypto = _load_libcrypto()
  File "/opt/lib/python2.7/site-packages/salt/utils/rsax931.py", line 40, in _load_libcrypto
    raise OSError('Cannot locate OpenSSL libcrypto')
OSError: Cannot locate OpenSSL libcrypto
=======
I built python using the IBM compiler, and my images do not have /sbin/ldconfig installed so the assumption that /sbin/ldconfig is always installed is "a bug".

in the util.py file the code reached is:

  +219      else:
  +220
  +221          def _findSoname_ldconfig(name):
  +222              import struct
  +223              if struct.calcsize('l') == 4:
  +224                  machine = os.uname()[4] + '-32'
  +225              else:
  +226                  machine = os.uname()[4] + '-64'
  +227              mach_map = {
  +228                  'x86_64-64': 'libc6,x86-64',
  +229                  'ppc64-64': 'libc6,64bit',
  +230                  'sparc64-64': 'libc6,64bit',
  +231                  's390x-64': 'libc6,64bit',
  +232                  'ia64-64': 'libc6,IA-64',
  +233                  }
  +234              abi_type = mach_map.get(machine, 'libc6')
  +235
  +236              # XXX assuming GLIBC's ldconfig (with option -p)
  +237              expr = r'\s+(lib%s\.[^\s]+)\s+\(%s' % (re.escape(name), abi_type)
  +238              f = os.popen('/sbin/ldconfig -p 2>/dev/null')
  +239              try:
  +240                  data = f.read()
  +241              finally:
  +242                  f.close()
  +243              res = re.search(expr, data)
  +244              if not res:
  +245                  return None
  +246              return res.group(1)
  +247
  +248          def find_library(name):
  +249              return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name))
  +250

(I have not researched _get_soname or _findLib_gcc but neither of these "feel right" as AIX, by default, does not end library (archives) with .so (archives end with .a and archive members frequently end with .so)

That this is/has not been reported more frequently may be because python programmers are avoiding ctypes - when portability is essential.

I hope that, just as for Solaris - where an alternate program is used - that AIX can have a block:
 # if os.name == "posix" and sys.platform.startswith("aix"):

so that if ldconfig is not available the command /usr/bin/dump could be used instead, and/or search LIBPATH and/or (when not empty) and/or ldd (for programs). Ideally, /sbin/ldconfig would not be need at all!

dump output:

root at x064:[/data/prj/gnu/bashRC1-4.4]dump -Xany -H /opt/bin/python

/opt/bin/python:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x000005ac       0x000035e3       0x0000006e       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000005       0x00030ee4       0x00006772       0x00030f52       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/vac/lib:/usr/lib:/lib                                            
1                                    libc.a              shr.o               
2                                    libpthreads.a       shr_xpg5.o          
3                                    libpthreads.a       shr_comm.o          
4                                    libdl.a             shr.o        

root at x064:[/usr/bin]dump -Xany -H /usr/lib/libcrypto.a

/usr/lib/libcrypto.a[libcrypto.so]:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000ff9       0x0000498a       0x00000038       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x0004f1f0       0x00014636       0x0004f228       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/lib:/lib                                                         
1                                    libc.a              shr.o               
2                                    libpthreads.a       shr_xpg5.o          

/usr/lib/libcrypto.a[libcrypto.so.0.9.8]:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000c4e       0x00004312       0x00000038       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x00044c48       0x0000f236       0x00044c80       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/lib:/lib                                                         
1                                    libc.a              shr.o               
2                                    libpthreads.a       shr_xpg5.o          

/usr/lib/libcrypto.a[libcrypto.so.1.0.0]:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000ff9       0x0000498a       0x00000038       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x0004f1f0       0x00014636       0x0004f228       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/lib:/lib                                                         
1                                    libc.a              shr.o               
2                                    libpthreads.a       shr_xpg5.o          

/usr/lib/libcrypto.a[libcrypto64.so]:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000ff2       0x00004987       0x0000003e       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x00061758       0x00014e03       0x00061796       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/lib:/lib                                                         
1                                    libc.a              shr_64.o            
2                                    libpthreads.a       shr_xpg5_64.o       

/usr/lib/libcrypto.a[libcrypto64.so.0.9.8]:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000c47       0x0000430d       0x0000003e       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x000557b0       0x0000f9e7       0x000557ee       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/lib:/lib                                                         
1                                    libc.a              shr_64.o            
2                                    libpthreads.a       shr_xpg5_64.o       

/usr/lib/libcrypto.a[libcrypto64.so.1.0.0]:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000ff2       0x00004987       0x0000003e       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x00061758       0x00014e03       0x00061796       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/lib:/lib                                                         
1                                    libc.a              shr_64.o            
2                                    libpthreads.a       shr_xpg5_64.o       
root at x064:[/usr/bin]
root at x064:[/usr/bin]echo $?                           
0


ldd outpath:
root at x064:[/usr/bin]ldd /opt/bin/python
/opt/bin/python needs:
         /usr/lib/libc.a(shr.o)
         /usr/lib/libpthreads.a(shr_xpg5.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /usr/lib/libdl.a(shr.o)
         /unix
         /usr/lib/libcrypt.a(shr.o)

root at x064:[/usr/bin]ldd /usr/lib/libcrypto.a
ldd: /usr/lib/libcrypto.a: File is an archive.
root at x064:[/usr/bin]echo $?                 
2

----------
components: ctypes
messages: 260861
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: ctypes.util.find_library fails ALWAYS when gcc is not used
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Thu Feb 25 11:02:39 2016
From: report at bugs.python.org (Michael Felt)
Date: Thu, 25 Feb 2016 16:02:39 +0000
Subject: [issue26439] ctypes.util.find_library fails ALWAYS when gcc is not
 used
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456416159.01.0.3174039515.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

p.s. On a debian (on POWER) system, the function is working, but the test seems a bit broken as well, i.e., cdll.LoadLibrary("libm.so") is not working even though 

    if os.name == "posix":
        # find and load_version
        print find_library("m")
        print find_library("c")
        print find_library("bz2")

has successfully printed.
root at ipv4:/home/michael# python -m ctypes.util
libm.so.6
libc.so.6
libbz2.so.1.0
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.7/ctypes/util.py", line 287, in <module>
    test()
  File "/usr/lib/python2.7/ctypes/util.py", line 282, in test
    print cdll.LoadLibrary("libm.so")
  File "/usr/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
    return self._dlltype(name)
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: libm.so: cannot open shared object file: No such file or directory
root at ipv4:/home/michael# uname -a
Linux ipv4.rootvg.net 3.16.0-4-powerpc64 #1 SMP Debian 3.16.7-ckt9-3 (2015-04-23) ppc64 GNU/Linux
root at ipv4:/home/michael# ldconfig -p | grep libm.so
        libm.so.6 (libc6, OS ABI: Linux 2.6.32) => /lib/powerpc-linux-gnu/libm.so.6
root at ipv4:/home/michael# ls -l /lib/powerpc-linux-gnu/libm.so.6
lrwxrwxrwx 1 root root 12 Apr 15  2015 /lib/powerpc-linux-gnu/libm.so.6 -> libm-2.19.so
root at ipv4:/home/michael# ls -l /lib/powerpc-linux-gnu/libm-2.19.so
-rw-r--r-- 1 root root 743784 Apr 15  2015 /lib/powerpc-linux-gnu/libm-2.19.so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Thu Feb 25 11:08:47 2016
From: report at bugs.python.org (Michael Felt)
Date: Thu, 25 Feb 2016 16:08:47 +0000
Subject: [issue26439] ctypes.util.find_library fails ALWAYS when gcc is not
 used
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456416527.39.0.0109184005772.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

Further testing...

I added an extremely simple hack in util.py so that a archive (AIX library) name got returned.

Also in this case - the     print cdll.LoadLibrary("libc.a") fails.

   +74  if os.name == "posix" and sys.platform == "darwin":
   +75      from ctypes.macholib.dyld import dyld_find as _dyld_find
   +76      def find_library(name):
   +77          possible = ['lib%s.dylib' % name,
   +78                      '%s.dylib' % name,
   +79                      '%s.framework/%s' % (name, name)]
   +80          for name in possible:
   +81              try:
   +82                  return _dyld_find(name)
   +83              except ValueError:
   +84                  continue
   +85          return None
   +86
   +87  if os.name == "posix" and sys.platform.startswith("aix"):
   +88       def find_library(name):
   +89          expr = "lib" + name + ".a"
   +90          return expr
   +91
   +92  elif os.name == "posix":
   +93      # Andreas Degert's find functions, using gcc, /sbin/ldconfig, objdump
   +94      import re, tempfile, errno
   +95
   +96      def _findLib_gcc(name):

  +275          else:
  +276              print cdll.LoadLibrary("libc.a")
  +277              print cdll.LoadLibrary("libm.so")
  +278              print cdll.LoadLibrary("libcrypt.so")

root at x064:[/tmp]python -m ctypes.util
libm.a
libc.a
libbz2.a
Traceback (most recent call last):
  File "/opt/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/opt/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/opt/lib/python2.7/ctypes/util.py", line 282, in <module>
    test()
  File "/opt/lib/python2.7/ctypes/util.py", line 276, in test
    print cdll.LoadLibrary("libc.a")
  File "/opt/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
    return self._dlltype(name)
  File "/opt/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
OSError:        0509-022 Cannot load module /usr/lib/libc.a.
        0509-103   The module has an invalid magic number.

So, what needs to be returned so that cdll.LoadLibrary could use that result? (e.g., I know that the default libm.a has no shared members on AIX 5.3 TL7 - but libc.a does (shr.o and more, but not all!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Thu Feb 25 11:18:09 2016
From: report at bugs.python.org (Michael Felt)
Date: Thu, 25 Feb 2016 16:18:09 +0000
Subject: [issue26439] ctypes.util.find_library fails ALWAYS when gcc is not
 used
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456417089.39.0.850133579664.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

Last message (back to debian, and minor changes to learn expected behavior)

        if sys.platform == "darwin":
            print cdll.LoadLibrary("libm.dylib")
            print cdll.LoadLibrary("libcrypto.dylib")
            print cdll.LoadLibrary("libSystem.dylib")
            print cdll.LoadLibrary("System.framework/System")
        else:
            print cdll.LoadLibrary("libm.so.6")
#            print cdll.LoadLibrary("libcrypt.so")
            print find_library("crypt")
            x = find_library("crypt")
            print cdll.LoadLibrary(x)

returns:
root at ipv4:/home/michael# python -m ctypes.util
libm.so.6
libc.so.6
libbz2.so.1.0
<CDLL 'libm.so.6', handle f7e65528 at f7b51fb0>
libcrypt.so.1
<CDLL 'libcrypt.so.1', handle 106a1878 at f7b51fb0>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Thu Feb 25 11:23:29 2016
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 25 Feb 2016 16:23:29 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456417409.95.0.0149614959873.issue26415@psf.upfronthosting.co.za>


A. Skrobov added the comment:

Mine is on Windows. I've now installed both 2.7.10 and 3.4.3 to reconfirm, and it's still the same, on both of them, except that on 3.4.3 it crashes with a MemoryError much faster (within a couple minutes).

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 11:49:19 2016
From: report at bugs.python.org (Bill Lee)
Date: Thu, 25 Feb 2016 16:49:19 +0000
Subject: [issue26440] tarfile._FileInFile.seekable is broken in stream mode
Message-ID: <1456418959.65.0.0948342534374.issue26440@psf.upfronthosting.co.za>


New submission from Bill Lee:

Description
===========
With a file object, retrieved by the `extractfile` method of a TarFile object opened in stream mode, calling its `seekable` method will raise an AttributeError.

How to Reproduce
================
cat > seekable.py << EOF
import sys
import tarfile
tar = tarfile.open(fileobj=sys.stdin.buffer, mode='r|')
contentFile = tar.extractfile(tar.next())
print(contentFile.seekable())
EOF

tar -cf test.tar seekable.py
python seekable.py < test.tar


Traceback
=========
Traceback (most recent call last):
  File "seekable.py", line 5, in <module>
    print(contentFile.seekable())
  File "/usr/local/lib/python3.5/tarfile.py", line 649, in seekable
    return self.fileobj.seekable()

How to Fix
==========
I think that adding a method seekable(), which always return False, to tarfile._Stream will works.

----------
components: Library (Lib)
messages: 260866
nosy: Bill Lee
priority: normal
severity: normal
status: open
title: tarfile._FileInFile.seekable is broken in stream mode
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26440>
_______________________________________

From report at bugs.python.org  Thu Feb 25 11:57:25 2016
From: report at bugs.python.org (Bill Lee)
Date: Thu, 25 Feb 2016 16:57:25 +0000
Subject: [issue26440] tarfile._FileInFile.seekable is broken in stream mode
In-Reply-To: <1456418959.65.0.0948342534374.issue26440@psf.upfronthosting.co.za>
Message-ID: <1456419445.64.0.242370732927.issue26440@psf.upfronthosting.co.za>


Bill Lee added the comment:

I posted an incomplete traceback by mistake. Here is the whole traceback.

Traceback
=========
Traceback (most recent call last):
  File "seekable.py", line 5, in <module>
    print(contentFile.seekable())
  File "/usr/local/lib/python3.5/tarfile.py", line 649, in seekable
    return self.fileobj.seekable()
AttributeError: '_Stream' object has no attribute 'seekable'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26440>
_______________________________________

From report at bugs.python.org  Thu Feb 25 12:08:44 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 25 Feb 2016 17:08:44 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456420124.73.0.634619368095.issue26415@psf.upfronthosting.co.za>


Eryk Sun added the comment:

I don't think this is Windows related. Are you using 32-bit Python? On Linux, if I limit the process address space to 2 gigs, it crashes almost immediately:

    $ ulimit -v 2000000
    $ python-dbg -c 'import crash'
    Segmentation fault

It runs out of memory while parsing the file:

    Program received signal SIGSEGV, Segmentation fault.
    0x000000000048ecb4 in PyObject_Malloc (nbytes=72) at ../Objects/obmalloc.c:932
    932	../Objects/obmalloc.c: No such file or directory.
    (gdb) bt
    #0  0x000000000048ecb4 in PyObject_Malloc (nbytes=72) at ../Objects/obmalloc.c:932
    #1  0x000000000048f8be in _PyObject_DebugMallocApi (id=111 'o', nbytes=40) at ../Objects/obmalloc.c:1469
    #2  0x000000000048fa2b in _PyObject_DebugReallocApi (api=111 'o', p=0x0, nbytes=40) at ../Objects/obmalloc.c:1520
    #3  0x000000000048f83c in _PyObject_DebugRealloc (p=0x0, nbytes=40) at ../Objects/obmalloc.c:1441
    #4  0x0000000000418a02 in PyNode_AddChild (n1=0x7fff85cbffb8, type=318, str=0x0, lineno=1, col_offset=6446977)
        at ../Parser/node.c:98
    #5  0x0000000000418f53 in push (s=0xa6b680, type=318, d=0x8bfc70 <dfas+2480>, newstate=1, lineno=1, col_offset=6446977)
        at ../Parser/parser.c:126
    #6  0x000000000041946c in PyParser_AddToken (ps=0xa6b680, type=262144, str=0x7fff85cba720 "11", lineno=1, 
        col_offset=6446977, expected_ret=0x7fffffffd324) at ../Parser/parser.c:252
    #7  0x0000000000419f19 in parsetok (tok=0xa5f650, g=0x8c0ac0 <_PyParser_Grammar>, start=257, err_ret=0x7fffffffd300, 
        flags=0x7fffffffd2ec) at ../Parser/parsetok.c:198
    #8  0x0000000000419cb6 in PyParser_ParseFileFlagsEx (fp=0xa19b70, filename=0xa53b00 "crash.py", 
        g=0x8c0ac0 <_PyParser_Grammar>, start=257, ps1=0x0, ps2=0x0, err_ret=0x7fffffffd300, flags=0x7fffffffd2ec)
        at ../Parser/parsetok.c:106

----------
components:  -Windows
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 12:15:02 2016
From: report at bugs.python.org (Jelte Fennema)
Date: Thu, 25 Feb 2016 17:15:02 +0000
Subject: [issue26402] Regression in Python 3.5 xmlrpc.client,
 raises RemoteDisconnected seemingly randomly.
In-Reply-To: <1456070616.55.0.333319744792.issue26402@psf.upfronthosting.co.za>
Message-ID: <1456420502.9.0.270968618912.issue26402@psf.upfronthosting.co.za>


Jelte Fennema added the comment:

No problem, I'm glad to have contributed something to the language I use the most.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26402>
_______________________________________

From report at bugs.python.org  Thu Feb 25 12:23:28 2016
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 25 Feb 2016 17:23:28 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456421008.93.0.0778223285684.issue26415@psf.upfronthosting.co.za>


A. Skrobov added the comment:

My Python is 64-bit, but my computer only has 2GB physical RAM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 12:26:50 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Thu, 25 Feb 2016 17:26:50 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456421210.77.0.456443170906.issue26404@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

updated the patch according to the CR comments.

----------
Added file: http://bugs.python.org/file42030/socketserver_context_manager4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Thu Feb 25 12:42:51 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Feb 2016 17:42:51 +0000
Subject: [issue26436] Add the regex-dna benchmark
In-Reply-To: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>
Message-ID: <1456422171.52.0.573912363157.issue26436@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I assume the code looks idiomatic to you?

And out of curiosity, what does the performance look like between something 3.5 and default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Thu Feb 25 12:43:17 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Feb 2016 17:43:17 +0000
Subject: [issue26436] Add the regex-dna benchmark
In-Reply-To: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>
Message-ID: <1456422197.86.0.356760599362.issue26436@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Oh, and how long does an execution take?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Thu Feb 25 12:47:34 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 25 Feb 2016 17:47:34 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456422454.15.0.751411153529.issue26415@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> My Python is 64-bit, but my computer only has 2GB physical RAM.

That explains why it takes half an hour to crash. It's thrashing on page faults. Adding another paging file or increasing the size of your current paging file should allow this to finish parsing... eventually in maybe an hour or two. 

The design of the parser isn't something I've delved into very much, but possibly the dynamic nature of Python prevents optimizing the memory footprint here. Or maybe no one has seen the need to optimize parsing containers (dicts, sets, lists, tuples) that have constant literals. This is an inefficient way to store 35 MiB of data, as opposed to XML, JSON, or a binary format.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu Feb 25 13:15:49 2016
From: report at bugs.python.org (Alessandro Cucci)
Date: Thu, 25 Feb 2016 18:15:49 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456424149.8.0.313863125597.issue19475@psf.upfronthosting.co.za>


Alessandro Cucci added the comment:

Oh, now I see your point.

I've uploaded a new patch with a note for that.

----------
Added file: http://bugs.python.org/file42031/issue19475_v16.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Thu Feb 25 13:29:22 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 25 Feb 2016 18:29:22 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1456424149.8.0.313863125597.issue19475@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKMCZ+=cM42MGjPBJ04zevqaM_JWDryD4uQkBMT86cTRA@mail.gmail.com>


Guido van Rossum added the comment:

Out of context here, but regarding round vs. truncate, IIUC for time
truncating down is the norm. My digital clock shows "12:00" for the
duration of the minute starting at noon. People look for clocks to
flip to know when it is exactly a given time (if the clock is accurate
enough).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Thu Feb 25 13:42:38 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 25 Feb 2016 18:42:38 +0000
Subject: [issue26437] asyncio create_server() not always accepts the 'port'
 parameter as str
In-Reply-To: <1456408319.2.0.804697554696.issue26437@psf.upfronthosting.co.za>
Message-ID: <1456425758.93.0.776001411868.issue26437@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't know why it used to accept a string port, but I can't find anything in the docs indicating that is acceptable. I am guessing the doc authors assumed it was so obvious that a port is an integer they forgot to mention it.

I can guess that in the past some system API was used that considered the port a "servname" to be looked up in /etc/services (likely the getaddrinfo() call).

But if you were passing '12345' instead of 12345, well, you always had a latent bug in your program.

I don't think the code ought to be adjusted to explicitly reject string ports; but I do think the docs should be clarified on the issue.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26437>
_______________________________________

From report at bugs.python.org  Thu Feb 25 13:49:58 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Feb 2016 18:49:58 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1456426198.28.0.132117668675.issue19475@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

We discussed truncation vs. rounding some time ago.  See msg202270 and the posts around it.  The consensus was the same as Guido's current advise: do the truncation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19475>
_______________________________________

From report at bugs.python.org  Thu Feb 25 14:08:05 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 25 Feb 2016 19:08:05 +0000
Subject: [issue26435] Fix versionadded/versionchanged documentation directives
In-Reply-To: <1456394940.93.0.16954708831.issue26435@psf.upfronthosting.co.za>
Message-ID: <1456427285.54.0.597348765512.issue26435@psf.upfronthosting.co.za>


Georg Brandl added the comment:

These are interpreted as comments by docutils. "make suspicious" only checks for markup erroneously remaining in the output. "make check", which runs tools/rstlint.py, should pick them up though.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26435>
_______________________________________

From report at bugs.python.org  Thu Feb 25 14:15:39 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 25 Feb 2016 19:15:39 +0000
Subject: [issue26435] Fix versionadded/versionchanged documentation directives
In-Reply-To: <1456394940.93.0.16954708831.issue26435@psf.upfronthosting.co.za>
Message-ID: <1456427739.32.0.270652941249.issue26435@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Ok, that was a bug in rstlint. Fixed now - and now I can find quite a few instances, will fix them (most of them are in this patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26435>
_______________________________________

From report at bugs.python.org  Thu Feb 25 14:18:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Feb 2016 19:18:28 +0000
Subject: [issue26435] Fix versionadded/versionchanged documentation directives
In-Reply-To: <1456394940.93.0.16954708831.issue26435@psf.upfronthosting.co.za>
Message-ID: <20160225191820.96917.81010@psf.io>


Roundup Robot added the comment:

New changeset 1f8dc6f2b171 by Georg Brandl in branch '3.5':
Closes #26435: fix syntax in directives. Thanks to Jakub Stasiak.
https://hg.python.org/cpython/rev/1f8dc6f2b171

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26435>
_______________________________________

From report at bugs.python.org  Thu Feb 25 14:53:55 2016
From: report at bugs.python.org (Greg McCoy)
Date: Thu, 25 Feb 2016 19:53:55 +0000
Subject: [issue26431] string template substitute tests
In-Reply-To: <1456371428.77.0.845294692706.issue26431@psf.upfronthosting.co.za>
Message-ID: <1456430035.12.0.56962923543.issue26431@psf.upfronthosting.co.za>


Greg McCoy added the comment:

My Mistake, I wasn't running coverage on all the tests

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26431>
_______________________________________

From report at bugs.python.org  Thu Feb 25 16:05:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Feb 2016 21:05:33 +0000
Subject: [issue26431] string template substitute tests
In-Reply-To: <1456371428.77.0.845294692706.issue26431@psf.upfronthosting.co.za>
Message-ID: <1456434333.06.0.978613488497.issue26431@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26431>
_______________________________________

From report at bugs.python.org  Thu Feb 25 17:48:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 25 Feb 2016 22:48:00 +0000
Subject: [issue26441] email.charset: to_splittable and from_splittable are not
 there anymore!
Message-ID: <1456440480.97.0.346838980393.issue26441@psf.upfronthosting.co.za>


New submission from Martin Panter:

In /Doc/library/email.charset.rst, the descriptions of the to_splittable() and from_splittable() methods are disabled. The comment saying they are not there is presumably referring to the fact that the methods were removed from the Python 3 implementation. They were removed in r57697, and the documentation was adjusted in revision f65de36f185c.

Perhaps the two descriptions should just be deleted from the documentation?

----------
components: email
messages: 260883
nosy: barry, martin.panter, r.david.murray
priority: normal
severity: normal
status: open
title: email.charset: to_splittable and from_splittable are not there anymore!
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26441>
_______________________________________

From report at bugs.python.org  Thu Feb 25 18:25:40 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 25 Feb 2016 23:25:40 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1456442740.18.0.422797621817.issue25507@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'import tkinter; tkinter.messagebox' should also fail, but currently work in IDLE.  See https://stackoverflow.com/questions/35619027/sub-import-issues-with-tkinter-messagebox, and my answer there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25507>
_______________________________________

From report at bugs.python.org  Thu Feb 25 19:24:55 2016
From: report at bugs.python.org (Michael Felt)
Date: Fri, 26 Feb 2016 00:24:55 +0000
Subject: [issue26439] ctypes.util.find_library fails ALWAYS when gcc is not
 used
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456446295.38.0.740920422725.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

FYI: getting objdump is not too hard...

root at x064:[/data/prj/gnu/binutils-2.25.1]v/null /usr/lib/libcrypto.a         <
In archive /usr/lib/libcrypto.a:

libcrypto.so:     file format aixcoff-rs6000


libcrypto.so.0.9.8:     file format aixcoff-rs6000


libcrypto.so.1.0.0:     file format aixcoff-rs6000


libcrypto64.so:     file format aix5coff64-rs6000


libcrypto64.so.0.9.8:     file format aix5coff64-rs6000


libcrypto64.so.1.0.0:     file format aix5coff64-rs6000

But ldconfig (as a command within glibc) will be a real headache - and I would home unnecessary.

In closing, I hope the AIX command /usr/bin/dump will be adequate as an alternative of objdump.

Where I am still a bit lost is with the "open", i.e. _dlopen(). Suggestions/hints for debugging are welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Thu Feb 25 20:14:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Feb 2016 01:14:07 +0000
Subject: [issue24421] Race condition compiling Modules/_math.c
In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za>
Message-ID: <20160226011403.2124.53012@psf.io>


Roundup Robot added the comment:

New changeset a99580157968 by Martin Panter in branch '3.5':
Issue #24421: Compile _math.c separately to avoid race condition
https://hg.python.org/cpython/rev/a99580157968

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24421>
_______________________________________

From report at bugs.python.org  Thu Feb 25 20:14:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Feb 2016 01:14:08 +0000
Subject: [issue26390] hashlib's pbkdf2_hmac documentation "rounds" does not
 match source
In-Reply-To: <1455840057.88.0.0946194046166.issue26390@psf.upfronthosting.co.za>
Message-ID: <20160226011403.2124.90765@psf.io>


Roundup Robot added the comment:

New changeset 7609aaf180b4 by Martin Panter in branch '3.5':
Issue #26390: Fix and test pbkdf2_hmac() parameter names
https://hg.python.org/cpython/rev/7609aaf180b4

New changeset a74420677e6b by Martin Panter in branch 'default':
Issue #26390: Merge pbkdf2_hmac() doc from 3.5
https://hg.python.org/cpython/rev/a74420677e6b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26390>
_______________________________________

From report at bugs.python.org  Thu Feb 25 21:15:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Feb 2016 02:15:01 +0000
Subject: [issue24421] Race condition compiling Modules/_math.c
In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za>
Message-ID: <20160226021457.1975.82523@psf.io>


Roundup Robot added the comment:

New changeset d4190ed586a4 by Martin Panter in branch '2.7':
Issue #24421: Compile _math.c separately to avoid race condition
https://hg.python.org/cpython/rev/d4190ed586a4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24421>
_______________________________________

From report at bugs.python.org  Thu Feb 25 21:15:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 26 Feb 2016 02:15:20 +0000
Subject: [issue26390] hashlib's pbkdf2_hmac documentation "rounds" does not
 match source
In-Reply-To: <1455840057.88.0.0946194046166.issue26390@psf.upfronthosting.co.za>
Message-ID: <1456452920.05.0.56525625517.issue26390@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26390>
_______________________________________

From report at bugs.python.org  Fri Feb 26 01:47:02 2016
From: report at bugs.python.org (A. Skrobov)
Date: Fri, 26 Feb 2016 06:47:02 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456469222.28.0.725400323831.issue26415@psf.upfronthosting.co.za>


A. Skrobov added the comment:

Yes, I understand that this is a matter of memory consumption, which is why I submitted this ticket as "resource usage".
What I don't understand is, what could possibly require gigabytes of memory for this task?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Fri Feb 26 03:33:51 2016
From: report at bugs.python.org (Michael Felt)
Date: Fri, 26 Feb 2016 08:33:51 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456475631.76.0.278021812865.issue26439@psf.upfronthosting.co.za>


Changes by Michael Felt <aixtools at gmail.com>:


----------
title: ctypes.util.find_library fails ALWAYS when gcc is not used -> ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Fri Feb 26 03:49:33 2016
From: report at bugs.python.org (Michael Felt)
Date: Fri, 26 Feb 2016 08:49:33 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456476573.81.0.0862852557307.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

The _dlopen call in __init__.py I have been able to fix (hack) with the following:

root at x064:[/data/prj/aixtools/python/python-2.7.10/Lib/ctypes]diff -u __init__.py /opt/lib/python2.7/ctypes/__init__.py
--- __init__.py 2015-05-23 16:09:01 +0000
+++ /opt/lib/python2.7/ctypes/__init__.py       2016-02-26 08:40:19 +0000
@@ -11,6 +11,7 @@
 from _ctypes import _Pointer
 from _ctypes import CFuncPtr as _CFuncPtr
 from _ctypes import __version__ as _ctypes_version
+# from _ctypes import RTLD_LOCAL, RTLD_GLOBAL, RTLD_NOW ## fails
 from _ctypes import RTLD_LOCAL, RTLD_GLOBAL
 from _ctypes import ArgumentError
 
@@ -32,6 +33,11 @@
     if int(_os.uname()[2].split('.')[0]) < 8:
         DEFAULT_MODE = RTLD_GLOBAL
 
+if _os.name == "posix" and _sys.platform.startswith("aix"):
+        RTLD_NOW    = 0x00000002
+        RTLD_MEMBER = 0x00040000
+        DEFAULT_MODE |= (RTLD_NOW | RTLD_MEMBER)
+
 from _ctypes import FUNCFLAG_CDECL as _FUNCFLAG_CDECL, \
      FUNCFLAG_PYTHONAPI as _FUNCFLAG_PYTHONAPI, \
      FUNCFLAG_USE_ERRNO as _FUNCFLAG_USE_ERRNO, \

I have an additional hack in util.py so that, e.g.,
find_Library("crypto")

returns:
 '/usr/lib/libcrypto.a(libcrypto.so)'

When that is passed to dlopen (plus RTLD_MEMBER) the dlopen succeeds.

<CDLL '/usr/lib/libcrypto.a/(libcrypto.so)', handle 6 at 30146670>

With some help in util.py, to do some sensible searching, being able to establish if in 32 or 64-bit mode, etc. somehing nice can be made here (imho).

p.s. can any verify whether this is limited to python 2.7? Or should python 3.X be added as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Fri Feb 26 06:00:50 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 26 Feb 2016 11:00:50 +0000
Subject: [issue25939] _ssl.enum_certificates() fails with ERROR_ACCESS_DENIED
 if python.exe run with low integrity level
In-Reply-To: <1450989628.26.0.849835515988.issue25939@psf.upfronthosting.co.za>
Message-ID: <1456484450.59.0.700973351445.issue25939@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Thanks for accepting my patch. I'm curious: any reason not applying to 2.7 branch? We're building youtube-dl.exe with py2exe on Python 2.7 as py2exe on 3.x sometimes fails. (https://github.com/rg3/youtube-dl/issues/5094)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25939>
_______________________________________

From report at bugs.python.org  Fri Feb 26 06:31:39 2016
From: report at bugs.python.org (ProgVal)
Date: Fri, 26 Feb 2016 11:31:39 +0000
Subject: [issue26442] Doc refers to xmlrpc.client but means xmlrpc.server
Message-ID: <1456486299.23.0.764792855205.issue26442@psf.upfronthosting.co.za>


New submission from ProgVal:

The doc of xmlrpc.server and xmlrpc.client both warn about XML vulnerabilities.

However, both say ?The xmlrpc.client module is not secure?, whereas the page for xml.server should say xmlrpc.server.

----------
assignee: docs at python
components: Documentation
messages: 260892
nosy: Valentin.Lorentz, docs at python
priority: normal
severity: normal
status: open
title: Doc refers to xmlrpc.client but means xmlrpc.server
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26442>
_______________________________________

From report at bugs.python.org  Fri Feb 26 07:03:48 2016
From: report at bugs.python.org (yuriy_levchenko)
Date: Fri, 26 Feb 2016 12:03:48 +0000
Subject: [issue26421] string_richcompare invalid check Py_NotImplemented
In-Reply-To: <1456238998.85.0.782373518975.issue26421@psf.upfronthosting.co.za>
Message-ID: <1456488228.54.0.0179672395776.issue26421@psf.upfronthosting.co.za>


yuriy_levchenko added the comment:

because,

PyObject_GetAttr(PyObject *v, PyObject *name)

have this code

if (!PyString_Check(name)) {

and 

PyDict_GetItem(PyObject *op, PyObject *key)

have this code

    if (!PyString_CheckExact(key) ||
        (hash = ((PyStringObject *) key)->ob_shash) == -1)
    {
        hash = PyObject_Hash(key);

next

lookdict_string(PyDictObject *mp, PyObject *key, register long hash)

    if (!PyString_CheckExact(key)) {
#ifdef SHOW_CONVERSION_COUNTS
        ++converted;
#endif
        mp->ma_lookup = lookdict;
        return lookdict(mp, key, hash);
    }

next

PyObject_RichCompare(PyObject *v, PyObject *w, int op)

and 

try_rich_compare(PyObject *v, PyObject *w, int op)

we have this code

    if ((f = RICHCOMPARE(v->ob_type)) != NULL) {
        res = (*f)(v, w, op);
        if (res != Py_NotImplemented)
            return res;
        Py_DECREF(res);
    }
    if ((f = RICHCOMPARE(w->ob_type)) != NULL) {
        return (*f)(w, v, _Py_SwappedOp[op]);
    }

v - PyStringObject
w - MyType

MyType have Py_TPFLAGS_HAVE_RICHCOMPARE and correct test with PyStringObject

but string_richcompare incorrect test type for object, and this code

a->ob_sval 

may cause "access violation" and crach!

if i replace PyString_Check on PyString_CheckExact, all work fine and correct!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26421>
_______________________________________

From report at bugs.python.org  Fri Feb 26 10:19:33 2016
From: report at bugs.python.org (=?utf-8?q?Martin_Hundeb=C3=B8ll?=)
Date: Fri, 26 Feb 2016 15:19:33 +0000
Subject: [issue26443] cross building extensions picks up host headers
Message-ID: <1456499973.95.0.823052816124.issue26443@psf.upfronthosting.co.za>


New submission from Martin Hundeb?ll:

When cross building python, the building of extensions is called with -I/usr/include and -L/usr/lib

This makes some extensions fail to compile due to picking up inline assembly from host headers (e.g. _socket[1]).

I have fixed this locally by applying the attached patch, but I cannot tell if that would make other builds fail.

[1] log output:
building '_socket' extension
arm-cortexa9neon-linux-gnueabi-gcc -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/stage/machine/usr/lib/libffi-3.2.1/include -O2 -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Werror=declaration-after-statement -I./Include -I/usr/include -I. -IInclude -I/home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/stage/cross/bin/../arm-cortexa9neon-linux-gnueabi/sysroot/usr/include -I/home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/src/Python-3.5.1/Include -I/home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/src/Python-3.5.1 -c /home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/src/Python-3.5.1/Modules/socketmodule.c -o build/temp.linux-arm-3.5/home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/src/Python-3.5.1/Modules/socketmodule.o
In file included from /usr/include/bits/byteswap.h:35:0,
                 from /usr/include/endian.h:60,
                 from /usr/include/bits/string2.h:51,
                 from /usr/include/string.h:635,
                 from ./Include/Python.h:30,
                 from /home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/src/Python-3.5.1/Modules/socketmodule.c:95:
/home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/src/Python-3.5.1/Modules/socketmodule.c: In function 'socket_getservbyport':
/usr/include/bits/byteswap-16.h:31:5: error: invalid 'asm': invalid operand for code 'w'
     __asm__ ("rorw $8, %w0"           \
     ^
/usr/include/netinet/in.h:403:21: note: in expansion of macro '__bswap_16'
 #   define htons(x) __bswap_16 (x)
                     ^
/home/mnhu/projects/pil/oe/tmp/work/machine/arm-cortexa9neon-linux-gnueabi/python-3.5.1/src/Python-3.5.1/Modules/socketmodule.c:4861:24: note: in expansion of macro 'htons'
     sp = getservbyport(htons((short)port), proto);
                        ^

----------
components: Cross-Build
files: include-dirs.patch
keywords: patch
messages: 260894
nosy: hundeboll
priority: normal
severity: normal
status: open
title: cross building extensions picks up host headers
type: compile error
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42032/include-dirs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26443>
_______________________________________

From report at bugs.python.org  Fri Feb 26 11:33:18 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 26 Feb 2016 16:33:18 +0000
Subject: [issue26434] multiprocessing cannot spawn grandchild from a Windows
 service
In-Reply-To: <1456394207.49.0.123218861266.issue26434@psf.upfronthosting.co.za>
Message-ID: <1456504398.0.0.501234833112.issue26434@psf.upfronthosting.co.za>


Davin Potts added the comment:

I can reproduce the problem under Windows 7.  Thank you for your example and description -- they were very helpful.

Detection that the original parent was PythonService.exe is necessary to avoid undoing the paths set appropriately for running under a service.  The current code only detects the immediate parent.

Modifying get_preparation_data() in lib/multiprocessing/forking.py to perform an additional test on the inherited values from the original parent's sys.argv (available via the preparation_data key 'sys_argv') would resolve this:
    if not d['sys_argv'][0].lower().endswith("pythonservice.exe"):
        ....

Potential complications to existing code appear very unlikely given its nature.

Patch forthcoming after running tests unless someone wants to beat me to it.

----------
assignee:  -> davin
nosy: +davin
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26434>
_______________________________________

From report at bugs.python.org  Fri Feb 26 11:53:50 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 26 Feb 2016 16:53:50 +0000
Subject: [issue26195] Windows frozen .exe multiprocessing.Queue access is
 denied exception
In-Reply-To: <1453690484.95.0.111987955887.issue26195@psf.upfronthosting.co.za>
Message-ID: <1456505630.8.0.156191528241.issue26195@psf.upfronthosting.co.za>


Davin Potts added the comment:

Using tools like pyinstaller (and other competing frozen-exe-creating tools) unfortunately complicates things for multiprocessing to understand the environment it's now in.  It is unclear from this description whether this should be regarded as an issue to be addressed in pyinstaller or in multiprocessing itself.  Any further information along these lines would be much appreciated.

----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26195>
_______________________________________

From report at bugs.python.org  Fri Feb 26 11:58:49 2016
From: report at bugs.python.org (Ismail s)
Date: Fri, 26 Feb 2016 16:58:49 +0000
Subject: [issue26444] Fix 2 typos on ElementTree docs
Message-ID: <1456505929.01.0.140412198941.issue26444@psf.upfronthosting.co.za>


New submission from Ismail s:

'incrementall' has been changed to 'incrementally' (and text reflowed).
'keywword' has been changed to 'keyword'.

----------
assignee: docs at python
components: Documentation
files: work.patch
keywords: patch
messages: 260897
nosy: Ismail s, docs at python
priority: normal
severity: normal
status: open
title: Fix 2 typos on ElementTree docs
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42033/work.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26444>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:13:18 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 26 Feb 2016 18:13:18 +0000
Subject: [issue26432] Add partial.kwargs
In-Reply-To: <1456388164.52.0.992584911868.issue26432@psf.upfronthosting.co.za>
Message-ID: <1456510398.63.0.548198249171.issue26432@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

-1 "foolish consistency" and all that ...

In the context of partial, it is fairly clear that "keywords" means "keyword arguments" while it may not be as clear in other more specialized contexts.  In the age of autocompletion almost everywhere, aliases are harmful because they result in user seeing redundant choices.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26432>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:13:27 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Feb 2016 18:13:27 +0000
Subject: [issue26444] Fix 2 typos on ElementTree docs
In-Reply-To: <1456505929.01.0.140412198941.issue26444@psf.upfronthosting.co.za>
Message-ID: <1456510407.73.0.85043774446.issue26444@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Reflow is kinda bad for patch review :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26444>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:15:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Feb 2016 18:15:11 +0000
Subject: [issue26444] Fix 2 typos on ElementTree docs
In-Reply-To: <1456505929.01.0.140412198941.issue26444@psf.upfronthosting.co.za>
Message-ID: <20160226181501.83573.11409@psf.io>


Roundup Robot added the comment:

New changeset 29beb1554dec by Georg Brandl in branch '3.5':
Closes #26444: typo fixes.
https://hg.python.org/cpython/rev/29beb1554dec

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26444>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:16:33 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 26 Feb 2016 18:16:33 +0000
Subject: [issue25939] _ssl.enum_certificates() fails with ERROR_ACCESS_DENIED
 if python.exe run with low integrity level
In-Reply-To: <1450989628.26.0.849835515988.issue25939@psf.upfronthosting.co.za>
Message-ID: <1456510593.12.0.884892909927.issue25939@psf.upfronthosting.co.za>


Steve Dower added the comment:

It was fixed in 2.7 - https://hg.python.org/cpython/rev/3cddcf471c70

The issue number wasn't in the commit, so it didn't appear here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25939>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:16:48 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Feb 2016 18:16:48 +0000
Subject: [issue26442] Doc refers to xmlrpc.client but means xmlrpc.server
In-Reply-To: <1456486299.23.0.764792855205.issue26442@psf.upfronthosting.co.za>
Message-ID: <1456510608.61.0.235537447653.issue26442@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks!

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26442>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:16:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Feb 2016 18:16:49 +0000
Subject: [issue26442] Doc refers to xmlrpc.client but means xmlrpc.server
In-Reply-To: <1456486299.23.0.764792855205.issue26442@psf.upfronthosting.co.za>
Message-ID: <20160226181648.1953.61479@psf.io>


Roundup Robot added the comment:

New changeset 9b240ec2bd42 by Georg Brandl in branch '3.5':
Closes #26442: fix copy-paste.
https://hg.python.org/cpython/rev/9b240ec2bd42

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26442>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:19:40 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Feb 2016 18:19:40 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1456510780.98.0.542536020196.issue25910@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: languishing -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:26:33 2016
From: report at bugs.python.org (glep)
Date: Fri, 26 Feb 2016 18:26:33 +0000
Subject: [issue26445] setup.py sdist mishandles package_dir option
Message-ID: <1456511193.21.0.2161734334.issue26445@psf.upfronthosting.co.za>


New submission from glep:

Suppose I have a setup.py with the option

   ...
   packages=['package', 'package.utils'],
   package_dir={'package.utils', '../utils'},
   ...

as would arise if ../utils was a package shared between several projets ('package', 'package1', ...).

I would expect the source distribution created by 'python setup.py sdist'
to create an archive with the following structure:

   /
   |-- package/
   |-- package/utils

And this is indeed what *bdist* does. BUT *sdist* copies '../utils' in 'package/../utils' instead of 'package/utils', with the result that utils is outside of the distribution altogether. 

The issue is referenced in a couple of StackOverflow posts that have attracted little attention so far, for example:

http://stackoverflow.com/questions/35510972/inconsistent-behaviour-of-bdist-vs-sdist-when-distributing-a-python-package

----------
components: Distutils
messages: 260904
nosy: dstufft, eric.araujo, glep
priority: normal
severity: normal
status: open
title: setup.py sdist mishandles package_dir option
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26445>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:38:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Feb 2016 18:38:13 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <20160226183801.6262.65113@psf.io>


Roundup Robot added the comment:

New changeset ce5ef48b5140 by Georg Brandl in branch '3.5':
Closes #25910: fix dead and permanently redirected links in the docs. Thanks to SilentGhost for the patch.
https://hg.python.org/cpython/rev/ce5ef48b5140

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Fri Feb 26 13:41:25 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Feb 2016 18:41:25 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1456512085.41.0.567533305853.issue25910@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Reopening, for fixing the rest of the broken ones.

----------
nosy: +georg.brandl
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Fri Feb 26 14:24:27 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 26 Feb 2016 19:24:27 +0000
Subject: [issue26446] Mention in the devguide that core devs are expected to
 follow the PSF CoC
Message-ID: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It should be mentioned in the devguide that receiving one's core developer privileges includes following the PSF CoC (https://www.python.org/psf/codeofconduct/).

----------
components: Devguide
messages: 260907
nosy: brett.cannon, ezio.melotti, willingc
priority: normal
severity: normal
stage: needs patch
status: open
title: Mention in the devguide that core devs are expected to follow the PSF CoC

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26446>
_______________________________________

From report at bugs.python.org  Fri Feb 26 15:44:07 2016
From: report at bugs.python.org (=?utf-8?b?SmVyb2Qg4oCcajNyZOKAnSBHYXduZQ==?=)
Date: Fri, 26 Feb 2016 20:44:07 +0000
Subject: [issue26447] rstrip() is pilfering my 'p'
Message-ID: <1456519447.91.0.0851895930382.issue26447@psf.upfronthosting.co.za>


New submission from Jerod ?j3rd? Gawne:

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32

In[4]: str = 'aaaaaaap.py'
In[5]: print(str.rstrip('.py'))
aaaaaaa

In[6]: str = 'aaaaaaap.pdf'
In[7]: print(str.rstrip('.pdf'))
aaaaaaa

In[8]: str = 'aaaaaaab.pdf'
In[9]: print(str.rstrip('.pdf'))
aaaaaaab

In[10]: str = 'apapapab.pdf'
In[11]: print(str.rstrip('.pdf'))
apapapab

In[12]: str = 'apapapap.pdf'
In[13]: print(str.rstrip('.pdf'))
apapapa

what's with the 'p' pilfering?

In[14]: str = 'apapapab.bdf'
In[15]: print(str.rstrip('.bdf'))
apapapa
In[16]: print(str.rstrip(r'.bdf'))
apapapa

In[18]: print(str.rstrip('\.bdf'))
apapapa

Actually though, it's grabbing an additional character before the '.' the same as the one after.

----------
messages: 260908
nosy: Jerod ?j3rd? Gawne
priority: normal
severity: normal
status: open
title: rstrip() is pilfering my 'p'
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26447>
_______________________________________

From report at bugs.python.org  Fri Feb 26 15:48:12 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 26 Feb 2016 20:48:12 +0000
Subject: [issue26447] rstrip() is pilfering my 'p'
In-Reply-To: <1456519447.91.0.0851895930382.issue26447@psf.upfronthosting.co.za>
Message-ID: <1456519692.97.0.961461040545.issue26447@psf.upfronthosting.co.za>


Ethan Furman added the comment:

https://docs.python.org/3/library/stdtypes.html#str.strip
---------------------------------------------------------
[...] The chars argument is not a prefix or suffix; rather, all combinations of its values are stripped:

----------
nosy: +ethan.furman
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26447>
_______________________________________

From report at bugs.python.org  Fri Feb 26 15:50:28 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 26 Feb 2016 20:50:28 +0000
Subject: [issue26447] rstrip() is pilfering my 'p'
In-Reply-To: <1456519447.91.0.0851895930382.issue26447@psf.upfronthosting.co.za>
Message-ID: <1456519828.92.0.0640592801725.issue26447@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26447>
_______________________________________

From report at bugs.python.org  Fri Feb 26 15:53:24 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Feb 2016 20:53:24 +0000
Subject: [issue26446] Mention in the devguide that core devs are expected to
 follow the PSF CoC
In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za>
Message-ID: <1456520004.27.0.962719334362.issue26446@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26446>
_______________________________________

From report at bugs.python.org  Fri Feb 26 16:46:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 26 Feb 2016 21:46:18 +0000
Subject: [issue24421] Race condition compiling Modules/_math.c
In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za>
Message-ID: <1456523178.07.0.52899023396.issue24421@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24421>
_______________________________________

From report at bugs.python.org  Fri Feb 26 18:45:04 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 26 Feb 2016 23:45:04 +0000
Subject: [issue26434] multiprocessing cannot spawn grandchild from a Windows
 service
In-Reply-To: <1456394207.49.0.123218861266.issue26434@psf.upfronthosting.co.za>
Message-ID: <1456530304.06.0.9345236909.issue26434@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attached is a patch for the 2.7 branch which adds the check described in the previous message.

I don't see a reasonable way to provide an accompanying test because it requires registering a win32 service (requiring administrative privileges) temporarily to attempt to provoke the issue.

Can I request that someone else run the full regression tests on this patch?  I am unable to complete a standard run of tests as my Windows 7 development system is set up for building Python 3.x (newer Visual Studio) and am hesitant to fight with Visual Studio configurations.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42034/issue_26434_fix_win32_service_parent_origin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26434>
_______________________________________

From report at bugs.python.org  Fri Feb 26 18:45:26 2016
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Fri, 26 Feb 2016 23:45:26 +0000
Subject: [issue18199] Windows: support path longer than 260 bytes using "\\?\"
 prefix
In-Reply-To: <1371050681.12.0.381093438517.issue18199@psf.upfronthosting.co.za>
Message-ID: <1456530326.62.0.199355666126.issue18199@psf.upfronthosting.co.za>


Changes by Ugra D?niel <daniel.ugra at gmail.com>:


----------
nosy: +daniel.ugra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18199>
_______________________________________

From report at bugs.python.org  Fri Feb 26 18:48:09 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 26 Feb 2016 23:48:09 +0000
Subject: [issue25340] libraries variable in setup.py ignore for
 multiprocessing module
In-Reply-To: <1444289556.93.0.862916307871.issue25340@psf.upfronthosting.co.za>
Message-ID: <1456530489.38.0.573795771296.issue25340@psf.upfronthosting.co.za>


Davin Potts added the comment:

Closing as the original reporter has not responded to requests for additional information after 4.5 months.

----------
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25340>
_______________________________________

From report at bugs.python.org  Fri Feb 26 20:09:57 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 01:09:57 +0000
Subject: [issue6143] IDLE - an extension to clear the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1456535397.08.0.667201362887.issue6143@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This issue is lower priority to me than many others, but there does seem to be at least some demand shown on Stackoverflow.  So I have not dismissed it completely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6143>
_______________________________________

From report at bugs.python.org  Fri Feb 26 22:54:10 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 27 Feb 2016 03:54:10 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
Message-ID: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>


New submission from Eric Fahlgren:

When trying out dis.dis on some synthetically long functions, I noted that spurious branch targets were being generated in the output.  First one is at address 8:

157           0 LOAD_CONST               1 (1)
              3 DUP_TOP
              4 STORE_FAST               0 (z)
              7 DUP_TOP
        >>    8 STORE_FAST               1 (a)
             11 DUP_TOP

I dug into findlabels and notices that it pays no attention to EXTENDED_ARG.  The fix is pretty simple, basically copy pasta from dis._get_instructions_bytes, at line 369, in the 3.5.1 release code add all the "extended_arg" bits:

    extended_arg = 0
    while i < n:
        op = code[i]
        i = i+1
        if op >= HAVE_ARGUMENT:
            arg = code[i] + code[i+1]*256 + extended_arg
            extended_arg = 0
            i = i+2
            if op == EXTENDED_ARG:
                 extended_arg = arg*65536
            label = -1

----------
components: Library (Lib)
messages: 260913
nosy: eric.fahlgren
priority: normal
severity: normal
status: open
title: dis.findlabels ignores EXTENDED_ARG
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 22:59:31 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Sat, 27 Feb 2016 03:59:31 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456545571.42.0.782056438313.issue26448@psf.upfronthosting.co.za>


Changes by Joe Jevnik <joe at quantopian.com>:


----------
nosy: +llllllllll

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:01:44 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 04:01:44 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456545704.26.0.589988628954.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

I'll take a look at it! :) Would you like unit tests as well?

----------
nosy: +Barun Parruck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:12:30 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 04:12:30 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456546350.48.0.239135709969.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Hi, to check if I've done things right, which functions did you try out dis.dis on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:17:51 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 27 Feb 2016 04:17:51 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456546671.84.0.433368352206.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

My test case:

def long():
    z = a = b = c = d = e = f = g = h = 1
    while x:
        x = x if x and x or not x else x
        above line repeated 2999 more times

import dis
print(dis.findlabels(long.__code__.co_code)[:10])

Buggy output:
[35510, 35509, 62, 69, 78, 81, 93, 100, 109, 112]

Correct output:
[101046, 101045, 62, 69, 78, 81, 93, 100, 109, 112]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:20:31 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 27 Feb 2016 04:20:31 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456546831.23.0.370899425932.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

Our paths crossed, I don't know exactly how you'd add a test case for this, maybe construct the monster function in a string, eval the string, the use the synthesized function in dis.findlabels?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:34:10 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 27 Feb 2016 04:34:10 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456547650.7.0.389919617824.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

Well, now that I'm thinking about it, you could synthesize a bytecode stream trivially and have a much better test.  This is completely off the top of my head, so take it is guaranteed to (probably) not work as written, but it should get you started:

from opcodes import *
import dis
bytecode = (
    chr(EXTENDED_ARG) + chr(1) + chr(0) + 
    chr(JUMP_IF_TRUE_OR_POP) + chr(0) + chr(0)
)
print(dis.findlabels(bytecode))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:34:29 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 04:34:29 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456547669.42.0.619569358452.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Allright, so I'm uploading a preliminary patch, please look through it to see if I understood what you meant me to do about dis.findlabels.

The tests seem to mostly pass, except oddly enough, urlstdlib2, which is probably system-specific?

I get the correct output that you specify for that particular test function.

I'll see about building a unit test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:36:09 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 04:36:09 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456547769.76.0.358942325571.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

The patch I forgot to attach. Ha ha.

----------
keywords: +patch
Added file: http://bugs.python.org/file42035/preliminarypatch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sat Feb 27 00:36:45 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 05:36:45 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456551405.28.0.059018069738.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Hi, I'm a little confused as to how to write a test using bytecode streams...probably due to my lack of clarity as to what exactly dis.disassemble does. Is there any way you could give me a bit more information? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sat Feb 27 00:53:28 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 27 Feb 2016 05:53:28 +0000
Subject: [issue25939] _ssl.enum_certificates() fails with ERROR_ACCESS_DENIED
 if python.exe run with low integrity level
In-Reply-To: <1450989628.26.0.849835515988.issue25939@psf.upfronthosting.co.za>
Message-ID: <1456552408.46.0.635800640381.issue25939@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Didn't see it. Sorry for bothering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25939>
_______________________________________

From report at bugs.python.org  Sat Feb 27 01:11:43 2016
From: report at bugs.python.org (Liang-Bo Wang)
Date: Sat, 27 Feb 2016 06:11:43 +0000
Subject: [issue26246] Code output toggle button uses removed jQuery method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <1456553503.81.0.199798055272.issue26246@psf.upfronthosting.co.za>


Liang-Bo Wang added the comment:

Just FYI, I applied the patch to the zh-hant translation of the documentation and the code output toggle button is back and works as expected.

    https://docs.python.org.tw/3/tutorial/introduction.html#numbers

You can see the result of any other page by changing the URL domain from docs.python.org to docs.python.org.tw

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26246>
_______________________________________

From report at bugs.python.org  Sat Feb 27 01:46:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 27 Feb 2016 06:46:44 +0000
Subject: [issue26246] Code output toggle button uses removed jQuery method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <20160227064641.26003.89235@psf.io>


Roundup Robot added the comment:

New changeset f0e20d942760 by Ezio Melotti in branch '3.4':
#26246: update copybutton.js after JQuery update.  Patch by Liang-Bo Wang.
https://hg.python.org/cpython/rev/f0e20d942760

New changeset ac175a7af60b by Ezio Melotti in branch '3.5':
#26246: merge with 3.4.
https://hg.python.org/cpython/rev/ac175a7af60b

New changeset 8c0761260d22 by Ezio Melotti in branch 'default':
#26246: merge with 3.5.
https://hg.python.org/cpython/rev/8c0761260d22

New changeset 20b5d153b894 by Ezio Melotti in branch '2.7':
#26246: update copybutton.js after JQuery update.  Patch by Liang-Bo Wang.
https://hg.python.org/cpython/rev/20b5d153b894

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26246>
_______________________________________

From report at bugs.python.org  Sat Feb 27 01:48:44 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 27 Feb 2016 06:48:44 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456551405.28.0.059018069738.issue26448@psf.upfronthosting.co.za>
Message-ID: <CAP2Qz+XuKG0KqUMmpQJOtQ-xaJf8JjwSXTLDA4dbK-BRHu82gw@mail.gmail.com>


Eric Fahlgren added the comment:

The findlabels function takes a bytecode array of type bytes, usually the
actual code from a function.  My original test case uses the full Python
compiler from source code to a CodeType object to create the bytecodes
(plus all that other stuff that makes up a function), then extracts just
the interesting part and passes that into findlabels.

The good part is that you can pretend you're the compiler by just putting
the correct bytes into a array and feed it into the various dis functions.
The EXTENDED_ARG operator plays with the operand of the succeeding
instruction, everything else either doesn't have an argument or has two
bytes.

Here's a real test case, I don't know how you write unit tests for the
stdlib, but you can compare the output of the findlabels call with a known
value, and that should get you pretty close.

from opcode import *
code = bytes(
    chr(opmap["JUMP_FORWARD"]) + chr(0) + chr(0) +
    chr(EXTENDED_ARG) + chr(1) + chr(0) +
    chr(opmap["JUMP_FORWARD"]) + chr(0) + chr(0) +
    chr(opmap["RETURN_VALUE"]),
    encoding="latin-1"
)
import dis
dis.dis(code)
print(dis.findlabels(code))
if dis.findlabels(code) == [0x0000+3, 0x00010000+9]:
    print("Test passed")

Take a look in the stdlib opcode.py and find the various "JUMP" operators,
those are the guys we care about for this.  Try out a bunch of cases by
augmenting the above definition of "code" and you'll soon get a feel for
what's going on.

As real, executable bytecode the above is of course non-sensical, but for a
test, it's great because you can predict exactly what should be produced.
?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sat Feb 27 01:51:36 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Feb 2016 06:51:36 +0000
Subject: [issue26246] Code output toggle button uses removed jQuery method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <1456555896.33.0.840699999906.issue26246@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I applied the patch -- it should go live the next time the docs are updated.  Thanks for the report and the patch!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26246>
_______________________________________

From report at bugs.python.org  Sat Feb 27 02:33:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Feb 2016 07:33:15 +0000
Subject: [issue26421] string_richcompare invalid check Py_NotImplemented
In-Reply-To: <1456238998.85.0.782373518975.issue26421@psf.upfronthosting.co.za>
Message-ID: <1456558395.59.0.0687841850452.issue26421@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyDict_GetItem and lookdict_string use PyString_CheckExact for fast path. String subclasses are proceeded in general way. PyObject_GetAttr and string_richcompare use PyString_Check because they work with string and string subclasses. Py_TPFLAGS_STRING_SUBCLASS shouldn't be used if the type is not string subclass.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26421>
_______________________________________

From report at bugs.python.org  Sat Feb 27 02:33:41 2016
From: report at bugs.python.org (Liang-Bo Wang)
Date: Sat, 27 Feb 2016 07:33:41 +0000
Subject: [issue26246] Code output toggle button uses removed jQuery method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <1456558421.18.0.890703678637.issue26246@psf.upfronthosting.co.za>


Liang-Bo Wang added the comment:

Thanks for the merge. 

I pulled the change and checked the result, but I found the patch missing a line to initiate the correct display state when the button was created. That is, it forgot to set `button.data('hidden', 'false');` when adding the button. 

This causes the first click on the button to have no effect. But the following clicks will work.

I filed the new patch to add this line back. I'm so sorry I missed this line :(

----------
Added file: http://bugs.python.org/file42036/copybutton_js_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26246>
_______________________________________

From report at bugs.python.org  Sat Feb 27 02:44:58 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 07:44:58 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456559098.35.0.947948693075.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Hi, yes, that works much better, and I've definitely understood!

Now, about the tests, how large would you like them to be? For instance :

code = bytes (
	chr(opmap["JUMP_FORWARD"]) + chr(0) + chr(255) + 
	chr(EXTENDED_ARG) + chr(1) + chr(1) + 
	chr(opmap["JUMP_FORWARD"]) + chr(0) + chr(0) +
	chr(EXTENDED_ARG) + chr(1) + chr(0) +
	chr(opmap["JUMP_ABSOLUTE"]) + chr(0) + chr(1) +
	chr(opmap["RETURN_VALUE"]),
	encoding="latin-1"
	)

Would return [65283, 16842761, 65792]

And I'll make sure I test all the jump instances (I'm shuddering to imagine what a real computer would do if fed with those byte codes)

Do you want the tests to be large? (array size > 10^2/2 as a result), or is the example above fine, if I add three or four more example testing each jump instance?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sat Feb 27 03:00:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Feb 2016 08:00:59 +0000
Subject: [issue26415] Out of memory, trying to parse a 35MB dict
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1456560059.51.0.944843620302.issue26415@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I though this might be tokenizer issue, but this is just large memory consumption for AST tree. Simpler example:

./python -c 'import ast; ast.parse("0,"*1000000, mode="eval")'

It takes over 450MB of memory on 32-bit system, over 450 bytes per tuple item. Increase the multiplier to 10000000 leads to swapping and failing with MemoryError.

Of course it would be nice to decrease memory consumption, but this looks rather as new feature.

----------
assignee: serhiy.storchaka -> 
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Sat Feb 27 03:18:27 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 08:18:27 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456561107.56.0.961929194118.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Four test cases have been included in the unittests, using the module unittest. One is the original one you gave me, the others are some that I played around with it, and thought would be useful to include.

I would love some code reviews at this point!

----------
Added file: http://bugs.python.org/file42037/testfindlabels.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sat Feb 27 03:40:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Feb 2016 08:40:27 +0000
Subject: [issue26436] Add the regex-dna benchmark
In-Reply-To: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>
Message-ID: <1456562427.61.0.900748325219.issue26436@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I assume the code looks idiomatic to you?

Sorry, I have not understood your question. Could you please reformulate?

The performance of all Python versions is rough the same. 2.7 is about 8% slower than 3.2 and 3.3, 3.4-default are about 3-4% slower than 3.2 and 3.3.

I have taken input data size such that the regex-dna benchmark runs rough the same time as the slowest regex benchmark regex-compile (0.7 sec per iteration on my computer, about a minute with default options). This is 1/50 of the size used in The Computer Language Benchmarks Game.

Since the benchmark generates input data, its size can easily be changed. Needed only update control sums.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Sat Feb 27 04:15:41 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 27 Feb 2016 09:15:41 +0000
Subject: [issue26449] Tutorial on Python Scopes and Namespaces uses confusing
 'read-only' terminology
Message-ID: <1456564541.09.0.218031979167.issue26449@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

>From the 9.2. Python Scopes and Namespace section:

> If a name is declared global, then all references and assignments go directly to the middle scope containing the module?s global names. To rebind variables found outside of the innermost scope, the nonlocal statement can be used; if not declared nonlocal, those variable are read-only (an attempt to write to such a variable will simply create a new local variable in the innermost scope, leaving the identically named outer variable unchanged).

This terminology is extremely confusing to newcomers; see https://stackoverflow.com/questions/35667757/read-only-namespace-in-python for an example. Variables are never read-only. The parent scope name simply is *not visible*, which is an entirely different concept. Can this section be re-written to not use the term 'read-only'?

----------
messages: 260933
nosy: mjpieters
priority: normal
severity: normal
status: open
title: Tutorial on Python Scopes and Namespaces uses confusing 'read-only' terminology

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26449>
_______________________________________

From report at bugs.python.org  Sat Feb 27 04:15:56 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 27 Feb 2016 09:15:56 +0000
Subject: [issue26449] Tutorial on Python Scopes and Namespaces uses confusing
 'read-only' terminology
In-Reply-To: <1456564541.09.0.218031979167.issue26449@psf.upfronthosting.co.za>
Message-ID: <1456564556.63.0.319157604854.issue26449@psf.upfronthosting.co.za>


Changes by Martijn Pieters <mj at python.org>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26449>
_______________________________________

From report at bugs.python.org  Sat Feb 27 04:25:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 09:25:59 +0000
Subject: [issue26393] random.shuffled
In-Reply-To: <1455910341.76.0.914915111625.issue26393@psf.upfronthosting.co.za>
Message-ID: <1456565159.44.0.71338417218.issue26393@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It is against our policy to wrap random half-line expressions as new function.  Doing so would bloat Python until it became unusable.  This should be rejected.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26393>
_______________________________________

From report at bugs.python.org  Sat Feb 27 04:27:41 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 09:27:41 +0000
Subject: [issue26394] Have argparse provide ability to require a fallback
 value be present
In-Reply-To: <1455985031.95.0.488150837583.issue26394@psf.upfronthosting.co.za>
Message-ID: <1456565261.42.0.630411310608.issue26394@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26394>
_______________________________________

From report at bugs.python.org  Sat Feb 27 04:37:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 09:37:39 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456565859.13.0.371464062829.issue26404@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This seems like an appropriate enhancement.  I notice that the serve_forever examples did not previously have server_close().  Was this an oversight or will the server_close in __exit__ just be a no-op?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Sat Feb 27 04:52:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 09:52:50 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
In-Reply-To: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>
Message-ID: <1456566770.12.0.562285934547.issue26407@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The TypeError is correct.  You passed a non-iterable.  I agree that adding information, *if possible*, when 'non-iterable' is determined by an exception being raised, would be nice.  I don't know how easy this would be.

----------
nosy: +terry.reedy
stage:  -> test needed
type: behavior -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:05:25 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 10:05:25 +0000
Subject: [issue26420] IDLE for Python 3.5.1 for x64 Windows exits when pasted
 a string with non-BMP characters
In-Reply-To: <1456237474.93.0.941468320226.issue26420@psf.upfronthosting.co.za>
Message-ID: <1456567525.88.0.699785103529.issue26420@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If you start IDLE from the console with 'python -m idlelib' you should see a TclError message when pasting.  This is a known limitation of tcl/tk.  Printing gives a traceback in IDLE's shell.
>>> print('\U00020BB7')
Traceback (most recent call last):
  File "<pyshell#26>", line 1, in <module>
    print('\U00020BB7')
  File "C:\Programs\Python35\lib\idlelib\PyShell.py", line 1344, in write
    return self.shell.write(s, self.tags)
UnicodeEncodeError: 'UCS-2' codec can't encode character '\U00020bb7' in position 0: Non-BMP character not supported in Tk

----------
nosy: +terry.reedy
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE crashes when pasting non-BMP unicode char on Py3
title: IDEL for Python 3.5.1 for x64 Windows exits when pasted a string with non-BMP characters -> IDLE for Python 3.5.1 for x64 Windows exits when pasted a string with non-BMP characters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26420>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:24:07 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 10:24:07 +0000
Subject: [issue26436] Add the regex-dna benchmark
In-Reply-To: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>
Message-ID: <1456568647.39.0.318372954901.issue26436@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I believe Brett is asking whether the code looks like the sort of Python code that one of us might write, as opposed to 'language X in Python'.  In my quick perusal, As far as I looked, I would say yes, except for using floats and while instead of int and for because the former are supposedly faster.  (See the loop in the middle of random_fasta.)  So do we want a benchmark micro-optimized for CSF's system or written 'normally' (with for, int, and range). I did not notice any PEP 8 style violations.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:26:50 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sat, 27 Feb 2016 10:26:50 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456568810.96.0.0196147568602.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Sorry, the previous file had a bug.

----------
Added file: http://bugs.python.org/file42038/testfindlabels2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:27:23 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 10:27:23 +0000
Subject: [issue26442] Doc refers to xmlrpc.client but means xmlrpc.server
In-Reply-To: <1456486299.23.0.764792855205.issue26442@psf.upfronthosting.co.za>
Message-ID: <1456568843.96.0.0909500771058.issue26442@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26442>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:33:01 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 27 Feb 2016 10:33:01 +0000
Subject: [issue26283] zipfile can not handle the path build by os.path.join()
In-Reply-To: <1454552368.89.0.734714115407.issue26283@psf.upfronthosting.co.za>
Message-ID: <1456569181.03.0.116062001914.issue26283@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy:  -anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26283>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:33:42 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 27 Feb 2016 10:33:42 +0000
Subject: [issue26269] zipfile should call lstat instead of stat if available
In-Reply-To: <1454449498.64.0.544045383692.issue26269@psf.upfronthosting.co.za>
Message-ID: <1456569222.14.0.978960377135.issue26269@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy:  -anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26269>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:35:39 2016
From: report at bugs.python.org (Anish Shah)
Date: Sat, 27 Feb 2016 10:35:39 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1456569339.6.0.384502690217.issue26252@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy:  -anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26252>
_______________________________________

From report at bugs.python.org  Sat Feb 27 09:02:38 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 27 Feb 2016 14:02:38 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456581758.89.0.193658013835.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

Lookin' good so far.  How about we try it on all the opcodes that have arguments?

See attached example for which I can see two obvious improvements:
1) It could be improved by taking apart that "args" list and using it to synthesize "sample_code" rather than having to hand duplicate the values in two places, albeit with different byte order.
2) Likewise, my hard-coded "offsets" table is pretty awful. :)

Also, is there already a test for the dis module in which you could just add this as a case?

----------
Added file: http://bugs.python.org/file42039/testfindlabels.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sat Feb 27 09:57:38 2016
From: report at bugs.python.org (yota moteuchi)
Date: Sat, 27 Feb 2016 14:57:38 +0000
Subject: [issue24663] ast.literal_eval does not handle empty set literals
In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za>
Message-ID: <1456585058.14.0.0580076261254.issue24663@psf.upfronthosting.co.za>


yota moteuchi added the comment:

Well, I would disagree with R. David Murray on this.

literal_eval() is meant to safely parse literal pythons "containers" structures.

{1, 2, 3} is a valid literal set(), why would an empty one not be parse-able as well. I can not predict, when I dump the structure with repr(), if the set() will be empty or not.

----------
nosy: +yota moteuchi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24663>
_______________________________________

From report at bugs.python.org  Sat Feb 27 11:48:45 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 27 Feb 2016 16:48:45 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1456591725.06.0.443088988276.issue26359@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
nosy: +brett.cannon, gregory.p.smith, lemburg, pitrou, r.david.murray, scoder, skrah, steve.dower, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Sat Feb 27 11:50:58 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 27 Feb 2016 16:50:58 +0000
Subject: [issue26285] Garbage collection of unused input sections from CPython
 binaries
In-Reply-To: <1454601388.85.0.405033419332.issue26285@psf.upfronthosting.co.za>
Message-ID: <1456591858.01.0.73595633716.issue26285@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
nosy: +gregory.p.smith, lemburg, scoder, steve.dower, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26285>
_______________________________________

From report at bugs.python.org  Sat Feb 27 11:54:01 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 27 Feb 2016 16:54:01 +0000
Subject: [issue26436] Add the regex-dna benchmark
In-Reply-To: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>
Message-ID: <1456592041.94.0.572986049309.issue26436@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Terry's right about what I meant; is the code of such quality that you would let it into the stdlib?

As for execution time, I would vote for increasing the input size to take 1 second as it's just going to get faster and faster just  from CPU improvements alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Sat Feb 27 11:57:22 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Feb 2016 16:57:22 +0000
Subject: [issue26436] Add the regex-dna benchmark
In-Reply-To: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>
Message-ID: <1456592242.92.0.453701380385.issue26436@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would add another kind of question: is it stressing something useful that isn't already stressed by the two other regex benchmarks we already have?

Given that it seems built around a highly-specialized use case (DNA matching?) and we don't even know if regular expressions are actually the tool of choice in the field (unless someone here is a specialist), I'm rather skeptical.

(in general, everything coming the "Computer Language Benchmarks Game" should be taken with a grain of salt IMHO: it's mostly people wanting to play writing toy programs)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Sat Feb 27 14:56:07 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Feb 2016 19:56:07 +0000
Subject: [issue26393] random.shuffled
In-Reply-To: <1455910341.76.0.914915111625.issue26393@psf.upfronthosting.co.za>
Message-ID: <1456602967.78.0.357493855288.issue26393@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I concur with Terry.

----------
assignee:  -> rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26393>
_______________________________________

From report at bugs.python.org  Sat Feb 27 15:17:16 2016
From: report at bugs.python.org (Aivar Annamaa)
Date: Sat, 27 Feb 2016 20:17:16 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.6 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1456604236.44.0.160470686148.issue15663@psf.upfronthosting.co.za>


Aivar Annamaa added the comment:

install_name_tool can specify relative paths (see eg. https://wincent.com/wiki/@executable_path,_ at load_path_and_@rpath). Therefore you don't need it in users' systems.

I've used it successfully for bundling Python 3.5 and Tk 8.6 with my IDE, see https://bitbucket.org/plas/thonny/src/master/packaging
/mac/build_requirements_old.sh and https://bitbucket.org/plas/thonny/src/master/packaging/mac/update_links.sh

----------
nosy: +Aivar.Annamaa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15663>
_______________________________________

From report at bugs.python.org  Sat Feb 27 15:20:32 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Feb 2016 20:20:32 +0000
Subject: [issue26449] Tutorial on Python Scopes and Namespaces uses confusing
 'read-only' terminology
In-Reply-To: <1456564541.09.0.218031979167.issue26449@psf.upfronthosting.co.za>
Message-ID: <1456604432.22.0.809272574194.issue26449@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, the learners in my Python classes seem to find the words "read-only" to be helpful.  Also, I think "not visible" conveys the wrong mental model ("shadowed" being a little more accurate).  

I also disagree with saying that "variables are never read-only". In fact, unless declared "nonlocal", the namespace for the nested scope can't be written to; likewise, we also have dict proxies in classes that are specifically designed to be read-only; further, there are many read-only attributes in Python.

The current paragraph is succinct and accurate.   That said, there is no doubt that creative people can find ways to misread it, so I think  there is room to add an extra paragraph that elaborates on the rules:

1) variable *lookups* will search from locals to nested scopes to globals to builtins, stopping at the first match or raising NameError if not found; and, 

2) variable *writes* always go into locals unless explicitly declared as being in another namespace with "nonlocal" or "global".

The docs can't smooth this over by changing a single misinterpreted word.  One way or another, either in the tutorial or in a FAQ, users need to learn why x=1 doesn't write to an enclosing scope without a namespace declaration and why self.x+=1 can read a class variable, increment the value, and then write to an instance variable.  Learning this is fundamental to understanding the language and it can't be glossed over by saying that the word "read-only" was confusing.  Everyone gets what "read-only" means; instead, the challenge is to grapple with what the rules are and why the language behaves this way.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26449>
_______________________________________

From report at bugs.python.org  Sat Feb 27 16:35:59 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Feb 2016 21:35:59 +0000
Subject: [issue26449] Tutorial on Python Scopes and Namespaces uses confusing
 'read-only' terminology
In-Reply-To: <1456564541.09.0.218031979167.issue26449@psf.upfronthosting.co.za>
Message-ID: <1456608959.85.0.0935399830809.issue26449@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I agree with Raymond.  IMHO the term "read-only" does a good job at conveying the fact that you can still access/read the value of the variable but you can't assign to it.  "read-only" is about /what/ you can do with the variable, even though it would also be good to clarify /why/ you can only read.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26449>
_______________________________________

From report at bugs.python.org  Sat Feb 27 17:43:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 27 Feb 2016 22:43:41 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1456613021.63.0.446661519149.issue21042@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks, this looks pretty good to me. I just need to remember to write a What?s New entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Sat Feb 27 18:03:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 27 Feb 2016 23:03:17 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1456614197.76.0.576313555845.issue25910@psf.upfronthosting.co.za>


Martin Panter added the comment:

BTW it looks like the suspicious.csv file needs updating to compensate for this change:

http://buildbot.python.org/all/builders/Docs%203.5/builds/654/steps/suspicious/logs/stdio

WARNING: [using/unix:31] ":Packaging" found in "https://en.opensuse.org/Portal:Packaging"
WARNING: Found 1/297 unused rules:
using/unix,,:Packaging,http://en.opensuse.org/Portal:Packaging

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Feb 27 18:10:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Feb 2016 23:10:06 +0000
Subject: [issue26436] Add the regex-dna benchmark
In-Reply-To: <1456402657.17.0.694301948635.issue26436@psf.upfronthosting.co.za>
Message-ID: <1456614606.17.0.631973936078.issue26436@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

DNA matching can be done with difflib.  Serious high-volume work should use compiled specialized matchers and aligners.

This particular benchmark, explained a bit at https://benchmarksgame.alioth.debian.org/u64q/regexdna-description.html#regexdna, manipulates and searches standard FASTA format representations of sequences with the regex available in each language.  (The site has another Python implementation at https://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=python3&id=1. It uses unicode strings rather than bytes, and multiprocessing.Pool to run re.findall in parallel.)

FASTA uses lowercase a,c,g,t for known bases and at least 11 uppercase letters for subsets of bases representing partially known bases.  The third task is to expand upper case letters to subsets of lowercase letters.  Since the rules requires use of re and one substitution at a time, the 2 Python programs run re.sub over the current sequence 11 times.  More idiomatic for Python, and probably faster, would be to use seq.replace(old,new) instead.  Perhaps even more idiomatic and probably faster still, would be to use str.translate, as in this reduced example.

>>> table = {ord('B') : '(c|g|t)', ord('D') : '(a|g|t)'}
>>> 'aBcDg'.translate(table)
'a(c|g|t)c(a|g|t)g'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26436>
_______________________________________

From report at bugs.python.org  Sat Feb 27 19:21:57 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 28 Feb 2016 00:21:57 +0000
Subject: [issue21042] ctypes.util.find_library() should return full pathname
 instead of filename in linux
In-Reply-To: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>
Message-ID: <1456618917.24.0.523836987722.issue21042@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I don't think we need an entry in whatsnew/3.6.rst for this (we already have documented the change in a versionchanged directive and a Misc/NEWS item)

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21042>
_______________________________________

From report at bugs.python.org  Sat Feb 27 20:15:52 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Feb 2016 01:15:52 +0000
Subject: [issue25488] IDLE: Remove '', user_dir,
 and idlelib from sys.path when added
In-Reply-To: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za>
Message-ID: <1456622152.38.0.0769017745139.issue25488@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#25507 addresses the tkinter.font problem of Note 2 in the first message.

----------
title: IDLE: Remove '' and idlelib from sys.path when added -> IDLE: Remove '', user_dir, and idlelib from sys.path when added
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25488>
_______________________________________

From report at bugs.python.org  Sat Feb 27 20:19:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Feb 2016 01:19:43 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <20160228011932.30274.13058@psf.io>


Roundup Robot added the comment:

New changeset fca9f02e10e5 by Martin Panter in branch '2.7':
Issue #22836: Keep exception reports sensible despite errors
https://hg.python.org/cpython/rev/fca9f02e10e5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Sat Feb 27 21:31:06 2016
From: report at bugs.python.org (Alex LordThorsen)
Date: Sun, 28 Feb 2016 02:31:06 +0000
Subject: [issue26450] make html fails on OSX
Message-ID: <1456626666.41.0.889799405397.issue26450@psf.upfronthosting.co.za>


New submission from Alex LordThorsen:

Did a fresh hg clone of the python 3.6 code base (3.6.0a0) on  OSX 10.10.5 and made a modification to a library rst. I went to build my changes and ran

$ make html
sphinx-build -b html -d build/doctrees -D latex_paper_size=  . build/html
make: sphinx-build: No such file or directory
make: *** [build] Error 1

I looked at https://docs.python.org/devguide/documenting.html#building-doc to see about what I can do about this failure and didn't see anything OSX specific. 

$ sphinx-build -b html . build/html

Works, however.

----------
components: Build
messages: 260954
nosy: Alex.Lord
priority: normal
severity: normal
status: open
title: make html fails on OSX
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26450>
_______________________________________

From report at bugs.python.org  Sat Feb 27 21:50:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 28 Feb 2016 02:50:46 +0000
Subject: [issue26450] make html fails on OSX
In-Reply-To: <1456626666.41.0.889799405397.issue26450@psf.upfronthosting.co.za>
Message-ID: <1456627846.99.0.131836454057.issue26450@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect this is not OS X specific. The documentation that you linked says ?Sphinx is maintained separately and is not included in this tree.?

By your output I suspect you need to install the sphinx-build program. On Arch Linux I had to install it myself:

$ pacman -Qo sphinx-build
/usr/bin/sphinx-build is owned by python-sphinx 1.3.4-1
$ pacman -Qi python-sphinx
Name           : python-sphinx
Version        : 1.3.4-1
Description    : Python3 documentation generator
Architecture   : any
URL            : http://sphinx.pocoo.org/

----------
nosy: +martin.panter
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26450>
_______________________________________

From report at bugs.python.org  Sat Feb 27 21:52:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 28 Feb 2016 02:52:26 +0000
Subject: [issue26450] make html fails on OSX
In-Reply-To: <1456626666.41.0.889799405397.issue26450@psf.upfronthosting.co.za>
Message-ID: <1456627946.48.0.84577408397.issue26450@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry I didn?t read the last bit of your message where you run sphinx-build manually. So I take back my last comment :)

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26450>
_______________________________________

From report at bugs.python.org  Sat Feb 27 21:58:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 28 Feb 2016 02:58:54 +0000
Subject: [issue26450] make html fails on OSX
In-Reply-To: <1456626666.41.0.889799405397.issue26450@psf.upfronthosting.co.za>
Message-ID: <1456628334.67.0.0703414049655.issue26450@psf.upfronthosting.co.za>


Martin Panter added the comment:

The only thing I can think of is checking the PATH environment variable. What is it inside the Makefile, and what is it when you run the command manually?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26450>
_______________________________________

From report at bugs.python.org  Sat Feb 27 22:05:49 2016
From: report at bugs.python.org (Alex LordThorsen)
Date: Sun, 28 Feb 2016 03:05:49 +0000
Subject: [issue26450] make html fails on OSX
In-Reply-To: <1456626666.41.0.889799405397.issue26450@psf.upfronthosting.co.za>
Message-ID: <1456628749.78.0.451626691108.issue26450@psf.upfronthosting.co.za>


Alex LordThorsen added the comment:

So I think this is really a documentation bug after playing with this a little bit. I built a virtual env and pip installed sphinx. If I'm in the virtual environment the build succeeds and out of it fails.

The documentation states that you need sphinx (in a different section) but doesn't have a step that explicitly tells you to install it.

Do devguide issues go on this bug tracker?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26450>
_______________________________________

From report at bugs.python.org  Sat Feb 27 22:13:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 28 Feb 2016 03:13:04 +0000
Subject: [issue26450] make html fails on OSX
In-Reply-To: <1456626666.41.0.889799405397.issue26450@psf.upfronthosting.co.za>
Message-ID: <1456629184.2.0.882896776847.issue26450@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yeah if you want to propose a specific change for the devguide, or even a patch, go right ahead :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26450>
_______________________________________

From report at bugs.python.org  Sat Feb 27 22:18:04 2016
From: report at bugs.python.org (Alex LordThorsen)
Date: Sun, 28 Feb 2016 03:18:04 +0000
Subject: [issue26451] CSV documentation doesn't open with an example
Message-ID: <1456629484.08.0.443868302354.issue26451@psf.upfronthosting.co.za>


New submission from Alex LordThorsen:

Had a friend get stuck on the CSV documentation. They didn't know what a CSV was (to start with) and couldn't find an example that made sense to them.  they went to other sources to figure out how to read CSV files in the end.

I made this patch in the hope that starting out with a very minimal example file format followed by an example python read will make landing on the CSV docs easier to follow for new programmers.

----------
assignee: docs at python
components: Documentation
files: csv_documentation.patch
keywords: patch
messages: 260960
nosy: Alex.LordThorsen, docs at python
priority: normal
severity: normal
status: open
title: CSV documentation doesn't open with an example
versions: Python 3.6
Added file: http://bugs.python.org/file42040/csv_documentation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26451>
_______________________________________

From report at bugs.python.org  Sat Feb 27 22:18:34 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Feb 2016 03:18:34 +0000
Subject: [issue25488] IDLE: Remove '', user_dir,
 and idlelib from sys.path when added
In-Reply-To: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za>
Message-ID: <1456629514.16.0.704295722008.issue25488@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In private email, eryk sun reports  "/usr/bin/idle3 instead prepends 3 directories: ['', current_directory_absolute, '/usr/bin']. If I use the -r option to run a script, it instead prepends script_directory_relative, '', '/usr/bin']. I think these should be [''] and [script_directory_absolute], respectively."

Windows does not have idle3.  None of the directories above are needed to run IDLE and I believe any could contain masking files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25488>
_______________________________________

From report at bugs.python.org  Sat Feb 27 22:25:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Feb 2016 03:25:26 +0000
Subject: [issue25488] IDLE: Remove '', user_dir,
 and idlelib from sys.path when added
In-Reply-To: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za>
Message-ID: <1456629926.31.0.491811228466.issue25488@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Upload: A listing of console (cross-platform) and icon (Windows-specific) IDLE starting methods and the effect on sys.path and current directory.  I believe that some of the details of the 'constant' part of sys.path are system dependent, but stable across methods for a particular python version.

----------
Added file: http://bugs.python.org/file42041/idle-start.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25488>
_______________________________________

From report at bugs.python.org  Sat Feb 27 22:45:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Feb 2016 03:45:04 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <20160228034501.30282.15486@psf.io>


Roundup Robot added the comment:

New changeset cf70b1204e44 by Martin Panter in branch '3.5':
Issue #22836: Keep exception reports sensible despite errors
https://hg.python.org/cpython/rev/cf70b1204e44

New changeset 2b597e03f7f4 by Martin Panter in branch 'default':
Issue #22836: Merge exception reporting from 3.5
https://hg.python.org/cpython/rev/2b597e03f7f4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Sat Feb 27 23:17:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 28 Feb 2016 04:17:57 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1456633077.43.0.473105352882.issue22836@psf.upfronthosting.co.za>


Martin Panter added the comment:

FTR Python 2?s exception report in __del__() is a bit different, here is what it now looks like:

>>> o = VeryBroken()
>>> del o
Exception __main__.BrokenStrException: <exception repr() failed> in <object repr() failed> ignored

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Sat Feb 27 23:18:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 28 Feb 2016 04:18:54 +0000
Subject: [issue6294] Improve shutdown exception ignored message
In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>
Message-ID: <1456633134.17.0.0909965123733.issue6294@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Broken "Exception ignored in:" message on exceptions in __repr__
versions: +Python 3.5, Python 3.6 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6294>
_______________________________________

From report at bugs.python.org  Sun Feb 28 00:00:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 28 Feb 2016 05:00:24 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <1456635624.25.0.475295279313.issue13573@psf.upfronthosting.co.za>


Berker Peksag added the comment:

csv.writer() documentation says:

    "All other non-string data are stringified with str() before being written."

https://docs.python.org/2.7/library/csv.html#csv.writer

I guess adding a sentence to document the special case for floats wouldn't hurt.

----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sun Feb 28 00:13:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 28 Feb 2016 05:13:01 +0000
Subject: [issue23041] csv needs more quoting rules
In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za>
Message-ID: <1456636381.52.0.907234296601.issue23041@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23041>
_______________________________________

From report at bugs.python.org  Sun Feb 28 01:15:50 2016
From: report at bugs.python.org (Greg Price)
Date: Sun, 28 Feb 2016 06:15:50 +0000
Subject: [issue26452] Wrong line number attributed to comprehension expressions
Message-ID: <1456640149.75.0.85936592027.issue26452@psf.upfronthosting.co.za>


New submission from Greg Price:

In a multi-line list comprehension (or dict or set comprehension), the code for the main expression of the comprehension is wrongly attributed to the *last* line of the comprehension, which might be several lines later.

This makes for quite baffling tracebacks when an exception occurs -- for example this program:
```
def f():
    return [j
            for i in range(3)
            if i]

f()
```
produces (with CPython from current `default`):
```
Traceback (most recent call last):
  File "foo.py", line 15, in <module>
    f()
  File "foo.py", line 3, in f
    for i in range(3)
  File "foo.py", line 4, in <listcomp>
    if i]
NameError: name 'j' is not defined
```
showing the line `if i]`, which has nothing to do with the error and gives very little hint as to where the exception is being raised.

Disassembly confirms that the line numbers on the code object are wrong:
```
  2           0 BUILD_LIST               0
              3 LOAD_FAST                0 (.0)
        >>    6 FOR_ITER                18 (to 27)

  3           9 STORE_FAST               1 (i)

  4          12 LOAD_FAST                1 (i)
             15 POP_JUMP_IF_FALSE        6
             18 LOAD_GLOBAL              0 (j)
             21 LIST_APPEND              2
             24 JUMP_ABSOLUTE            6
        >>   27 RETURN_VALUE
```
The `LOAD_GLOBAL` instruction for `j` is attributed to line 4, when it should be line 2.

A similar issue affects multi-line function calls, which get attributed to a line in the last argument.  This is less often so seriously confusing because the function called is right there as the next frame down on the stack, but it's much more common and it makes the traceback look a little off -- I've noticed this as a minor annoyance for years, before the more serious comprehension issue got my attention.

Historically, line numbers were constrained to be wrong in these ways because the line-number table `co_lnotab` on a code object required its line numbers to increase monotonically -- and the code for the main expression of a comprehension comes after all the `for` and `if` clauses, so it can't get a line number earlier than theirs.  Victor Stinner's recent work in https://hg.python.org/cpython/rev/775b74e0e103 lifted that restriction in the `co_lnotab` data structure, so it's now just a matter of actually entering the correct line numbers there.

I have a draft patch to do this, attached here.  It fixes the issue both for comprehensions and function calls, and includes tests.  Things I'd still like to do before considering the patch ready:
* There are a couple of bits of logic that I knock out that can probably be simplified further.
* While I'm looking at this, there are several other forms of expression and statement that have or probably have similar issues, and I'll want to go and review them too to either fix or determine that they're fine.  The ones I've thought of are included in the draft test file, either as actual tests (with their current answers) or TODO comments for me to investigate.

Comments very welcome on the issue and my draft patch, and meanwhile I'll continue with the further steps mentioned above.

Thanks to Benjamin Peterson for helping diagnose this issue with me when we ran into a confusing traceback that ran through a comprehension.

----------
components: Interpreter Core
files: lines.diff
keywords: patch
messages: 260966
nosy: Greg Price
priority: normal
severity: normal
status: open
title: Wrong line number attributed to comprehension expressions
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42042/lines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26452>
_______________________________________

From report at bugs.python.org  Sun Feb 28 01:28:53 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Feb 2016 06:28:53 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456640933.12.0.445789606268.issue26439@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Sun Feb 28 01:29:45 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Feb 2016 06:29:45 +0000
Subject: [issue26440] tarfile._FileInFile.seekable is broken in stream mode
In-Reply-To: <1456418959.65.0.0948342534374.issue26440@psf.upfronthosting.co.za>
Message-ID: <1456640985.17.0.635361158017.issue26440@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26440>
_______________________________________

From report at bugs.python.org  Sun Feb 28 01:33:19 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Feb 2016 06:33:19 +0000
Subject: [issue26443] cross building extensions picks up host headers
In-Reply-To: <1456499973.95.0.823052816124.issue26443@psf.upfronthosting.co.za>
Message-ID: <1456641199.56.0.735599131715.issue26443@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26443>
_______________________________________

From report at bugs.python.org  Sun Feb 28 01:36:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Feb 2016 06:36:30 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456641390.97.0.381189229341.issue26448@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +ncoghlan, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sun Feb 28 02:16:59 2016
From: report at bugs.python.org (Antony Lee)
Date: Sun, 28 Feb 2016 07:16:59 +0000
Subject: [issue26453] SystemError on invalid numpy.ndarray / Path operation
Message-ID: <1456643819.34.0.521319001507.issue26453@psf.upfronthosting.co.za>


New submission from Antony Lee:

Running
```
from pathlib import Path
import numpy as np
np.arange(300000) / Path("foo")
```
raises
```
TypeError: argument should be a path or str object, not <class 'int'>

During handling of the above exception, another exception occurred:

SystemError: <built-in method __new__ of type object at 0x7fb4df227fc0> returned a result with an error set

<elided: many repeats of the same>

During handling of the above exception, another exception occurred:

SystemError: <built-in method __new__ of type object at 0x7fb4df227fc0> returned a result with an error set

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/foo.py", line 3, in <module>
    np.arange(300000) / Path("foo")
  File "/usr/lib/python3.5/pathlib.py", line 879, in __rtruediv__
    return self._from_parts([key] + self._parts)
  File "/usr/lib/python3.5/pathlib.py", line 637, in _from_parts
    self = object.__new__(cls)
SystemError: <built-in method __new__ of type object at 0x7fb4df227fc0> returned a result with an error set
```
Note that this does NOT appear for small arrays; I haven't determined the threshold.
Crossposted as https://github.com/numpy/numpy/issues/7360.

----------
components: Interpreter Core
messages: 260967
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: SystemError on invalid numpy.ndarray / Path operation
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26453>
_______________________________________

From report at bugs.python.org  Sun Feb 28 02:35:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Feb 2016 07:35:04 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <20160228073501.30278.88777@psf.io>


Roundup Robot added the comment:

New changeset d3ac0214b7b8 by Raymond Hettinger in branch '2.7':
Issue 13573: Document that csv.writer uses str() for floats instead of repr().
https://hg.python.org/cpython/rev/d3ac0214b7b8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sun Feb 28 02:35:20 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Feb 2016 07:35:20 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <1456644920.77.0.419323691354.issue13573@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sun Feb 28 02:42:56 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 28 Feb 2016 07:42:56 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1456645376.8.0.45473290284.issue25910@psf.upfronthosting.co.za>


SilentGhost added the comment:

Perhaps, I'm misreading the log output, but it seems to me that it's Doc/tools/susp-ignored.csv that needs updating. Here is the attached patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sun Feb 28 03:54:33 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 28 Feb 2016 08:54:33 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <1456649673.92.0.241437616685.issue13573@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: needs patch -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sun Feb 28 04:45:02 2016
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 28 Feb 2016 09:45:02 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1456652702.7.0.104209416155.issue26049@psf.upfronthosting.co.za>


Changes by C?dric Krier <cedric.krier at b2ck.com>:


Added file: http://bugs.python.org/file42043/client.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Sun Feb 28 04:46:30 2016
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 28 Feb 2016 09:46:30 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1456652790.15.0.124016562481.issue26049@psf.upfronthosting.co.za>


C?dric Krier added the comment:

Here is the client/server scripts.
I don't measure a big performance improvement with it.
I think the improvement measured in msg257756 are linked to the way xmlrpclib is overriden in Tryton.

----------
Added file: http://bugs.python.org/file42044/server.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Sun Feb 28 05:27:32 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Sun, 28 Feb 2016 10:27:32 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
 auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1456655252.53.0.141778600824.issue2202@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

I can see in the tests (test_urllib2_localnet.py) that Digest auth is tested only through "ProxyAuthTests". Is that sufficient ? Isn't it a bug ? If no, should I add the test in that class ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Sun Feb 28 06:50:25 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Sun, 28 Feb 2016 11:50:25 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
 auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1456660225.33.0.615664246461.issue2202@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

first draft

----------
Added file: http://bugs.python.org/file42045/digest_md5sess_unittest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Sun Feb 28 07:39:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 28 Feb 2016 12:39:36 +0000
Subject: [issue26453] SystemError on invalid numpy.ndarray / Path operation
In-Reply-To: <1456643819.34.0.521319001507.issue26453@psf.upfronthosting.co.za>
Message-ID: <1456663176.94.0.0598533715342.issue26453@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as NumPy bug.

----------
nosy: +haypo, serhiy.storchaka
resolution:  -> third party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26453>
_______________________________________

From report at bugs.python.org  Sun Feb 28 08:06:15 2016
From: report at bugs.python.org (yuriy_levchenko)
Date: Sun, 28 Feb 2016 13:06:15 +0000
Subject: [issue26454] add support string that are not inherited from
 PyStringObject
Message-ID: <1456664775.79.0.943467327671.issue26454@psf.upfronthosting.co.za>


New submission from yuriy_levchenko:

i have my string object based on COW (https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Copy-on-write)

i think i need add flag Py_TPFLAGS_STRING_SUBCLASS

https://bugs.python.org/issue26421

but this only for bases on PyStringObject

----------
messages: 260974
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: add support string that are not inherited from PyStringObject
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26454>
_______________________________________

From report at bugs.python.org  Sun Feb 28 08:06:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Feb 2016 13:06:30 +0000
Subject: [issue26453] SystemError on invalid numpy.ndarray / Path operation
In-Reply-To: <1456643819.34.0.521319001507.issue26453@psf.upfronthosting.co.za>
Message-ID: <1456664790.57.0.589775064555.issue26453@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Bug in NumPy.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26453>
_______________________________________

From report at bugs.python.org  Sun Feb 28 08:36:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 28 Feb 2016 13:36:43 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1456666603.57.0.562487353291.issue26049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks C?dric.

There is no improvement for the first request. But if repeat requests, there is small (about 5%) improvement. This is too small.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Sun Feb 28 08:46:10 2016
From: report at bugs.python.org (Barun Parruck)
Date: Sun, 28 Feb 2016 13:46:10 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456667170.55.0.00663141356087.issue26448@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Hi, sorry, been pretty busy, and will be for a few days, so my replies may not be instant!

Having looked through the dis test module, to be honest, I can't even find a call to dis.findlabels...odd. Maybe I've got it wrong, and I wouldn't mind somebody else taking a look! But either way, a quick overview shows me that it basically picks up functions, figures out the disassembled function, and compares expected output, in a similar way that we're working, actually. 

I'll look through your example, which looks pretty good! It works as expected on my repo (fails and passes appropriately), and I'll see about improving it, but for now, it seems to do its job.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sun Feb 28 08:52:38 2016
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 28 Feb 2016 13:52:38 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1456667558.79.0.232190226462.issue26049@psf.upfronthosting.co.za>


C?dric Krier added the comment:

One advantage, I see, is when xmlrpclib is overridden to use an other marshaller which is can not be feed chunk by chunk. So reducing the number of call to feed will have a bigger impact.
But I don't know if this is enough for Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Sun Feb 28 11:11:42 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sun, 28 Feb 2016 16:11:42 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456675902.7.0.0239106559437.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

Oh, don't worry about time between responses, we all have lives (well, some of us anyhow :) ).

After looking at Lib/test/test_dis.py, I think it's just an oversight that there is no specific findlabels test (it's tested implicitly by ``dis.dis`` after all), and it would be good thing for you to add one.  The obvious place seems like a new method at the bottom of the ``DisTests`` class, but we'll have to rely on (probably) Yury to make that call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sun Feb 28 11:37:30 2016
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Sun, 28 Feb 2016 16:37:30 +0000
Subject: [issue26338] remove duplicate bind addresses in create_server
In-Reply-To: <1455201454.94.0.572810493705.issue26338@psf.upfronthosting.co.za>
Message-ID: <1456677450.29.0.0758327912139.issue26338@psf.upfronthosting.co.za>


Sebastien Bourdeauducq added the comment:

Can someone have a quick look at this please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26338>
_______________________________________

From report at bugs.python.org  Sun Feb 28 13:20:55 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sun, 28 Feb 2016 18:20:55 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456683655.92.0.173468765412.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

I just remembered that code can have more than one (up to three?) EXTENDED_ARG operators before the real opcode, so I added that generalization to build code around the args list...

----------
Added file: http://bugs.python.org/file42046/testfindlabels.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sun Feb 28 13:36:30 2016
From: report at bugs.python.org (David Edelsohn)
Date: Sun, 28 Feb 2016 18:36:30 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456684590.0.0.506578050069.issue26439@psf.upfronthosting.co.za>


David Edelsohn added the comment:

ctypes util.py "simply" needs support for AIX.  There already is special support for Windows, Darwin, BSDs, Solaris.  Is the question about the technical details for equivalent functionality on AIX or about adding a stanza to Lib/ctpyes/util.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Sun Feb 28 14:04:15 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 28 Feb 2016 19:04:15 +0000
Subject: [issue26446] Mention in the devguide that core devs are expected to
 follow the PSF CoC
In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za>
Message-ID: <1456686255.2.0.77493885424.issue26446@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Discussion of this change: https://mail.python.org/pipermail/python-committers/2016-February/003750.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26446>
_______________________________________

From report at bugs.python.org  Sun Feb 28 14:18:41 2016
From: report at bugs.python.org (Matt)
Date: Sun, 28 Feb 2016 19:18:41 +0000
Subject: [issue17369] Message.get_filename produces exception if the RFC2231
 encoding is ill-formed
In-Reply-To: <1362608740.33.0.297004510938.issue17369@psf.upfronthosting.co.za>
Message-ID: <1456687121.11.0.0194721342521.issue17369@psf.upfronthosting.co.za>


Changes by Matt <webforms+python at mjharrigan.com>:


----------
components: +Library (Lib) -email
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17369>
_______________________________________

From report at bugs.python.org  Sun Feb 28 14:19:27 2016
From: report at bugs.python.org (Matt)
Date: Sun, 28 Feb 2016 19:19:27 +0000
Subject: [issue17369] Message.get_filename produces exception if the RFC2231
 encoding is ill-formed
In-Reply-To: <1362608740.33.0.297004510938.issue17369@psf.upfronthosting.co.za>
Message-ID: <1456687167.65.0.216264636073.issue17369@psf.upfronthosting.co.za>


Changes by Matt <webforms+python at mjharrigan.com>:


----------
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17369>
_______________________________________

From report at bugs.python.org  Sun Feb 28 14:26:50 2016
From: report at bugs.python.org (Matt)
Date: Sun, 28 Feb 2016 19:26:50 +0000
Subject: [issue17369] Message.get_filename produces exception if the RFC2231
 encoding is ill-formed
In-Reply-To: <1362608740.33.0.297004510938.issue17369@psf.upfronthosting.co.za>
Message-ID: <1456687610.93.0.386802959664.issue17369@psf.upfronthosting.co.za>


Changes by Matt <webforms+python at mjharrigan.com>:


----------
components: +email -Library (Lib)
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17369>
_______________________________________

From report at bugs.python.org  Sun Feb 28 14:50:27 2016
From: report at bugs.python.org (Michel Desmoulin)
Date: Sun, 28 Feb 2016 19:50:27 +0000
Subject: [issue26455] Inconsistent behavior with KeyboardInterrupt and asyncio
 futures
Message-ID: <1456689026.99.0.0359024900858.issue26455@psf.upfronthosting.co.za>


New submission from Michel Desmoulin:

If you trigger KeyboardInterrupt in a coroutine and catch it, the program terminates cleanly:

import asyncio

async def bar():
    raise KeyboardInterrupt

loop = asyncio.get_event_loop()

try:
    loop.run_until_complete(bar())
except KeyboardInterrupt:
    print("It's ok")
finally:
    loop.stop()
    loop.close()


This outputs:

It's ok

However, if you wrap the coroutine in a Task, you will get a mixed behavior:

try:
    task = asyncio.ensure_future(bar())
    loop.run_until_complete(task)
except KeyboardInterrupt:
    print("It's ok")

This outputs:

It's ok
Task exception was never retrieved
future: <Task finished coro=<bar() done, defined at ki_bug.py:4> exception=KeyboardInterrupt()>
Traceback (most recent call last):
  File "ki_bug.py", line 10, in <module>
    loop.run_until_complete(main_future)
  File "/usr/lib/python3.5/asyncio/base_events.py", line 325, in run_until_complete
    self.run_forever()
  File "/usr/lib/python3.5/asyncio/base_events.py", line 295, in run_forever
    self._run_once()
  File "/usr/lib/python3.5/asyncio/base_events.py", line 1258, in _run_once
    handle._run()
  File "/usr/lib/python3.5/asyncio/events.py", line 125, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "ki_bug.py", line 5, in bar
    raise KeyboardInterrupt
KeyboardInterrupt

We have several contradictory behaviors: the KeyboardInterrupt is raised, and captured by the future (since your can do task.exception() to suppress the stracktrace) but also catched by except while the program is allowed to continue, yet still the stack trace is displayed and eventually the program return code will  be 0.

It's very confusing.

----------
components: asyncio
messages: 260984
nosy: Michel Desmoulin, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Inconsistent behavior with KeyboardInterrupt and asyncio futures
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26455>
_______________________________________

From report at bugs.python.org  Sun Feb 28 15:06:34 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Feb 2016 20:06:34 +0000
Subject: [issue26449] Tutorial on Python Scopes and Namespaces uses confusing
 'read-only' terminology
In-Reply-To: <1456564541.09.0.218031979167.issue26449@psf.upfronthosting.co.za>
Message-ID: <1456689994.19.0.97626517747.issue26449@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I think rephrasing with "... can only be read" would keep the intended meaning, but avoid the problematic "the namespaces are readonly" meaning.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26449>
_______________________________________

From report at bugs.python.org  Sun Feb 28 15:13:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Feb 2016 20:13:55 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <20160228201348.47181.72550@psf.io>


Roundup Robot added the comment:

New changeset 8f8e86ea3abb by Georg Brandl in branch '3.5':
Update susp-ignore file (#25910).
https://hg.python.org/cpython/rev/8f8e86ea3abb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sun Feb 28 16:02:23 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sun, 28 Feb 2016 21:02:23 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456693343.08.0.978322543002.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

Two things:

1) Verified this has always been a problem and still is in the development branch, so I added 2.7 and 3.6 to the versions list.

2) Couldn't tolerate the duplicate code handling the extended args operator, so in the interests of DRY, I moved the code scanner to a generator function (see attached dis_with_code_scanner.diff).

The patch is definitely not required to fix this bug, but it does isolate the original problem area to just one piece of code.

Could we get a get a quick review from a core dev saying either "go with Barun's less invasive preliminarypatch.diff" or "go with Eric's greater-churn dis_with_code_scanner.diff patch?"

(We still need to flesh out the testing a bit, so don't call us, we'll call you. :) )

----------
versions: +Python 2.7, Python 3.6
Added file: http://bugs.python.org/file42047/dis_with_code_scanner.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sun Feb 28 18:26:39 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sun, 28 Feb 2016 23:26:39 +0000
Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG
In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za>
Message-ID: <1456701999.97.0.852337815911.issue26448@psf.upfronthosting.co.za>


Eric Fahlgren added the comment:

Oops, wrong/bad patch, delete line 310 "arg = None" in _get_instruction_bytes...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26448>
_______________________________________

From report at bugs.python.org  Sun Feb 28 20:53:54 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 29 Feb 2016 01:53:54 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1456710834.22.0.990066985912.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

What I really want is to use regex in the C part as I did for the python one. It's the best approach and by very far.
I need to figure out how to use regex in CPython internals.

If I defer the actual processing to the Python part, what's the point of doing a C part ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 28 21:19:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Feb 2016 02:19:27 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1456710834.22.0.990066985912.issue15873@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZRDHmUsqdVtTVb+qoHJCuX3sKS-42voLNcyA7G=OfHPg@mail.gmail.com>


STINNER Victor added the comment:

> If I defer the actual processing to the Python part, what's the point of doing a C part ?

Currently, the "datetime" module is fully implemented in C, it's the
_datetime module in practice (accessed by the datetime module
namespace).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Feb 28 21:25:05 2016
From: report at bugs.python.org (Mathieu Dupuy)
Date: Mon, 29 Feb 2016 02:25:05 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1456712705.18.0.717239599318.issue15873@psf.upfronthosting.co.za>


Mathieu Dupuy added the comment:

I know. Martin was suggesting to defer the processing to an actual Python implementation, hence my answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Mon Feb 29 00:58:46 2016
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 29 Feb 2016 05:58:46 +0000
Subject: [issue26195] Windows frozen .exe multiprocessing.Queue access is
 denied exception
In-Reply-To: <1453690484.95.0.111987955887.issue26195@psf.upfronthosting.co.za>
Message-ID: <1456725526.91.0.168956687349.issue26195@psf.upfronthosting.co.za>


Alex Robinson added the comment:

Sorry I can't help more than provide a test environment for any fix. I just plucked the "fix" from StackOverflow and it fixed the Q problem on my machine.

It appears, at the least, the multiprocessing code should probably not rely on the default value for the 'inheritable' argument. That argument does sound like one that might be different in the usual case for Win32 and Unix, just because.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26195>
_______________________________________

From report at bugs.python.org  Mon Feb 29 01:29:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Feb 2016 06:29:11 +0000
Subject: [issue26456] import _tkinter + TestForkInThread leaves zombie with
 stalled thread
Message-ID: <1456727351.62.0.83247971741.issue26456@psf.upfronthosting.co.za>


New submission from Martin Panter:

After running the 2.7 test suite many times, my Linux OS?s memory slowly gets eaten up. It seems to be because of zombie Python processes that never get cleaned up unless I kill them explicitly. I never get this problem with the Python 3 test suite.

I narrowed it down to running test_tcl followed by test_thread, and then narrowed it even further to importing _tkinter and running TestForkInThread.test_forkinthread(). Now I have it minimized to the following:

$ ./python -c 'import _tkinter, thread, os; thread.start_new_thread(os.fork, ())'

A process is left behind listed with the ?defunct? or Z (zombie) status. However it has a child thread; maybe this is why it does not automatically get cleaned up.

Extract from ?htop?:
  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
    1 root       20   0 35412  4528  3448 S  0.0  0.2  0:01.25 /sbin/init
12615 vadmium    20   0     0     0     0 Z  0.0  0.0  0:00.00 ?? python
12616 vadmium    20   0  142M  5952  2220 S  0.0  0.3  0:00.00 ?  ?? ./python -c import _tkinter, thread, os; thread.start_new_thread(os.fork, ()) 

$ sudo strace -p 12616
Process 12616 attached - interrupt to quit
select(4, [3], [], [], NULL^C <unfinished ...>
Process 12616 detached
$ ls -l /proc/12616/fd
total 0
lrwx------ 1 vadmium users 64 Feb 29 05:57 0 -> /dev/pts/1
lrwx------ 1 vadmium users 64 Feb 29 05:57 1 -> /dev/pts/1
lrwx------ 1 vadmium users 64 Feb 29 05:57 2 -> /dev/pts/1
lr-x------ 1 vadmium users 64 Feb 29 05:57 3 -> pipe:[946176]
lr-x------ 1 vadmium users 64 Feb 29 05:57 4 -> pipe:[946321]
l-wx------ 1 vadmium users 64 Feb 29 05:57 5 -> pipe:[946176]
$ pacman -Q systemd glibc
systemd 222-1
glibc 2.22-4

----------
components: Tests, Tkinter
messages: 260993
nosy: martin.panter
priority: normal
severity: normal
status: open
title: import _tkinter + TestForkInThread leaves zombie with stalled thread
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26456>
_______________________________________

From report at bugs.python.org  Mon Feb 29 01:29:44 2016
From: report at bugs.python.org (feng liang)
Date: Mon, 29 Feb 2016 06:29:44 +0000
Subject: [issue26457] Error in ipaddress.address_exclude function
Message-ID: <1456727384.52.0.87644034474.issue26457@psf.upfronthosting.co.za>


New submission from feng liang:

when i read in document 3.5.1,run the example in ipaddress.address_exclude function 

>>> n1 = ip_network('192.0.2.0/28')
>>> n2 = ip_network('192.0.2.1/32')
>>> list(n1.address_exclude(n2))  

I got:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python 3.5\lib\ipaddress.py", line 794, in address_exclude
    s1, s2 = s1.subnets()
ValueError: not enough values to unpack (expected 2, got 1)

----------
components: Library (Lib)
messages: 260994
nosy: out
priority: normal
severity: normal
status: open
title: Error in ipaddress.address_exclude function
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26457>
_______________________________________

From report at bugs.python.org  Mon Feb 29 01:42:51 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 29 Feb 2016 06:42:51 +0000
Subject: [issue26457] Error in ipaddress.address_exclude function
In-Reply-To: <1456727384.52.0.87644034474.issue26457@psf.upfronthosting.co.za>
Message-ID: <1456728171.63.0.560584343807.issue26457@psf.upfronthosting.co.za>


Changes by Xiang Zhang <18518281186 at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26457>
_______________________________________

From report at bugs.python.org  Mon Feb 29 02:19:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Feb 2016 07:19:34 +0000
Subject: [issue26456] import _tkinter + TestForkInThread leaves zombie with
 stalled thread
In-Reply-To: <1456727351.62.0.83247971741.issue26456@psf.upfronthosting.co.za>
Message-ID: <1456730374.51.0.802787807871.issue26456@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26456>
_______________________________________

From report at bugs.python.org  Mon Feb 29 02:23:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Feb 2016 07:23:34 +0000
Subject: [issue26457] Error in ipaddress.address_exclude function
In-Reply-To: <1456727384.52.0.87644034474.issue26457@psf.upfronthosting.co.za>
Message-ID: <1456730614.71.0.727401299514.issue26457@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +ncoghlan, pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26457>
_______________________________________

From report at bugs.python.org  Mon Feb 29 02:50:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Feb 2016 07:50:14 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1456732214.09.0.581310530088.issue26362@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have read the thread on Python-list (http://comments.gmane.org/gmane.comp.python.general/789339) and still don't understand the purpose of your idea.

If you need unique filesystem paths without any access to real filesystem, you can use simple counter. If you need unpredictable -- use random generator. For uniqueness use a set of already generated name. If you have additional requirements -- it is easy to modify you code for your needs.

----------
nosy: +georg.brandl, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 29 03:56:34 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 29 Feb 2016 08:56:34 +0000
Subject: [issue26449] Tutorial on Python Scopes and Namespaces uses confusing
 'read-only' terminology
In-Reply-To: <1456564541.09.0.218031979167.issue26449@psf.upfronthosting.co.za>
Message-ID: <1456736194.78.0.406739297058.issue26449@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

+1 for "... can only be read". read-only can too easily be construed to mean that the variable cannot be set from *anywhere*, even the original scope. Another alternative would be "... is effectively read-only", but "... can only be read" is simpler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26449>
_______________________________________

From report at bugs.python.org  Mon Feb 29 04:12:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Feb 2016 09:12:11 +0000
Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug
In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za>
Message-ID: <1456737131.12.0.641608607309.issue25718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25718>
_______________________________________

From report at bugs.python.org  Mon Feb 29 04:41:00 2016
From: report at bugs.python.org (Steve Holden)
Date: Mon, 29 Feb 2016 09:41:00 +0000
Subject: [issue26449] Tutorial on Python Scopes and Namespaces uses confusing
 'read-only' terminology
In-Reply-To: <1456564541.09.0.218031979167.issue26449@psf.upfronthosting.co.za>
Message-ID: <1456738860.72.0.147030073792.issue26449@psf.upfronthosting.co.za>


Steve Holden added the comment:

I don't agree there is any place for the term "read-only" in this document. A reader who doesn't understand it or seeks clarification is likely to end up at a page like https://en.wikipedia.org/wiki/Read-only. I submit that nowhere except the documentation under discussion are they likely to find any suggestion that a read-only variable can in fact be changed, and hence I regard the discussion as extremely misleading.

Surely it would be better to focus on the fundamental point here, which is that IN THE ABSENCE OF A global OR nonlocal DECLARATION, ASSIGNMENT BINDS IN THE LOCAL NAMESPACE in a function.

If this point is correctly emphasised it should then be relatively easy to explain that in the absence of such an assignment in the function body in question, the standard name resolution algorithm operates, and that the global and non-local declarations change the effect of assignments to operate on the namespace that is identified by the standard name resolution algorithm.

It's too easy to confuse newcomers, and there seems to be general agreement that this piece is confusing. I'll be happy to attempt a rewrite of this section if we can agree on the goals.

----------
nosy: +holdenweb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26449>
_______________________________________

From report at bugs.python.org  Mon Feb 29 04:49:53 2016
From: report at bugs.python.org (Scott Corbin)
Date: Mon, 29 Feb 2016 09:49:53 +0000
Subject: [issue19241] MINGW: install import library
In-Reply-To: <1381661724.71.0.909185396021.issue19241@psf.upfronthosting.co.za>
Message-ID: <1456739393.2.0.155242658271.issue19241@psf.upfronthosting.co.za>


Changes by Scott Corbin <shacorbin at gmail.com>:


Added file: http://bugs.python.org/file42048/0AANH-66nZTUDUk9PVA

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19241>
_______________________________________

From report at bugs.python.org  Mon Feb 29 04:50:47 2016
From: report at bugs.python.org (Scott Corbin)
Date: Mon, 29 Feb 2016 09:50:47 +0000
Subject: [issue19241] MINGW: install import library
In-Reply-To: <1381661724.71.0.909185396021.issue19241@psf.upfronthosting.co.za>
Message-ID: <1456739447.74.0.763445613739.issue19241@psf.upfronthosting.co.za>


Changes by Scott Corbin <shacorbin at gmail.com>:


Removed file: http://bugs.python.org/file42048/0AANH-66nZTUDUk9PVA

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19241>
_______________________________________

From report at bugs.python.org  Mon Feb 29 05:05:40 2016
From: report at bugs.python.org (Michael Felt)
Date: Mon, 29 Feb 2016 10:05:40 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456740340.96.0.340746547658.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

it was, partly, about the technical details - but I feel I have found the key bits - /full/path/libNAME.a(libNAME.so) + dlflags RTLD_NOW + RTLD_MEMBER for "native" AIX support.

Additionally, a patch should not break what might be working for some (via google I read of suggestions for other languages, e.g., java, where .so members are extracted or installed side-by-side with the .a archive) - as the IBM run-rime loader also accepts/looks for both .a and .so. And/or for when /sbin/ldconfig is available. And when available, is this used as last case, or preferred?

Lastly, we cannot assume we will know the name of the member based on the name of the library. In many cases, e.g., libiconv.a the IBM names are shr.o, shr4.o and shr4_64.o - and these are the only member names unless GNU libiconv.a has been added (and then libconv.a also contains libiconv.so.2 (so version support is also desired!)) in both 32 and 64 bit mode.

One technical detail I have not been able to discover yet: how to determine whether in 32-bit or 64-bit mode. This will be important for libraries that have shr4.o and shr4_64.o as the members that need to be dlopened.

Lastly: about adding the "stanza": python is a new language for me. Any assistance with a patch - to keep it properly 'pythonized'

In short, I shall continue my studies/learning. Assistance from anyone wiser than me is welcome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Mon Feb 29 05:26:28 2016
From: report at bugs.python.org (Albert Freeman)
Date: Mon, 29 Feb 2016 10:26:28 +0000
Subject: [issue26458] Is the default value assignment of a function parameter
 evaluated multiple times if it is Parameter=None
Message-ID: <1456741588.21.0.674537261973.issue26458@psf.upfronthosting.co.za>


New submission from Albert Freeman:

def f(a, L=[]):
    L.append(a)
    return L

Seems to behave differently to
def f(a, L=None):
    L = []
    L.append(a)
    return L
Which behaves the same as (as far as I noticed) to the below code in the documentation (In the tutorial under 4. More Control Flow Tools)
def f(a, L=None):
    if L is None:
        L = []
    L.append(a)
    return L

I am using CPython 3.5.1, what is the point of "if L is None:" in the lowermost above example? And why is None treated differently to []?

----------
assignee: docs at python
components: Documentation
messages: 261000
nosy: docs at python, tocretpa
priority: normal
severity: normal
status: open
title: Is the default value assignment of a function parameter evaluated multiple times if it is Parameter=None
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26458>
_______________________________________

From report at bugs.python.org  Mon Feb 29 05:30:45 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Feb 2016 10:30:45 +0000
Subject: [issue26458] Is the default value assignment of a function parameter
 evaluated multiple times if it is Parameter=None
In-Reply-To: <1456741588.21.0.674537261973.issue26458@psf.upfronthosting.co.za>
Message-ID: <1456741845.53.0.996396907156.issue26458@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This is not a bug, see https://docs.python.org/3.6/faq/programming.html#why-are-default-values-shared-between-objects

In the first case L is evaluated once at compile time.
In the second case L is always set to a new empty list, regardless of what you pass as second argument to f.
In the third case L is set to a new empty list only if you don't pass a second argument (or if you pass None).

----------
nosy: +ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26458>
_______________________________________

From report at bugs.python.org  Mon Feb 29 05:32:27 2016
From: report at bugs.python.org (Andrej Antonov)
Date: Mon, 29 Feb 2016 10:32:27 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>
Message-ID: <1456741947.08.0.906973071988.issue14157@psf.upfronthosting.co.za>


Andrej Antonov added the comment:

$ python
    Python 3.5.1 (default, Dec  7 2015, 12:58:09) 
    [GCC 5.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 
    >>> 
    >>> 
    >>> import time
    >>> 
    >>> time.strptime("Feb 29", "%b %d")
    time.struct_time(tm_year=1900, tm_mon=2, tm_mday=29, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=60, tm_isdst=-1)
    >>> 
    >>> 
    >>> import datetime
    >>> 
    >>> datetime.datetime.strptime("Feb 29", "%b %d")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3.5/_strptime.py", line 511, in _strptime_datetime
        return cls(*args)
    ValueError: day is out of range for month

----------
nosy: +polymorphm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Mon Feb 29 06:23:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Feb 2016 11:23:50 +0000
Subject: [issue26456] import _tkinter + TestForkInThread leaves zombie with
 stalled thread
In-Reply-To: <1456727351.62.0.83247971741.issue26456@psf.upfronthosting.co.za>
Message-ID: <1456745030.03.0.0913991980943.issue26456@psf.upfronthosting.co.za>


Martin Panter added the comment:

I should point out that I think this problem didn?t used to happen. As far as I know, it could be a bug in a recently upgraded glibc or something. On another Linux computer I cannot produce the problem. When I get a chance I will try upgrading packages to see if that triggers the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26456>
_______________________________________

From report at bugs.python.org  Mon Feb 29 06:28:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 29 Feb 2016 11:28:38 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <20160229112834.76432.74501@psf.io>


Roundup Robot added the comment:

New changeset 5bfb4147405e by Martin Panter in branch '2.7':
Issue #26385: Cleanup NamedTemporaryFile if fdopen() fails, by SilentGhost
https://hg.python.org/cpython/rev/5bfb4147405e

New changeset a1c125f21db4 by Martin Panter in branch '3.5':
Issue #26385: Cleanup NamedTemporaryFile if open() fails, by SilentGhost
https://hg.python.org/cpython/rev/a1c125f21db4

New changeset 865cf8eba51a by Martin Panter in branch 'default':
Issue #26385: Merge NamedTemporaryFile fix from 3.5
https://hg.python.org/cpython/rev/865cf8eba51a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Mon Feb 29 06:45:24 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Mon, 29 Feb 2016 11:45:24 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>
Message-ID: <1456746324.23.0.939872672902.issue14157@psf.upfronthosting.co.za>


Sriram Rajagopalan added the comment:

datetime.strptime() uses the return value of _strptime() [ which returns 1900 for 29th Feb without an year ] and eventually ends up calling datetime_new()->check_date_args() [ datetimemodule.c ] with 29th Feb 1900 and eventual failure.

Should we enhance check_date_args to take a year_dont_care flag and validate the input year argument only if it is explicitly passed?

----------
nosy: +Sriram Rajagopalan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Mon Feb 29 08:19:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Feb 2016 13:19:45 +0000
Subject: [issue18195] error when deep copying module is confusing
In-Reply-To: <1370990732.59.0.654966118724.issue18195@psf.upfronthosting.co.za>
Message-ID: <1456751985.85.0.51607789821.issue18195@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Python 3.6:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/copy.py", line 97, in copy
    rv = reductor(4)
TypeError: can't pickle module objects

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18195>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:17:38 2016
From: report at bugs.python.org (Neil Girdhar)
Date: Mon, 29 Feb 2016 14:17:38 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1456755458.32.0.976620923166.issue4356@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

I'm also looking for bisect with a key argument (numpy array of records, want to search on one element).  However, I don't see bisect in the what's new: https://docs.python.org/3.6/whatsnew/3.6.html ?  Any luck with the implementation?

----------
nosy: +neil.g

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:17:57 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Mon, 29 Feb 2016 14:17:57 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456755477.95.0.555907764693.issue26404@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

The examples did not close the server but I am not sure if that was a mistake. The server is not being closed only on examples where it is expected to run until there is a keyboard interrupt. However you can see that when you send keyboard interrupt to a server you start using python -m http.server you will do close the server.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:32:02 2016
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Mon, 29 Feb 2016 14:32:02 +0000
Subject: [issue26459] Windows build instructions are very inaccurate
Message-ID: <1456756322.44.0.126364143286.issue26459@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

I've tried following the dev guide (still not successful) to compile a debug version of cpython 2.7 and a couple issues that I run into:

* The VS2010 vs VS2008 confustion - the docs say "most versions before 3.3 use VS2008" - what does it mean by "most"? The current cpython trunk seems to work only on 2010 (with a variety of fun errors).

* VS2010 is hard to download, as is 2008 - direct links would help

* nowhere it's mentioned that you need to run stuff from VS console

* the readme and the devguide disagree on a few points - readme seems to be better, but also not ideal

* the docs don't say how to get svn.exe (that is install tortoiseHG, but then select extra tools from somewhere)

* the build seems to require perl, despite claiming it's not

Other things are misguiding too, but fixing all of the above would be a massive step forward

----------
assignee: docs at python
components: Documentation
messages: 261009
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: Windows build instructions are very inaccurate
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26459>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:32:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Feb 2016 14:32:42 +0000
Subject: [issue26459] Windows build instructions are very inaccurate
In-Reply-To: <1456756322.44.0.126364143286.issue26459@psf.upfronthosting.co.za>
Message-ID: <1456756362.37.0.453752241432.issue26459@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26459>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:44:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 29 Feb 2016 14:44:15 +0000
Subject: [issue17231] Mark __del__ not being called in cycles as an impl detail
In-Reply-To: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>
Message-ID: <1456757055.62.0.161567133005.issue17231@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17231>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:44:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 29 Feb 2016 14:44:23 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1456757063.8.0.239985898265.issue17232@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:47:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Feb 2016 14:47:02 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1456757222.61.0.447250833843.issue17232@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Mon Feb 29 09:47:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Feb 2016 14:47:07 +0000
Subject: [issue17231] Mark __del__ not being called in cycles as an impl detail
In-Reply-To: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>
Message-ID: <1456757227.28.0.920464995789.issue17231@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17231>
_______________________________________

From report at bugs.python.org  Mon Feb 29 10:20:32 2016
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 29 Feb 2016 15:20:32 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456759232.02.0.359275702919.issue26439@psf.upfronthosting.co.za>


David Edelsohn added the comment:

AIX traditionally used member names like shr.o or shr<version>.o or shr<aix_release>.o insider the archive, with _64 designating a 64 bit object when there is a naming collision.

GNU libtool defaults to the SO name and version number insider the archive.

AIX objects (and shared objects) contain a bit in the header that specifies 32 bit or 64 bit.  Both 32 bit and 64 bit objects are intended to be archived together.  The linker only processes objects of the correct mode.

AIX shared objects contain a bit that specifies if the object may be used at link-edit time or only should be used for loading.  This is controlled by the AIX strip -e/-E option (yes, I know, strange place to hide that option).

This combination of features allows all of the libraries to be placed in a single /usr/lib directory and all of the objects to be collected into a single archive, avoiding /usr/lib64 and explosion of shared objects and symbolic links clutter.  Various packages have created /usr/local/lib64 anyway using Linux/Solaris/SVR4-style naming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Mon Feb 29 10:35:00 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 29 Feb 2016 15:35:00 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1456760100.94.0.195627740713.issue24823@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components:  -Devguide

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24823>
_______________________________________

From report at bugs.python.org  Mon Feb 29 11:19:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Feb 2016 16:19:37 +0000
Subject: [issue17580] ctypes: ARM hardfloat argument corruption calling
 functions with many float arguments
In-Reply-To: <1364651250.44.0.538707073215.issue17580@psf.upfronthosting.co.za>
Message-ID: <1456762777.77.0.153440780921.issue17580@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17580>
_______________________________________

From report at bugs.python.org  Mon Feb 29 11:23:00 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Feb 2016 16:23:00 +0000
Subject: [issue26459] Windows build instructions are very inaccurate
In-Reply-To: <1456756322.44.0.126364143286.issue26459@psf.upfronthosting.co.za>
Message-ID: <1456762980.28.0.52630538873.issue26459@psf.upfronthosting.co.za>


Steve Dower added the comment:

Agreed. The PCBuild/readme.txt file should clear up a few of those points, but the docs aren't exactly beginner friendly (and by that I mean beginning Windows users, not beginning C developers).

We probably need someone to write a dedicated document for building Python 2.7 at this stage. The dev guide should only really be for versions under active development. Unless someone else gets there first, I'll look at making it more approachable.

----------
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26459>
_______________________________________

From report at bugs.python.org  Mon Feb 29 12:58:07 2016
From: report at bugs.python.org (Michael Felt)
Date: Mon, 29 Feb 2016 17:58:07 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456768687.4.0.877556004396.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

The following demonstrates the basics.

cdll.LoadLibrary will load a .so file if it can be located (you will have to believe me as I forgot to include the test in this last batch)

Further, when given the AIX format for loading a member of an archive
(e.g., libc.a(shr.o) or libcrypto.a(libcrypto.so), the dlload occurs as expected.

in ctypes/utils.py
This looks in the standard directories (as the example, but not complete, see below) to demonstrate how to respond.
Note: it is also looking for a .so file, and if it finds one, it returns the .so name, otherwise it looks for a .a file - and when it finds it, just appends the libNAME.so in the correct format.

What is not done, and probably different from ldconfig behavior!

1. The complete path is not returned (so cdll.LoadLibrary will still follow default search - which I hope includes, read uses, the default for the python executable

2. The member name is not verified for existence (e.g., libconv.a(libiconv.so) is not expected to find libiconv.a(libiconv.so.2)

3. Since member verification is not being performed, shr.o, shr4.o, shr*_64.o

And many many thanks for the strip -e/-E info. Hard to find!

root at x064:[/data/prj/aixtools/src]diff -u python-2.7.11/Lib/ctypes/__init__.py /opt/lib/python2.7/ctypes/__init__.py
--- python-2.7.11/Lib/ctypes/__init__.py        2015-12-05 19:46:56 +0000
+++ /opt/lib/python2.7/ctypes/__init__.py       2016-02-29 17:36:43 +0000
@@ -11,6 +11,7 @@
 from _ctypes import _Pointer
 from _ctypes import CFuncPtr as _CFuncPtr
 from _ctypes import __version__ as _ctypes_version
+# from _ctypes import RTLD_LOCAL, RTLD_GLOBAL, RTLD_NOW ## fails
 from _ctypes import RTLD_LOCAL, RTLD_GLOBAL
 from _ctypes import ArgumentError
 
@@ -356,6 +357,14 @@
         if use_last_error:
             flags |= _FUNCFLAG_USE_LASTERROR
 
+        if _sys.platform.startswith("aix"):
+            RTLD_NOW    = 0x00000002
+            RTLD_MEMBER = 0x00040000
+            mode |= RTLD_NOW
+            if name is not None:
+                if name[-1] == ')':
+                       mode |= RTLD_MEMBER
+
         class _FuncPtr(_CFuncPtr):
             _flags_ = flags
             _restype_ = self._func_restype_


root at x064:[/data/prj/aixtools/src]diff -u python-2.7.11/Lib/ctypes/util.py /opt/lib/python2.7/ctypes/util.py
--- python-2.7.11/Lib/ctypes/util.py    2015-12-05 19:46:56 +0000
+++ /opt/lib/python2.7/ctypes/util.py   2016-02-29 17:42:41 +0000
@@ -84,6 +84,23 @@
                 continue
         return None
 
+if os.name == "posix" and sys.platform.startswith("aix"):
+        def _findLib_aix(name):
+            paths='/usr/lib:/lib:/usr/lpp/xlC/lib'
+            for dir in paths.split(":"):
+                shlib = os.path.join(dir, "lib%s.so" % name)
+                if os.path.exists(shlib):
+                    return shlib
+                libfile = os.path.join(dir, "lib%s.a" % name)
+                if os.path.exists(libfile):
+                    shlib = "lib%s.a(lib%s.so)" % (name, name)
+                    return shlib
+
+            return None
+
+        def find_library(name):
+            return _findLib_aix(name)
+
 elif os.name == "posix":
     # Andreas Degert's find functions, using gcc, /sbin/ldconfig, objdump
     import re, tempfile, errno
@@ -267,7 +284,16 @@
             print cdll.LoadLibrary("libcrypto.dylib")
             print cdll.LoadLibrary("libSystem.dylib")
             print cdll.LoadLibrary("System.framework/System")
+        elif sys.platform.startswith("aix"):
+            print find_library("crypto")
+            x = find_library("crypto")
+            print cdll.LoadLibrary(x)
+            print cdll.LoadLibrary("libcrypto.a(libcrypto.so)")
+            print cdll.LoadLibrary("libc.a(shr.o)")
+            print find_library("crypt")
+            print cdll.LoadLibrary("libcrypt.a(shr.o)")
         else:
+            print cdll.LoadLibrary("libc.a")
             print cdll.LoadLibrary("libm.so")
             print cdll.LoadLibrary("libcrypt.so")
             print find_library("crypt")


p.s. Anyone know what flag to set in vi so that tabs are never inserted and/or spaces converted to tabs. Python seems to hate tab indents.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Mon Feb 29 12:59:09 2016
From: report at bugs.python.org (Michael Felt)
Date: Mon, 29 Feb 2016 17:59:09 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1456768749.18.0.235282521924.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

Oops: forgot the example output:

root at x064:[/data/prj/aixtools/src]python -m ctypes.util
libm.a(libm.so)
libc.a(libc.so)
libbz2.a(libbz2.so)
libcrypto.a(libcrypto.so)
<CDLL 'libcrypto.a(libcrypto.so)', handle 6 at 30147690>
<CDLL 'libcrypto.a(libcrypto.so)', handle 7 at 30147690>
<CDLL 'libc.a(shr.o)', handle 8 at 30147690>
libcrypt.a(libcrypt.so)
<CDLL 'libcrypt.a(shr.o)', handle 9 at 30147690>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Mon Feb 29 13:02:35 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Mon, 29 Feb 2016 18:02:35 +0000
Subject: [issue26460] datetime.strptime without a year fails on Feb 29
Message-ID: <1456768955.02.0.995801288981.issue26460@psf.upfronthosting.co.za>


New submission from Sriram Rajagopalan:

$ python
    Python 3.5.1 (default, Dec  7 2015, 12:58:09) 
    [GCC 5.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 
    >>> 
    >>> 
    >>> import time
    >>> 
    >>> time.strptime("Feb 29", "%b %d")
    time.struct_time(tm_year=1900, tm_mon=2, tm_mday=29, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=60, tm_isdst=-1)
    >>> 
    >>> 
    >>> import datetime
    >>> 
    >>> datetime.datetime.strptime("Feb 29", "%b %d")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3.5/_strptime.py", line 511, in _strptime_datetime
        return cls(*args)
    ValueError: day is out of range for month

The same issue is seen in all versions of Python

----------
components: Library (Lib)
messages: 261014
nosy: Sriram Rajagopalan
priority: normal
severity: normal
status: open
title: datetime.strptime without a year fails on Feb 29
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26460>
_______________________________________

From report at bugs.python.org  Mon Feb 29 13:04:45 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Mon, 29 Feb 2016 18:04:45 +0000
Subject: [issue14157] time.strptime without a year fails on Feb 29
In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>
Message-ID: <1456769085.62.0.104848543355.issue14157@psf.upfronthosting.co.za>


Sriram Rajagopalan added the comment:

Opened issue 26460 for fixing the leap day bug in datetime.datetime.strptime()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14157>
_______________________________________

From report at bugs.python.org  Mon Feb 29 13:39:01 2016
From: report at bugs.python.org (Ben Finney)
Date: Mon, 29 Feb 2016 18:39:01 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1456771141.01.0.174153415211.issue26362@psf.upfronthosting.co.za>


Ben Finney added the comment:

> I have read the thread on Python-list

Thank you, and thanks for linking to that discussion.

> and still don't understand the purpose of your idea.

The purpose is to get a public API for making temporary filesystem paths with the same properties as are produced by ?tempfile?, specifically as produced by a ?tempfile._get_candidate_names? generator.

The paths will be used in unit tests and will never touch the filesystem.

Some have suggested using ?uuid? or other random-generator APIs. Using an API that isn't explicitly designed to produce valid filesystem paths is both risky (the algorithm may not exactly produce the right behaviour), and confusing (a reader seeing use of an unrelated API will not find it obvious why that API was used for generating a filesystem path).

The unit tests need paths with properties that are already implemented in ?tempfile?, so it seems unreasonable to suggest that functionality should be re-implemented elsewhere since it is already in the standard library.

The request is for a ?get the next path generated by a ?tempfile._get_candidate_names? generator?, with an approved and documented public API. One suggested name is ?tempfile.makepath?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 29 13:44:45 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 29 Feb 2016 18:44:45 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1456771485.12.0.254676570862.issue26362@psf.upfronthosting.co.za>


Ethan Furman added the comment:

> The request is for a ?get the next path generated by a
> ?tempfile._get_candidate_names? generator?, with an approved and
> documented public API.

I don't see any problem with this.  Patches welcome.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 29 14:17:40 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Feb 2016 19:17:40 +0000
Subject: [issue26385] the call of tempfile.NamedTemporaryFile fails and leaves
 a file on the disk
In-Reply-To: <1455812272.44.0.420327480876.issue26385@psf.upfronthosting.co.za>
Message-ID: <1456773460.74.0.144782826627.issue26385@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26385>
_______________________________________

From report at bugs.python.org  Mon Feb 29 15:15:17 2016
From: report at bugs.python.org (=?utf-8?q?Ilja_Everil=C3=A4?=)
Date: Mon, 29 Feb 2016 20:15:17 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
In-Reply-To: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>
Message-ID: <1456776917.94.0.452539013581.issue26407@psf.upfronthosting.co.za>


Ilja Everil? added the comment:

I have 0 beef with it being the TypeError as long as the exception chain is kept intact, especially since PY3 makes it possible. With current behaviour heisenbugs would produce some serious hair pulling, until one figures out that it is actually the __iter__ raising an exception.

With that in mind, take an object implementing the __iter__ dunder correctly 999,999 times out of a million. Is it not iterable?

Unfortunately I lack the experience with CPython C API to do something about this. Tests on the other hand I suppose I could manage, if a consensus on the behaviour can be reached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Mon Feb 29 15:31:18 2016
From: report at bugs.python.org (=?utf-8?q?Ilja_Everil=C3=A4?=)
Date: Mon, 29 Feb 2016 20:31:18 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
In-Reply-To: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>
Message-ID: <1456777878.46.0.233143875617.issue26407@psf.upfronthosting.co.za>


Ilja Everil? added the comment:

As a side note PyObject_GetIter actually raises a TypeError already for non-iterables (classes without __iter__ etc.), so csv_writerows duplicates the effort at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Mon Feb 29 15:32:19 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 29 Feb 2016 20:32:19 +0000
Subject: [issue26456] import _tkinter + TestForkInThread leaves zombie with
 stalled thread
In-Reply-To: <1456727351.62.0.83247971741.issue26456@psf.upfronthosting.co.za>
Message-ID: <1456777939.57.0.856803183429.issue26456@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I suspect this may be what causes several of the 2.7 builders to fail.  The ones that fail look like they complete successfully, but then sit with no output until buildbot kills them.

For example:

http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%202.7/builds/506/steps/compile/logs/stdio
http://buildbot.python.org/all/builders/s390x%20Debian%202.7/builds/258/steps/test/logs/stdio
http://buildbot.python.org/all/builders/s390x%20RHEL%202.7/builds/261/steps/test/logs/stdio
http://buildbot.python.org/all/builders/s390x%20SLES%202.7/builds/264/steps/test/logs/stdio
http://buildbot.python.org/all/builders/x86-64%20Ubuntu%2015.10%20Skylake%20CPU%202.7/builds/159/steps/test/logs/stdio

In each of those cases, test_tcl runs before test_thread (except on the SLES builder; but test_tk also imports _tkinter and does come before test_thread).

I can reproduce on Ubuntu 14.04.3, but not on a freshly updated Gentoo.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26456>
_______________________________________

From report at bugs.python.org  Mon Feb 29 15:39:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Feb 2016 20:39:33 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1456778373.51.0.842314993143.issue26362@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I see a problem. tempfile._get_candidate_names is implementation detail, and exposing it adds a burden for maintainers. It also adds cognitive burden for users of the tempfile module. And the idea itself looks doubtful and contradictory with the good practice of using the tempfile module.

I'm -1 for adding such function to the tempfile module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 29 15:47:57 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 29 Feb 2016 20:47:57 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1456778877.31.0.0925768235902.issue26362@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I don't see the problem.  Every Python platform that has `mktemp` has an implementation to generate the names, and that implementation can become the public face instead of `mktemp`.  So no more of a burden than `mktemp` is; likewise for the "cognitive burden".

As far as appropriate location -- where else would you put it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 29 16:20:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Feb 2016 21:20:30 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1456780830.7.0.638569439208.issue26362@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

mktemp is deprecated, and I think we will get rid of it when 2.7 will be out of use. Do you want to add new deprecated from the start function?

> As far as appropriate location -- where else would you put it?

May be in third-party module on PyPI? It doesn't look as highly demanded function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 29 16:26:33 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 29 Feb 2016 21:26:33 +0000
Subject: [issue26460] datetime.strptime without a year fails on Feb 29
In-Reply-To: <1456768955.02.0.995801288981.issue26460@psf.upfronthosting.co.za>
Message-ID: <1456781193.02.0.504000860673.issue26460@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Python's time.strptime() behavior is consistent with that of glibc 2.19:

======= strptime_c.c =======
#define _XOPEN_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

int
main(void)
{
  struct tm tm;
  char buf[255];

  memset(&tm, 0, sizeof(struct tm));
  strptime("Feb 29", "%b %d", &tm);
  strftime(buf, sizeof(buf), "%d %b %Y %H:%M", &tm);
  puts(buf);
  exit(EXIT_SUCCESS);
}
=======

$ gcc strptime_c.c 
$ ./a.out
29 Feb 1900 00:00


I'm not saying that the behavior is a good API, but given the unfortunate API at hand, parsing a date without specifying what year it is using strptime is a bad idea.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26460>
_______________________________________

From report at bugs.python.org  Mon Feb 29 17:09:26 2016
From: report at bugs.python.org (Ben Finney)
Date: Mon, 29 Feb 2016 22:09:26 +0000
Subject: [issue26362] Approved API for creating a temporary file path
In-Reply-To: <1455502271.6.0.558905453707.issue26362@psf.upfronthosting.co.za>
Message-ID: <1456783766.08.0.566455094826.issue26362@psf.upfronthosting.co.za>


Ben Finney added the comment:

Serhiy Storchaka

> mktemp is deprecated, and I think we will get rid of it when 2.7 will be out of use.

That's fine. This is not a request to retain ?tempfile.mktemp?.

I confused matters in my initial message, so your confusion is understandable on this point. To repeat:

The request is for a ?get the next path generated by a ?tempfile._get_candidate_names? generator?, with an approved and documented public API. One suggested name is ?tempfile.makepath?.


> Do you want to add new deprecated from the start function?

No. I'm asking for already-implemented and currently-maintained (i.e. not deprecated) standard library code, that is currently neither public nor documented, to gain a public API.


Ethan Furman:

> I don't see any problem with this.  Patches welcome.

Thank you, I'll work on a patch soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26362>
_______________________________________

From report at bugs.python.org  Mon Feb 29 17:26:03 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Mon, 29 Feb 2016 22:26:03 +0000
Subject: [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1456784763.36.0.109746302042.issue26176@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

From report at bugs.python.org  Mon Feb 29 17:30:33 2016
From: report at bugs.python.org (=?utf-8?q?Ilja_Everil=C3=A4?=)
Date: Mon, 29 Feb 2016 22:30:33 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
In-Reply-To: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>
Message-ID: <1456785033.65.0.915138981722.issue26407@psf.upfronthosting.co.za>


Ilja Everil? added the comment:

I'm starting to think my initial example code was too simplified and misled from the issue at hand. It very explicitly showed what happens when some class with __iter__ raises and is passed to csv_writerows. Even then:

>>> from collections.abc import Iterable
>>> class X:
...  def __iter__(self):
...   raise RuntimeError
... 
>>> x = X()
>>> issubclass(X, Iterable)
True
>>> isinstance(x, Iterable)
True

The glossary entry for iterable has nothing to say about exceptions. It only requires that they are able to return their members "one at a time". In a moderately complicated class this might be true most of the time, but that's not interesting; that 1 time when it can't is.

Now imagine you have a class with __iter__ using 1..N foreign libraries that all may blow up at the wrong phase of the moon (humor me). With the current implementation you get "TypeError: writerows() argument must be iterable", which goes out of its way to actually mislead you. Just letting the original exception through would be the obviously helpful thing to do. Which is what PyObject_GetIter does, before csv_writerows overwrites it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Mon Feb 29 17:51:30 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Feb 2016 22:51:30 +0000
Subject: [issue26460] datetime.strptime without a year fails on Feb 29
In-Reply-To: <1456768955.02.0.995801288981.issue26460@psf.upfronthosting.co.za>
Message-ID: <1456786290.35.0.954487768559.issue26460@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

This is not no more bug than

>>> from datetime import *
>>> datetime.strptime('0228', '%m%d')
datetime.datetime(1900, 2, 28, 0, 0)

Naturally, as long as datetime.strptime('0228', '%m%d') is the same as datetime.strptime('19000228', '%Y%m%d'), datetime.strptime('0229', '%m%d') should raise a ValueError as long as datetime.strptime('19000229', '%m%d') does.

The only improvement, I can think of in this situation is to point the user to time.strptime() in the error message.  The time.strptime method works just fine in the recent versions (see issue 14157.)

>>> time.strptime('0229', '%m%d')[1:3]
(2, 29)

----------
nosy: +belopolsky
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26460>
_______________________________________

From report at bugs.python.org  Mon Feb 29 17:54:41 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Feb 2016 22:54:41 +0000
Subject: [issue26460] datetime.strptime without a year fails on Feb 29
In-Reply-To: <1456768955.02.0.995801288981.issue26460@psf.upfronthosting.co.za>
Message-ID: <1456786481.55.0.114298759742.issue26460@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Python's time.strptime() behavior is consistent with that of glibc 2.19

Gregory,

I believe OP is complaining about the way datetime.datetime.strptime() behaves, not time.strptime() which is mentioned as (preferred?) alternative.


See msg261015  in issue 14157 for context.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26460>
_______________________________________

From report at bugs.python.org  Mon Feb 29 17:54:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Feb 2016 22:54:51 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1456786491.18.0.00686604672056.issue26404@psf.upfronthosting.co.za>


Martin Panter added the comment:

Server_close() was only documentated last year; see Issue 23254. For the examples that run until you interrupt them, the servers currently emit a resource warning (in addition to the KeyboardInterrupt traceback and the Python 2 bytes warnings):

$ python -bWall TCPServer.py
127.0.0.1 wrote:
TCPServer.py:16: BytesWarning: str() on a bytes instance
  print(self.data)
b'hello world with TCP'
127.0.0.1 wrote:
TCPServer.py:16: BytesWarning: str() on a bytes instance
  print(self.data)
b'python is nice'
^CTraceback (most recent call last):
  File "TCPServer.py", line 28, in <module>
    server.serve_forever()
  File "/usr/lib/python3.5/socketserver.py", line 237, in serve_forever
    ready = selector.select(poll_interval)
  File "/usr/lib/python3.5/selectors.py", line 367, in select
    fd_event_list = self._poll.poll(timeout)
KeyboardInterrupt
sys:1: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 9999)>
[Exit 1]

If you ignore the warning, there isn?t much effective difference, because the socket gets closed when the process exits, or if you are lucky, when Python garbage collects the global ?server? object. But IMO it is bad practice not to clean up resources properly, especially in an API example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Mon Feb 29 18:19:10 2016
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Mon, 29 Feb 2016 23:19:10 +0000
Subject: [issue26461] PyInterpreterState_Head(),
 PyThreadState_Next() etc can't be sanely used
Message-ID: <1456787950.96.0.423186176416.issue26461@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

All the internal uses of this API guard everything with HEAD_LOCK/HEAD_UNLOCK that's not exposed. It's not safe to traverse the whole API without holding those locks and those locks are static and module local

----------
messages: 261030
nosy: fijall
priority: normal
severity: normal
status: open
title: PyInterpreterState_Head(), PyThreadState_Next() etc can't be sanely used

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26461>
_______________________________________

From report at bugs.python.org  Mon Feb 29 18:27:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Feb 2016 23:27:06 +0000
Subject: [issue26461] PyInterpreterState_Head(),
 PyThreadState_Next() etc can't be sanely used
In-Reply-To: <1456787950.96.0.423186176416.issue26461@psf.upfronthosting.co.za>
Message-ID: <1456788426.11.0.968380832963.issue26461@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Are you asking to expose the lock?

----------
nosy: +haypo, pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26461>
_______________________________________

From report at bugs.python.org  Mon Feb 29 18:31:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Feb 2016 23:31:52 +0000
Subject: [issue26461] PyInterpreterState_Head(),
 PyThreadState_Next() etc can't be sanely used
In-Reply-To: <1456787950.96.0.423186176416.issue26461@psf.upfronthosting.co.za>
Message-ID: <1456788712.59.0.629550157005.issue26461@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fijal explained on IRC his use case: implement vmprof on Windows, a statistical profiler, using a C thread running in the Python process.

The _PyThread_CurrentFrames() API requires to be called with the GIL hold which is not acceptable for his use case. Having to wait for the GIL would serialize statistics plots and so would have a poor quality, probably similar to cProfile.

The use case is to implement something like _PyThread_CurrentFrames() without holding the GIL.

--

fijal mentioned pystate.c/.h functions which come with this comment:

/* Routines for advanced debuggers, requested by David Beazley.
   Don't use unless you know what you are doing! */

These functions are not safe if you don't hold head_mutex lock, but this lock is private in pystate.c (declared with "static").

I guess that they are safe to use if the whole process is stopped by a debugger like gdb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26461>
_______________________________________

From report at bugs.python.org  Mon Feb 29 18:36:57 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 29 Feb 2016 23:36:57 +0000
Subject: [issue17580] ctypes: ARM hardfloat argument corruption calling
 functions with many float arguments
In-Reply-To: <1364651250.44.0.538707073215.issue17580@psf.upfronthosting.co.za>
Message-ID: <1456789017.35.0.571384904153.issue17580@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17580>
_______________________________________

From report at bugs.python.org  Mon Feb 29 18:44:22 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 29 Feb 2016 23:44:22 +0000
Subject: [issue26460] datetime.strptime without a year fails on Feb 29
In-Reply-To: <1456768955.02.0.995801288981.issue26460@psf.upfronthosting.co.za>
Message-ID: <1456789462.88.0.132575184838.issue26460@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

time.strptime() is "working" (not raising an exception) as it appears not to validate the day of the month when a year is not specified, yet the return value from either of these APIs is a date which has no concept of an ambiguous year.

## Via the admittedly old Python 2.7.6 from Ubuntu 14.04: ##
# 1900 was not a leap year as it is not divisible by 400.
>>> time.strptime("1900 Feb 29", "%Y %b %d")
ValueError: day is out of range for month
>>> time.strptime("Feb 29", "%b %d")
time.struct_time(tm_year=1900, tm_mon=2, tm_mday=29, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=60, tm_isdst=-1)

So what should the validation behavior be?

>>> datetime.datetime.strptime("Feb 29", "%b %d")
ValueError: day is out of range for month
>>> datetime.datetime.strptime("2016 Feb 29", "%Y %b %d")
datetime.datetime(2016, 2, 29, 0, 0)
>>> datetime.datetime.strptime("1900 Feb 29", "%Y %b %d")
ValueError: day is out of range for month
>>> datetime.datetime(year=1900, month=2, day=29)
ValueError: day is out of range for month

datetime objects cannot be constructed with the invalid date (as the time.strptime return value allows).

Changing the API to assume the current year or a +/- 6 months from "now" when no year is parsed is likely to break existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26460>
_______________________________________

From report at bugs.python.org  Mon Feb 29 18:53:30 2016
From: report at bugs.python.org (Zach Byrne)
Date: Mon, 29 Feb 2016 23:53:30 +0000
Subject: [issue26280] ceval: Optimize list
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1456790010.26.0.44985845904.issue26280@psf.upfronthosting.co.za>


Zach Byrne added the comment:

The new patch "subscr2" removes the tuple block, and addresses Victor's comments. This one looks a little faster, down to 0.0215 usec for the same test.

----------
Added file: http://bugs.python.org/file42049/subscr2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26280>
_______________________________________

From report at bugs.python.org  Mon Feb 29 18:58:52 2016
From: report at bugs.python.org (Julien)
Date: Mon, 29 Feb 2016 23:58:52 +0000
Subject: [issue26462] Patch to enhance literal block language declaration
Message-ID: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za>


New submission from Julien:

Hi,

As I don't like warnings, and sphinx-doc was verbose about "Could not parse literal_block as "python3". highlighting skipped.", I fixed most of them.

Bonus: It's graphically better, as an example the XML block here: https://docs.python.org/3.5/library/pyexpat.html is now nicely colored: http://www.afpy.org/doc/python/3.5/library/pyexpat.html

----------
assignee: docs at python
components: Documentation
files: literal_blocks_languages.patch
keywords: patch
messages: 261035
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Patch to enhance literal block language declaration
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file42050/literal_blocks_languages.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26462>
_______________________________________

From report at bugs.python.org  Mon Feb 29 20:36:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Mar 2016 01:36:27 +0000
Subject: [issue26280] ceval: Optimize list[int] (subscript) operation
 similarly to CPython 2.7
In-Reply-To: <1454518938.55.0.360626721568.issue26280@psf.upfronthosting.co.za>
Message-ID: <1456796187.79.0.519320444804.issue26280@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: ceval: Optimize list -> ceval: Optimize list[int] (subscript) operation similarly to CPython 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26280>
_______________________________________

From report at bugs.python.org  Mon Feb 29 21:50:54 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Mar 2016 02:50:54 +0000
Subject: [issue26463] asyncio-related (?) segmentation fault
Message-ID: <1456800654.16.0.873933997584.issue26463@psf.upfronthosting.co.za>


New submission from Nicholas Chammas:

Python 3.5.1, OS X 10.11.3.

I have an application that uses asyncio and Cryptography (via the AsyncSSH library). Cryptography has some parts written in C, I believe.

I'm testing my application by sending a keyboard interrupt while 2 tasks are working. My application doesn't clean up after itself correctly, so I get these warnings about pending tasks being destroyed, but I don't think I should ever be getting segfaults. I am able to consistently get this segfault by interrupting my application at roughly the same point.

I'm frankly intimidated by the segfault (it's been many years since I dug into one), but the most likely culprits are either Python or Cryptography since they're the only components of my application that have parts written in C, as far as I know.

I'm willing to help boil this down to something more minimal with some help. Right now I just have the repro at this branch of my application (which isn't too helpful for people other than myself): 

https://github.com/nchammas/flintrock/pull/77

Basically, launch a cluster on EC2, and as soon as one task reports that SSH is online, interrupt Flintrock with Control + C. You'll get this segfault.

----------
components: Macintosh, asyncio
files: segfault.txt
messages: 261036
nosy: Nicholas Chammas, gvanrossum, haypo, ned.deily, ronaldoussoren, yselivanov
priority: normal
severity: normal
status: open
title: asyncio-related (?) segmentation fault
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file42051/segfault.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26463>
_______________________________________

From report at bugs.python.org  Mon Feb 29 21:51:18 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Mar 2016 02:51:18 +0000
Subject: [issue26463] asyncio-related (?) segmentation fault
In-Reply-To: <1456800654.16.0.873933997584.issue26463@psf.upfronthosting.co.za>
Message-ID: <1456800678.72.0.898343438475.issue26463@psf.upfronthosting.co.za>


Changes by Nicholas Chammas <nicholas.chammas at gmail.com>:


Added file: http://bugs.python.org/file42052/stacktrace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26463>
_______________________________________

From report at bugs.python.org  Mon Feb 29 22:22:09 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 01 Mar 2016 03:22:09 +0000
Subject: [issue26457] Error in ipaddress.address_exclude function
In-Reply-To: <1456727384.52.0.87644034474.issue26457@psf.upfronthosting.co.za>
Message-ID: <1456802529.91.0.257131846238.issue26457@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

In old ipaddr.py, IPv4Network('192.0.2.0/31').subnet() returns [IPv4Network('192.0.2.0/32'), IPv4Network('192.0.2.1/32')], but ipaddress returns only [IPv4Network('192.0.2.0/32')]. 

It seems simply change end to end+1 in https://hg.python.org/cpython/file/tip/Lib/ipaddress.py#l921 can solve the problem and pass the test. But maybe there are some side effects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26457>
_______________________________________