From report at bugs.python.org  Mon Jan  1 00:47:34 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 01 Jan 2018 05:47:34 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
Message-ID: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

>From python-ideas: https://mail.python.org/pipermail/python-ideas/2017-December/048492.html

In this page of the documentation:
https://docs.python.org/3/library/collections.abc.html

The table could be difficult to understand, a diagram help visualize things.

I'm joining the last version of my work, and the .puml I used to generate it.

Opinions about details (fonts, displaying...) are being discussed on the mailist right now.

----------
assignee: docs at python
components: Documentation
files: base.png
messages: 309318
nosy: docs at python, yahya-abou-imran
priority: normal
severity: normal
status: open
title: Add an UML class diagram to the collections.abc module documentation
type: enhancement
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47357/base.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Mon Jan  1 00:55:05 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 01 Jan 2018 05:55:05 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1514786105.46.0.467229070634.issue32471@psf.upfronthosting.co.za>


Yahya Abou Imran <yahya-abou-imran at protonmail.com> added the comment:

Here is the .puml

----------
Added file: https://bugs.python.org/file47358/base.puml

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Mon Jan  1 01:06:41 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 01 Jan 2018 06:06:41 +0000
Subject: [issue32472] Mention of __await__ missing in Coroutine Abstract
 Methods
Message-ID: <1514786801.71.0.467229070634.issue32472@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

In the collections.abc documentation:

https://docs.python.org/3/library/collections.abc.html

__await__() doesn't appear in the abstract methods of Coroutine, we see only send() and throw().

But since Coroutine inherit from Awaitable, it's required:


from collections.abc import Coroutine

class MyCoroutine(Coroutine):
    def send(self, value):
        raise StopIteration
    def throw(self, err):
        raise err

mc = MyCoroutine()

Traceback (most recent call last):
  File "_tmp.py", line 9, in <module>
    mc = MyCoroutine()
TypeError: Can't instantiate abstract class MyCoroutine with abstract methods __await__


To be consistent with the rest of the document, this method should appear here to show all the abstract methods, even the inherited ones.

----------
assignee: docs at python
components: Documentation
messages: 309320
nosy: docs at python, yahya-abou-imran
priority: normal
severity: normal
status: open
title: Mention of __await__ missing in Coroutine Abstract Methods
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32472>
_______________________________________

From report at bugs.python.org  Mon Jan  1 01:09:25 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 01 Jan 2018 06:09:25 +0000
Subject: [issue32473] Readibility of ABCMeta._dump_registry()
Message-ID: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

>From python-ideas:
https://mail.python.org/pipermail/python-ideas/2017-December/048504.html

In python 2.7, ABCs's caches and registries are sets. But in python 3.6 they are WeakSet.
In consequence, the output of _dump_registry() is almost useless:

>>> from collections import abc
>>> abc.Iterator._dump_registry()
Class: collections.abc.Iterator
Inv.counter: 40
_abc_cache: <_weakrefset.WeakSet object at 0x7f4b58fe2668>
_abc_negative_cache: <_weakrefset.WeakSet object at 0x7f4b53283780>
_abc_negative_cache_version: 40
_abc_registry: <_weakrefset.WeakSet object at 0x7f4b58fe2630>

We could convert them into a regular set before printing:

if isinstance(value, WeakSet):
    value = set(value)

The result:

>>> abc.Iterator._dump_registry()
Class: collections.abc.Iterator
Inv.counter: 40
_abc_cache: {<class 'dict_valueiterator'>, <class 'bytearray_iterator'>, <class 'tuple_iterator'>, <class 'dict_itemiterator'>, <class 'dict_keyiterator'>, <class 'str_iterator'>, <class 'zip'>, <class 'set_iterator'>, <class 'list_reverseiterator'>, <class 'range_iterator'>, <class 'longrange_iterator'>, <class 'list_iterator'>, <class 'bytes_iterator'>}
_abc_negative_cache: set()
_abc_negative_cache_version: 40
_abc_registry: set()

----------
messages: 309321
nosy: yahya-abou-imran
priority: normal
severity: normal
status: open
title: Readibility of ABCMeta._dump_registry()
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Mon Jan  1 01:47:30 2018
From: report at bugs.python.org (Shubham Sharma)
Date: Mon, 01 Jan 2018 06:47:30 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
Message-ID: <1514789250.22.0.467229070634.issue32474@psf.upfronthosting.co.za>


Change by Shubham Sharma <shubhamsharma1172 at gmail.com>:


----------
components: Library (Lib)
nosy: shubham1172
priority: normal
severity: normal
status: open
title: argparse nargs should support string wrapped integers too
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 02:02:42 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 01 Jan 2018 07:02:42 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
Message-ID: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

What do you mean by "string wrapped integers", and how should it support them?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 02:10:37 2018
From: report at bugs.python.org (Shubham Sharma)
Date: Mon, 01 Jan 2018 07:10:37 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514790637.03.0.467229070634.issue32474@psf.upfronthosting.co.za>


Shubham Sharma <shubhamsharma1172 at gmail.com> added the comment:

Values like "1", "2", "3", should be supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 02:11:39 2018
From: report at bugs.python.org (Shubham Sharma)
Date: Mon, 01 Jan 2018 07:11:39 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514790699.23.0.467229070634.issue32474@psf.upfronthosting.co.za>


Shubham Sharma <shubhamsharma1172 at gmail.com> added the comment:

A simple int(nargs) would be sufficient. I am getting ready with a PR in some time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 02:19:41 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 01 Jan 2018 07:19:41 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790637.03.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <20180101071933.GY4215@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Values like "1", "2", "3", should be supported.

You mean you want to call parser.add_argument('--foo', nargs="2") 
instead of parser.add_argument('--foo', nargs=2)?

Why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 02:22:14 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jan 2018 07:22:14 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514791334.76.0.467229070634.issue32474@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why?  What's the motivation for supporting this?  There's no reason that I can think of, so I'm curious what your use case is.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 02:34:17 2018
From: report at bugs.python.org (Shubham Sharma)
Date: Mon, 01 Jan 2018 07:34:17 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514792057.15.0.467229070634.issue32474@psf.upfronthosting.co.za>


Shubham Sharma <shubhamsharma1172 at gmail.com> added the comment:

nargs can take various values like "*", "+", etc. but doesn't support integers which are wrapped around in strings. Say, I want to take a user input for the nargs value (just a hypothetical situation); now I'll have to check additionally whether there's a numeric value inside the input char and then cast it to integer manually. An enhancement like this would eliminate this hassle and support for these will be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 03:31:45 2018
From: report at bugs.python.org (Tim Savannah)
Date: Mon, 01 Jan 2018 08:31:45 +0000
Subject: [issue32475] Add ability to query number of buffered bytes available
 on buffered I/O
Message-ID: <1514795505.19.0.467229070634.issue32475@psf.upfronthosting.co.za>


New submission from Tim Savannah <kata198 at gmail.com>:

Hello!

This is my first time submitting to Python bug tracker, so please bear with me if I miss/mess something.

So a little bit of relevant background, I'm an avid python developer with many open-source projects.

One of the projects I wrote and maintain is called "python-nonblock", which provides pure-python non-blocking I/O methods. It is available at:

https://github.com/kata198/python-nonblock


I'll only include the relevant details to this topic.

So, one of the features provided by the python-nonblock in the nonblock_read function. This allows you to read from a stream whilst ensuring the operation does not block.

It achieves this by basically following this pattern:

1. Call "select" on the stream and see if any data is available. If not, sleep and reiterate.

2. If there is data available, it reads a single byte from the stream and stores is to return at the end.

It supports most streams and sockets which have a real fd backing (and thus support "select").


There are a couple reasons you may need to do this, e.x. certain interactive scenarios, I won't go into it too much.


The python-nonblock library also bundles a layer which sits on top of that method, called BackgroundRead. This interface launches a thread into the background, which reads blocks of arbitrary (user-provided) size into a variable on an object. So you could have a processing app which reads blocks of data from a source, processes them in the foreground whilst they continue to load up in the background.


That's all well and good, but we are getting to the meat of the issue: for large sources of available data (like a file on disk), while this method of operation is effective, it is SLOW, due to the overhead of a select syscall and libpython for every single byte. This is especially true on a loaded system, as it makes us a prime candidate for the scheduler to preempt our task and context switch us off the cpu!


I've been looking into ways to improve this, and have actually seemed to have struck gold. So on a standard linux HDD filesystem, the I/O block size is 4096. So, thanks to readahead, on a non-fragmented file, a read call for 1 byte will actually load up to 4096 bytes. libpython has this extra data, and calls like read1 will return it if available, but it does not expose this number. Thus, libraries like mine can't take advantage of it, which means that for a filesystem I/O read on linux, 4095 out of 4096 iterations of the two-step loop above are wasted effort.

So I've written up an additional function to the C code for BufferedReader, "getbuffn", which returns the number bytes currently buffered in libpython, but not yet returned to the application, and modified python-nonblock ( in the 4.0branch_getbuffn branch ) with simple additions to take advantage of this extra information, when available. So if we detect that there are 4095 bytes already read and pending, we know for certain we can grab all 4095 bytes at once without blocking, or even needing a call to select!

So the new pattern for buffered streams that have getbuffn available, we can:

1. Select to see if data is available, if not rest and reiterate

2. Read a single byte off the stream

3. Check getbuffn, and if it returns >0 read that many bytes off the stream (Guaranteed to not block)


The performance improvements are * MASSIVE * with this change in place.

   On a 5 meg file from a VM which is running on an SSD, I average the following:
 
     Loaded system, non-cached I/O:
 
        One-Fell-Swoop file.read() - .3 seconds
 
        getbuffn-patched python and this impl - 3.1 seconds
 
        unpatched python and this impl - 41 to 55 = 44 seconds. ( avg min - avg max)
 
     Unloaded system, cached I/O:
 
        One-Fell-Swoop file.read() - .0017 seconds
 
        getbuffn-patched python and this impl - .034 seconds
 
        unpatched python and this impl - 45 seconds. ( not as variable as loaded system )

That's a 13,235% (thirteen-thousand two-hundred and five percent) performance boost on just a 5MB file, which just grows exponentially as the size of the dataset increases. These gains are just simply not possible without this information available (the amount remaining in the buffer).


So I've attached the simple patch (only additions, no modifications to existing functions) against python 3.6.4. The version of python-nonblock which supports this enhanced approach when available (and more details at the top of the README) can be found here: 

https://github.com/kata198/python-nonblock/tree/4.0branch_getbuffn

I've looked at the python 2.7 code too, and it seems that with minimal effort this same functionality can be provided there as well!


So, I'm an experienced developer who is willing to put in the legwork. Is this something that is possible to get merged upstream? If so, what are the steps I would need to take in order to make it so?


Thanks in advance,
Tim Savannah

----------
components: IO, Library (Lib)
files: Python_3_6_4_getbuffn.patch
keywords: patch
messages: 309328
nosy: kata198
priority: normal
severity: normal
status: open
title: Add ability to query number of buffered bytes available on buffered I/O
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file47359/Python_3_6_4_getbuffn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32475>
_______________________________________

From report at bugs.python.org  Mon Jan  1 04:00:43 2018
From: report at bugs.python.org (Shubham Sharma)
Date: Mon, 01 Jan 2018 09:00:43 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514797243.77.0.467229070634.issue32474@psf.upfronthosting.co.za>


Change by Shubham Sharma <shubhamsharma1172 at gmail.com>:


----------
keywords: +patch
pull_requests: +4944
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 04:39:35 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 01 Jan 2018 09:39:35 +0000
Subject: [issue32466] Remove fractions._gcd()
In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za>
Message-ID: <1514799575.52.0.467229070634.issue32466@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> the types in question were added to the numeric tower for gmpy 2.0.9 and 2.1.0.

Ah, good to know. Thanks. I was using 2.0.8.

> * We're back to needing a test for the line in question.

Agreed. It's not currently covered, and with the current behaviour the line _is_ necessary.

> * We're eschewing the possibility of changing the behavior of `fractions.Fraction` to force int numerator and denominator.

I think that's a separate issue from this one, and if you want to pursue it it's worth its own issue on the tracker. But there would need to be a good reason for deliberately changing the existing by-design behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32466>
_______________________________________

From report at bugs.python.org  Mon Jan  1 05:00:01 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 01 Jan 2018 10:00:01 +0000
Subject: [issue32466] Fix missing test coverage for fractions.Fraction.__new__
In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za>
Message-ID: <1514800801.57.0.467229070634.issue32466@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've retitled the issue to avoid confusion, since we're no longer proposing removing the _gcd function.

----------
title: Remove fractions._gcd() -> Fix missing test coverage for fractions.Fraction.__new__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32466>
_______________________________________

From report at bugs.python.org  Mon Jan  1 09:09:51 2018
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 01 Jan 2018 14:09:51 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514815791.4.0.467229070634.issue17611@psf.upfronthosting.co.za>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +4945

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 11:17:04 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 01 Jan 2018 16:17:04 +0000
Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c:
 Function argument assignment between types "unsigned long" and "struct
 fsid_t" is not allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1514823424.4.0.467229070634.issue32390@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

Did some additional research. The code can work asis when _ALL_SOURCE is undefined. Or, in other words - there does not have to be a variable syntax issue or separate code for AIX.

As you read this - please remember that since issue #32143 was 'resolved' AIX cannot compile.

* https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html

describes _ALL_SOURCE as a macro for AIX3.

Looking at AIX: /usr/include/sys/types.h - by undefining _ALL_SOURCE the typedefs in the header files are equivalent enough that the new code added for os.statvfs(path) is compiled by both gcc and xlc.

As examples (from Centos)
/usr/include/bits/typesizes.h:72:#define __FSID_T_TYPE          struct { int __val[2]; }

And from AIX:
 * /usr/include/sys/types.h
  +360  / * typedef for the File System Identifier (fsid).  This must correspond
  +361    * to the "struct fsid" structure in _ALL_SOURCE below.
  +362    * /
  +363  typedef struct fsid_t {
  +364  #ifdef __64BIT_KERNEL
  +365          unsigned long val[2];
  +366  #else  / * __64BIT_KERNEL * /
  +367  #ifdef _ALL_SOURCE
  +368          unsigned int val[2];
  +369  #else  / * _ALL_SOURCE * /
  +370          unsigned int __val[2];
  +371  #endif / * _ALL_SOURCE * /
  +372  #endif / * __64BIT_KERNEL * /
  +373  } fsid_t;
 */

(Note - a variation of the text above was in the pull request https://github.com/python/cpython/pull/4972. Per reviewer request - this is removed and a discussion is now open here.)

Thank you for your comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Mon Jan  1 11:18:52 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jan 2018 16:18:52 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514823532.93.0.467229070634.issue17611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So we now have three competing PRs... each of which is not trivial. It would be nice if somehow there could be some conciliation, or at least a synthetic comparison. I don't think I want to review all three proposals (and I already spent time reviewing previous versions of Serhiy's).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 11:54:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jan 2018 16:54:33 +0000
Subject: [issue32475] Add ability to query number of buffered bytes available
 on buffered I/O
In-Reply-To: <1514795505.19.0.467229070634.issue32475@psf.upfronthosting.co.za>
Message-ID: <1514825673.89.0.467229070634.issue32475@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why don't you use BufferedReader.peek()?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32475>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:02:25 2018
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 01 Jan 2018 17:02:25 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514826145.32.0.467229070634.issue17611@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

It shouldn't be a surprise that I have submitted a PR. The original patch was my work and a month ago I said I would update it over the Christmas break. 

To avoid "competing" PRs in future, simply asking before appropriating other peoples work would help. I've signed the CLA, so I don't think there are any legal issues with Serhiy's or Neil's PRs containing my code, but it does seem a bit presumptive.

Having said that, if someone can convince me that Serhiy's PR is better, then I have no problem with it being merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:11:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 17:11:12 +0000
Subject: [issue32416] Refactor and add new tests for the f_lineno setter
In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za>
Message-ID: <1514826672.15.0.467229070634.issue32416@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4946

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32416>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:13:02 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 01 Jan 2018 17:13:02 +0000
Subject: [issue27643] test_ctypes fails on AIX with xlc
In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za>
Message-ID: <1514826782.03.0.467229070634.issue27643@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

As I was not responding properly (too verbose) - I'll reread the thread for the initial patch suggestion - and hope it still fits the current 'master'.

My apologies for the long silence on this.

----------
nosy:  -aixtools at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27643>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:16:23 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 01 Jan 2018 17:16:23 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514826983.98.0.467229070634.issue32474@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:19:31 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 01 Jan 2018 17:19:31 +0000
Subject: [issue28290] BETA report: Python-3.6 build messages to stderr: AIX
 and "not GCC"
In-Reply-To: <1475001330.34.0.107474417097.issue28290@psf.upfronthosting.co.za>
Message-ID: <1514827171.63.0.467229070634.issue28290@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

this was just feedback - and should probably be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28290>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:21:24 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 01 Jan 2018 17:21:24 +0000
Subject: [issue27632] build on AIX fails when builddir != srcdir,
 more than bad path to ld_so_aix
In-Reply-To: <1469608112.86.0.803958819971.issue27632@psf.upfronthosting.co.za>
Message-ID: <1514827284.01.0.467229070634.issue27632@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

There were changes made - I know not when - but OOT builds work now. This issue may be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27632>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:38:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 17:38:44 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514828324.29.0.467229070634.issue17611@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

New opcodes in PR 5071 look interesting, but I think it is better to leave this experiment for a separate issue.

Complexities of PRs (ignoring tests, documentation, and generated files):

PR 4682:
 Include/opcode.h      |  12 +-
 Lib/opcode.py         |  21 +-
 Objects/frameobject.c | 241 ++++++++-----
 Objects/genobject.c   |  10 +-
 Python/ceval.c        | 426 +++++++++++------------
 Python/compile.c      | 884 +++++++++++++++++++++++++++++++++---------------
 Python/peephole.c     |  18 +-
 7 files changed, 979 insertions(+), 633 deletions(-)

PR 5006:
 Include/opcode.h      |   8 +-
 Lib/opcode.py         |  11 +-
 Objects/frameobject.c | 203 ++++++++-------------
 Objects/genobject.c   |  10 +-
 Python/ceval.c        | 344 ++++++++++++++++-------------------
 Python/compile.c      | 474 +++++++++++++++++++++++++++++-------------------
 Python/peephole.c     |  33 ++--
 7 files changed, 561 insertions(+), 522 deletions(-)

PR 5071:
 Include/frameobject.h     |   5 +-
 Include/opcode.h          |  18 +-
 Lib/opcode.py             |  25 +-
 Objects/frameobject.c     | 224 ++++++---------
 Objects/genobject.c       |  10 +-
 Python/ceval.c            | 507 ++++++++++++---------------------
 Python/compile.c          | 681 +++++++++++++++++++++++++++++++-------------
 Python/peephole.c         |  49 +---
 Python/wordcode_helpers.h |  33 ++-
 9 files changed, 827 insertions(+), 725 deletions(-)

PR 4682: +4 opcodes, -4 opcodes, and changed numerical values of 2 opcodes
PR 5006: +4 opcodes, -4 opcodes
PR 5071: +8 opcodes, -8 opcodes, and changed numerical value of 1 opcode

It looks to me that PR 5006 has the lowest complexity and is the most easy for reviewing.

I'm working on it since taking Antoine's PR 5 months ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:39:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 17:39:41 +0000
Subject: [issue32416] Refactor and add new tests for the f_lineno setter
In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za>
Message-ID: <1514828381.78.0.467229070634.issue32416@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e8ed96550c6aa9a1e39c36e67e892994e25e2c41 by Serhiy Storchaka in branch 'master':
bpo-32416: Add two new tests in test_sys_settrace. (#5072)
https://github.com/python/cpython/commit/e8ed96550c6aa9a1e39c36e67e892994e25e2c41


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32416>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:39:56 2018
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Jan 2018 17:39:56 +0000
Subject: [issue32416] Refactor and add new tests for the f_lineno setter
In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za>
Message-ID: <1514828396.01.0.467229070634.issue32416@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4947

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32416>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:40:52 2018
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Jan 2018 17:40:52 +0000
Subject: [issue32416] Refactor and add new tests for the f_lineno setter
In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za>
Message-ID: <1514828452.37.0.467229070634.issue32416@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4948

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32416>
_______________________________________

From report at bugs.python.org  Mon Jan  1 12:54:11 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jan 2018 17:54:11 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514829251.29.0.467229070634.issue17611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I took a quick look at Mark's PR.  The main thing going for it IMHO is that it produces simpler bytecode: it removes the complicated with/finally-related opcodes, while Serhiy's has non-trivial END_FINALLY and POP_FINALLY.

It would be nice to know if it's able to fix the stack size issues as in the following tests:
https://github.com/python/cpython/pull/5006/files?diff=unified#diff-dae68b96e8fdcb924e1ea46c31f51aec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 13:31:16 2018
From: report at bugs.python.org (Shubham Sharma)
Date: Mon, 01 Jan 2018 18:31:16 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514831476.94.0.467229070634.issue32474@psf.upfronthosting.co.za>


Change by Shubham Sharma <shubhamsharma1172 at gmail.com>:


----------
pull_requests: +4949

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 13:51:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 18:51:14 +0000
Subject: [issue32416] Refactor and add new tests for the f_lineno setter
In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za>
Message-ID: <1514832674.74.0.467229070634.issue32416@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2de47ca109d0418c7c01e451b5614f748ad76ee9 by Serhiy Storchaka (Miss Islington (bot)) in branch '2.7':
bpo-32416: Add two new tests in test_sys_settrace. (GH-5072) (#5074)
https://github.com/python/cpython/commit/2de47ca109d0418c7c01e451b5614f748ad76ee9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32416>
_______________________________________

From report at bugs.python.org  Mon Jan  1 13:51:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 18:51:33 +0000
Subject: [issue32416] Refactor and add new tests for the f_lineno setter
In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za>
Message-ID: <1514832693.01.0.467229070634.issue32416@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 439ce8a93936d92e4f10765c482195a28e93ec76 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-32416: Add two new tests in test_sys_settrace. (GH-5072) (#5073)
https://github.com/python/cpython/commit/439ce8a93936d92e4f10765c482195a28e93ec76


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32416>
_______________________________________

From report at bugs.python.org  Mon Jan  1 14:19:07 2018
From: report at bugs.python.org (John Jolly)
Date: Mon, 01 Jan 2018 19:19:07 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
Message-ID: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>


New submission from John Jolly <jjolly at suse.com>:

The current implementation of the xpath specification in ElementTree does not allow for predicates that may contain both an apostrophe and a quote. Either one or the other is allowed, but escaping (either string escaping using the backslash or html escaping) is not supported.

A simple solution would be to implement the xpath concat function for predicates. This would allow the combination of quote types in the predicate. Attached is a proposed patch for this fix.

----------
components: Library (Lib)
files: etree-concat.patch
keywords: patch
messages: 309344
nosy: jjolly
priority: normal
severity: normal
status: open
title: Add concat functionality to ElementTree xpath find
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47360/etree-concat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Mon Jan  1 14:49:09 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 01 Jan 2018 19:49:09 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514836149.42.0.467229070634.issue32474@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

-1

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 15:06:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 20:06:58 +0000
Subject: [issue24340] co_stacksize estimate can be highly off
In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za>
Message-ID: <1514837218.9.0.467229070634.issue24340@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4950

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24340>
_______________________________________

From report at bugs.python.org  Mon Jan  1 15:08:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 20:08:55 +0000
Subject: [issue24340] co_stacksize estimate can be highly off
In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za>
Message-ID: <1514837335.28.0.467229070634.issue24340@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

With PR 5076 the result of the above example is 10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24340>
_______________________________________

From report at bugs.python.org  Mon Jan  1 15:10:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 20:10:37 +0000
Subject: [issue24340] co_stacksize estimate can be highly off
In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za>
Message-ID: <1514837437.2.0.467229070634.issue24340@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tests originally based on Antoine's tests added for PR 2827.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24340>
_______________________________________

From report at bugs.python.org  Mon Jan  1 15:13:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 20:13:02 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514837582.9.0.467229070634.issue17611@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> It would be nice to know if it's able to fix the stack size issues as in the following tests:

I just worked on it. See issue24340.

----------
dependencies: +co_stacksize estimate can be highly off

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 16:11:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jan 2018 21:11:19 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514841079.66.0.467229070634.issue17611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I just worked on it.

I meant Mark's PR :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 16:27:22 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jan 2018 21:27:22 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1514842042.49.0.467229070634.issue32474@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Agreed.  I don't think there is sufficient motivation for doing this, and there are downsides as Eric has pointed out.  Rejecting.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 16:40:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 21:40:27 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514842827.84.0.467229070634.issue17611@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4951

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Mon Jan  1 17:03:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 22:03:27 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
Message-ID: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed patch moves jumps optimization from the peepholer to the compiler. The optimization is performed for lists of instructions before generating concrete bytecode and is not restricted by the size of bytecode instructions. It allows to optimize more long chains of jumps.

This is a step to getting rid of the peepholer.

----------
components: Interpreter Core
messages: 309351
nosy: benjamin.peterson, brett.cannon, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Move jumps optimization from the peepholer to the compiler
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Mon Jan  1 17:06:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 22:06:04 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1514844364.47.0.467229070634.issue32477@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4952
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Mon Jan  1 17:52:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 22:52:03 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
Message-ID: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

'break' and 'return' are never used inside 'finally' clause in the stdlib. Therefore these cases are not covered by tests even implicitly. The proposed patch adds explicit tests for them.

'continue' inside 'finally' clause currently is prohibited (see issue1542451) and there are tests for this.

----------
components: Tests
messages: 309352
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add tests for 'break' and 'return' inside 'finally' clause
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Mon Jan  1 17:53:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 22:53:58 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514847238.58.0.467229070634.issue32478@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4953
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Mon Jan  1 18:29:27 2018
From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=)
Date: Mon, 01 Jan 2018 23:29:27 +0000
Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs
In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za>
Message-ID: <1514849367.37.0.467229070634.issue32453@psf.upfronthosting.co.za>


Niklas Hamb?chen <nh2 at deditus.de> added the comment:

A better location to view the whole coreutils thread is:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29921

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32453>
_______________________________________

From report at bugs.python.org  Mon Jan  1 18:59:21 2018
From: report at bugs.python.org (Emily Morehouse)
Date: Mon, 01 Jan 2018 23:59:21 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514851161.66.0.467229070634.issue32452@psf.upfronthosting.co.za>


Change by Emily Morehouse <emily at cuttlesoft.com>:


----------
keywords: +patch
pull_requests: +4954
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Mon Jan  1 19:03:34 2018
From: report at bugs.python.org (Emily Morehouse)
Date: Tue, 02 Jan 2018 00:03:34 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514851414.12.0.467229070634.issue32452@psf.upfronthosting.co.za>


Change by Emily Morehouse <emily at cuttlesoft.com>:


----------
nosy: +emilyemorehouse

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Mon Jan  1 19:38:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 00:38:37 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514853517.68.0.467229070634.issue32478@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7cc42c356b0dc5ad9eaa9392789e84bd4aa1c7de by Serhiy Storchaka in branch 'master':
bpo-32478: Add tests for 'break' and 'return' inside 'finally' clause. (#5078)
https://github.com/python/cpython/commit/7cc42c356b0dc5ad9eaa9392789e84bd4aa1c7de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Mon Jan  1 19:39:50 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jan 2018 00:39:50 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514853590.88.0.467229070634.issue32478@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4955

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Mon Jan  1 20:34:57 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jan 2018 01:34:57 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514856897.27.0.467229070634.issue32452@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:


New changeset f190eb59e60e2ae7a7cbd396458389a7a076e0d3 by R. David Murray (Emily Morehouse) in branch 'master':
bpo-32452: clarify term 'brackets' in generator tutorial (#5079)
https://github.com/python/cpython/commit/f190eb59e60e2ae7a7cbd396458389a7a076e0d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Mon Jan  1 20:36:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jan 2018 01:36:07 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514856967.5.0.467229070634.issue32452@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4956

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Mon Jan  1 20:37:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jan 2018 01:37:07 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514857027.78.0.467229070634.issue32452@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4957

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Tue Jan  2 02:04:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jan 2018 07:04:07 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514876647.77.0.467229070634.issue32478@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4958

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Tue Jan  2 02:13:01 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Jan 2018 07:13:01 +0000
Subject: [issue32445] Skip creating redundant wrapper functions in
 ExitStack.callback
In-Reply-To: <1514554664.91.0.213398074469.issue32445@psf.upfronthosting.co.za>
Message-ID: <1514877181.97.0.467229070634.issue32445@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, you're right, I wasn't thinking clearly when I filed this - the correct public API method to transfer existing exit stack entries to a new stack would be "ExitStack.push()".

I'll make a note of that on the original issue.

----------
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32445>
_______________________________________

From report at bugs.python.org  Tue Jan  2 02:21:53 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Jan 2018 07:21:53 +0000
Subject: [issue32145] Wrong ExitStack Callback recipe
In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za>
Message-ID: <1514877713.35.0.467229070634.issue32145@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As per the comment at https://bugs.python.org/issue32445#msg309356, there's a bug in my suggested changes to `ExitStack.pop_all()`: the right method to call is ExitStack.push(), *not* ExitStack.callback() (the latter adds a wrapper function to make the signatures match, but our stored callbacks all already have the right signature).

I'm not too fussy about the details of the docstring, but we need to be careful about the guarantees we make to ExitStack subclasses: if the docstring implies that "target.push()" will always be called, then we need to limit the stack stealing behaviour to actual ExitStack instances (which may be a good idea anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32145>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:20:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 08:20:15 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514881215.09.0.467229070634.issue32478@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset aea95c2fbdec05dddd8b833a74eeb7ec8dc69706 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-32478: Add tests for 'break' and 'return' inside 'finally' clause. (GH-5078) (#5083)
https://github.com/python/cpython/commit/aea95c2fbdec05dddd8b833a74eeb7ec8dc69706


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:22:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 08:22:14 +0000
Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs
In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za>
Message-ID: <1514881334.16.0.467229070634.issue32453@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks for your investigations Niklas. I ran my benchmark on a spinning disk, but significant nonlinearity is observed only for the size of directory around 1000000 and more. And yes, sorting by inode number helps.

$ for j in 1 2 3 4 6 8 12 16; do i=$((j*100000)); mkdir x; (cd x && seq $i|xargs touch); env time -f "%e $i" python3.7-unpatched -c 'import shutil; shutil.rmtree("x")'; done
1.01 100000
3.80 200000
3.64 300000
4.89 400000
8.72 600000
11.86 800000
56.80 1200000
209.82 1600000

$ for j in 1 2 3 4 6 8 12 16; do i=$((j*100000)); mkdir x; (cd x && seq $i|xargs touch); env time -f "%e $i" python3.7-patched -c 'import shutil; shutil.rmtree("x")'; done
0.97 100000
2.42 200000
3.84 300000
4.48 400000
7.07 600000
10.01 800000
15.53 1200000
23.24 1600000

$ for j in 1 2 3 4 6 8 12 16; do i=$((j*100000)); mkdir x; (cd x && seq $i|xargs touch); env time -f "%e $i" env rm -rf x; done
0.68 100000
1.34 200000
2.10 300000
3.95 400000
5.95 600000
10.28 800000
47.66 1200000
89.32 1600000

On an SSD:

$ for j in 1 2 3 4 6 8 12 16; do i=$((j*100000)); mkdir x; (cd x && seq $i|xargs touch); env time -f "%e $i" python3.7-unpatched -c 'import shutil; shutil.rmtree("x")'; done
1.00 100000
1.93 200000
2.90 300000
4.98 400000
7.05 600000
9.87 800000
21.45 1200000
36.19 1600000

$ for j in 1 2 3 4 6 8 12 16; do i=$((j*100000)); mkdir x; (cd x && seq $i|xargs touch); env time -f "%e $i" python3.7-patched -c 'import shutil; shutil.rmtree("x")'; done
0.96 100000
1.99 200000
3.09 300000
4.85 400000
7.55 600000
9.44 800000
16.03 1200000
21.28 1600000

$ for j in 1 2 3 4 6 8 12 16; do i=$((j*100000)); mkdir x; (cd x && seq $i|xargs touch); env time -f "%e $i" env rm -rf x; done
0.67 100000
1.38 200000
2.41 300000
2.82 400000
5.24 600000
7.02 800000
18.60 1200000
30.58 1600000

Interesting that patched Python is faster than 'rm' (GNU coreutils 8.26) for large numbers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32453>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:30:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 08:30:42 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514881842.37.0.467229070634.issue32478@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4959

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:48:08 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 02 Jan 2018 08:48:08 +0000
Subject: [issue32479] inconsistent ImportError message executing same import
 statement
Message-ID: <1514882888.25.0.467229070634.issue32479@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

While debugging a problem in my job I find an odd case about import, it could be reduced to the following tracebacks:

>>> from keystone.assignment import schema
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/keystone/assignment/__init__.py", line 15, in <module>
    from keystone.assignment import controllers  # noqa
  File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 26, in <module>
    from keystone.common import controller
  File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 24, in <module>
    from keystone.common import authorization
  File "/usr/lib/python2.7/site-packages/keystone/common/authorization.py", line 23, in <module>
    from keystone.models import token_model
  File "/usr/lib/python2.7/site-packages/keystone/models/token_model.py", line 15, in <module>
    from keystoneclient.common import cms
ImportError: No module named keystoneclient.common
>>> from keystone.assignment import schema
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/keystone/assignment/__init__.py", line 15, in <module>
    from keystone.assignment import controllers  # noqa
  File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 25, in <module>
    from keystone.assignment import schema
ImportError: cannot import name schema

keystoneclient is deliberately not installed. I think it should always report keystoneclient.common could not be found which reveals the root causes. But only the first time it does so. Later tries it always report cannot import schema.

The reason of this behaviour is that first time although keystone.assignment import fails but keystone.assignment.schema is successfully installed in sys.modules. And then, in ensure_fromlist, it calls import_submodule which returns the module in sys.modules, without set schema attribute to keystone.assignment. So it then fails in import_from for not able to get the attribute.

It could be simply reproduced by the following package structure:

test
|-- a.py
|-- b.py
`-- __init__.py

__init__.py:
from test import a

a.py: 
from test import b
import modulenotexisting

b.py: #emtpy

>>> import test
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test/__init__.py", line 1, in <module>
    from test import a
  File "test/a.py", line 2, in <module>
    import dddddddddd
ImportError: No module named dddddddddd
>>> import test
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test/__init__.py", line 1, in <module>
    from test import a
  File "test/a.py", line 1, in <module>
    from test import b
ImportError: cannot import name b

Python3 doesn't suffer this problem, at least for 3.7.

I don't know this should be identified as a bug or not. But this does bring me trouble debugging problems and lead to confusions because it doesn't  tell users the real module can't be imported.

----------
components: Interpreter Core
messages: 309360
nosy: brett.cannon, eric.snow, ncoghlan, xiang.zhang
priority: normal
severity: normal
status: open
title: inconsistent ImportError message executing same import statement
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32479>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:56:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 08:56:47 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514883407.45.0.467229070634.issue32478@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b495377a8bdd711e9aab0885c60cd148284156e8 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-32478: Add tests for 'break' and 'return' inside 'finally' clause. (GH-5078). (#5084)
https://github.com/python/cpython/commit/b495377a8bdd711e9aab0885c60cd148284156e8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:59:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 08:59:00 +0000
Subject: [issue32478] Add tests for 'break' and 'return' inside 'finally'
 clause
In-Reply-To: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>
Message-ID: <1514883540.69.0.467229070634.issue32478@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:59:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 08:59:44 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1514883584.39.0.467229070634.issue32477@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +inada.naoki, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Tue Jan  2 04:18:02 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 02 Jan 2018 09:18:02 +0000
Subject: [issue32472] Mention of __await__ missing in Coroutine Abstract
 Methods
In-Reply-To: <1514786801.71.0.467229070634.issue32472@psf.upfronthosting.co.za>
Message-ID: <1514884682.38.0.467229070634.issue32472@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

`Coroutine` is inherited from `Awaitable`, that's why inherited abstract `__await__` method is present.

It **is** consistent with the rest of the document: e.g. Mapping has no `__len__` method but inherits it from Collection which in turn is inherited from Sized

----------
nosy: +asvetlov
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32472>
_______________________________________

From report at bugs.python.org  Tue Jan  2 04:32:38 2018
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 02 Jan 2018 09:32:38 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1514829251.29.0.467229070634.issue17611@psf.upfronthosting.co.za>
Message-ID: <34e0f2fa-9bc5-3fcd-d6e8-32d4aede09c6@hotpy.org>


Mark Shannon <mark at hotpy.org> added the comment:

On 01/01/18 17:54, Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> I took a quick look at Mark's PR.  The main thing going for it IMHO is that it produces simpler bytecode: it removes the complicated with/finally-related opcodes, while Serhiy's has non-trivial END_FINALLY and POP_FINALLY.
> 
> It would be nice to know if it's able to fix the stack size issues as in the following tests:
> https://github.com/python/cpython/pull/5006/files?diff=unified#diff-dae68b96e8fdcb924e1ea46c31f51aec

Yes, it can. The key to determining a correct stack size is that each 
bytecode has a fixed stack delta for each exiting edge.
For example, FOR_ITER is good because it has a delta of 0 when entering 
the body and a delta of -1 when leaving the loop.
But (the old) WITH_CLEANUP_START is bad because it has a variable delta.

With fixed deltas, it is not too hard to construct an algorithm to 
determine the correct stack size. The presence of JSR-style finally 
blocks complicates things a little, but not that much.

An outline algorithm would be:
     Find all "finally" subgraphs, so as to distinguish them from the 
main CFG - It might be easiest to do this by marking the basic blocks 
where generating the code.
     For each subgraph compute max-depth, by keeping a running total of
     depth. Jumps to finally blocks should not alter the depth, but 
would potentially increase the max-depth.
     The max-depth for the main CFG is the stack depth for the function.

> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue17611>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  2 04:56:21 2018
From: report at bugs.python.org (Ajay)
Date: Tue, 02 Jan 2018 09:56:21 +0000
Subject: [issue32480] czipfile installation failure
Message-ID: <1514886981.07.0.467229070634.issue32480@psf.upfronthosting.co.za>


New submission from Ajay <mail2.hn at gmail.com>:

pip installation for czipfile is failing with compilation error (as below)

Command Execute:
pip install --no-cache-dir czipfile

Error:
Collecting czipfile
  Downloading czipfile-1.0.0.tar.gz (144kB)
    100% |????????????????????????????????| 153kB 726kB/s
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\503022~1\AppData\Local\Temp\pip-build-3uthum1g\czipfile\setup.py", line 18
        print "cython not found, using previously-cython'd .c file."
                                                                   ^
    SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "cython not found, using previously-cython'd .c file.")?

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in...

----------
components: Library (Lib)
messages: 309364
nosy: ajayhn
priority: normal
severity: normal
status: open
title: czipfile installation failure
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32480>
_______________________________________

From report at bugs.python.org  Tue Jan  2 05:42:25 2018
From: report at bugs.python.org (Jacob Jorvang)
Date: Tue, 02 Jan 2018 10:42:25 +0000
Subject: =?utf-8?q?=5Bissue32481=5D_Hitting_the_acute_accent_=C2=B4_button_on_a_Da?=
 =?utf-8?q?nish_keyboard_causes_Python_with_tkinter_to_crash_immediately?=
 =?utf-8?q?=2E?=
Message-ID: <1514889745.69.0.467229070634.issue32481@psf.upfronthosting.co.za>


New submission from Jacob Jorvang <jacobjorvang at gmail.com>:

Hitting the acute accent ? button on a Danish keyboard causes Python with tkinter to crash immediately. This is a problem because the key is just left of the backspace key.
Using:
Python 3.6.3
MacOS version of tkinter
ActiveTCL 8.6.4.1

MacBook-Pro:~ username$ python3 --version
Python 3.6.3
MacBook-Pro:~ username$ pip3 list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
altgraph (0.15)
future (0.16.0)
lxml (4.1.1)
macholib (1.9)
modulegraph (0.16)
pefile (2017.11.5)
pip (9.0.1)
py2app (0.14)
PyInstaller (3.4.dev0+ab8fd9753)
setuptools (28.8.0)
xmltodict (0.11.0)
MacBook-Pro:~ username$ python3 -c 'import tkinter; tkinter.Text().pack(); tkinter.mainloop()'
2018-01-02 11:31:53.488 Python[80562:5642430] *** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000010010e00b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x0000000100de0c76 objc_exception_throw + 48
	2   CoreFoundation                      0x000000010019fc9d +[NSException raise:format:] + 205
	3   CoreFoundation                      0x0000000100089f26 -[__NSCFString characterAtIndex:] + 102
	4   Tk                                  0x0000000103ef1353 TkpInitKeymapInfo + 731
	5   Tk                                  0x0000000103ef71b1 Tk_MacOSXSetupTkNotifier + 798
	6   Tcl                                 0x0000000103dd1a50 Tcl_DoOneEvent + 300
	7   _tkinter.cpython-36m-darwin.so      0x0000000101fedaa1 _tkinter_tkapp_mainloop + 209
	8   Python                              0x00000001007bd7b8 _PyCFunction_FastCallDict + 552
	9   Python                              0x0000000100847164 call_function + 612
	10  Python                              0x0000000100848b74 _PyEval_EvalFrameDefault + 5604
	11  Python                              0x0000000100846e21 fast_function + 465
	12  Python                              0x000000010084714b call_function + 587
	13  Python                              0x0000000100848b74 _PyEval_EvalFrameDefault + 5604
	14  Python                              0x0000000100846500 _PyEval_EvalCodeWithName + 2720
	15  Python                              0x00000001008466a4 PyEval_EvalCode + 100
	16  Python                              0x0000000100883747 PyRun_StringFlags + 183
	17  Python                              0x00000001008837d1 PyRun_SimpleStringFlags + 65
	18  Python                              0x000000010089c304 Py_Main + 1812
	19  Python                              0x0000000100000dfe Python + 3582
	20  Python                              0x0000000100000c34 Python + 3124
	21  ???                                 0x0000000000000003 0x0 + 3
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

----------
components: Tkinter
messages: 309365
nosy: Jacob Jorvang
priority: normal
severity: normal
status: open
title: Hitting the acute accent ? button on a Danish keyboard causes Python with tkinter to crash immediately.
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32481>
_______________________________________

From report at bugs.python.org  Tue Jan  2 06:24:27 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jan 2018 11:24:27 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514892267.23.0.467229070634.issue17611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With fixed deltas, it is not too hard to construct an algorithm to 
determine the correct stack size. The presence of JSR-style finally 
blocks complicates things a little, but not that much.

Any chance you can put that patch somewhere to get an idea of the additional complexity?

I'd like to gauge the total complexity of each approach including the stack size computation fix (since fixing that issue is one of the end goals).  Also, that would help compare your PR and Serhiy's on more equal terms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  2 06:26:15 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jan 2018 11:26:15 +0000
Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs
In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za>
Message-ID: <1514892375.76.0.467229070634.issue32453@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, so `rm -rf` is quadratic on my SSD too...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32453>
_______________________________________

From report at bugs.python.org  Tue Jan  2 06:31:39 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jan 2018 11:31:39 +0000
Subject: [issue32480] czipfile installation failure
In-Reply-To: <1514886981.07.0.467229070634.issue32480@psf.upfronthosting.co.za>
Message-ID: <1514892699.93.0.467229070634.issue32480@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is an issue with the czipfile package on PyPI (<https://pypi.python.org/pypi/czipfile>) and not a bug in CPython.

Note that czipfile appears to support Python 2 only, which would explain the error message you are getting.

----------
nosy: +ronaldoussoren
resolution:  -> not a bug
stage:  -> resolved
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32480>
_______________________________________

From report at bugs.python.org  Tue Jan  2 06:48:01 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 02 Jan 2018 11:48:01 +0000
Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c:
 Function argument assignment between types "unsigned long" and "struct
 fsid_t" is not allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1514893681.97.0.467229070634.issue32390@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Can you please post the definition of the statvfs structure on AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Tue Jan  2 08:36:12 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jan 2018 13:36:12 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514900172.62.0.467229070634.issue32452@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:


New changeset f24c1857a8a1ba3efb3f957d43371bc9499e3c86 by R. David Murray (Miss Islington (bot)) in branch '3.6':
bpo-32452: clarify term 'brackets' in generator tutorial (GH-5079) (#5081)
https://github.com/python/cpython/commit/f24c1857a8a1ba3efb3f957d43371bc9499e3c86


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Tue Jan  2 08:40:08 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jan 2018 13:40:08 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514900408.81.0.467229070634.issue32452@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It looks like the docs job hung on the 2.7 backport, but I don't see how to restart it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Tue Jan  2 09:11:53 2018
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 02 Jan 2018 14:11:53 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514902313.37.0.467229070634.issue17611@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

I've added a commit to compute the stack size.
It should compute the exact stack size in all cases, and thus fix bpo-24340.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:15:27 2018
From: report at bugs.python.org (Steve Margetts)
Date: Tue, 02 Jan 2018 15:15:27 +0000
Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1
In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za>
Message-ID: <1514906127.46.0.467229070634.issue32447@psf.upfronthosting.co.za>


Steve Margetts <stevemargetts at me.com> added the comment:

OK, so I created a profile for my son (single name without any spaces!) and that seems to allow both Python and IDLE to work fine. I'll try and sort out my profile slow time - it doesn't seem to be causing any other issues just now. Thanks for the guidance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32447>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:20:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 15:20:43 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
Message-ID: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR:

* Fixes Py3k warnings introduced by recent backports.
* Backports tests from Python 3.
* Improve handling of Py3k warnings. They are now checked only for statements that emit them instead of silencing for the whole module.
* Fixes few minor defects that can lead to hiding expected errors.

----------
components: Tests
messages: 309374
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve tests for syntax and grammar in 2.7
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:22:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 15:22:48 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
In-Reply-To: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>
Message-ID: <1514906568.29.0.467229070634.issue32482@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4960
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:23:11 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 02 Jan 2018 15:23:11 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514906591.34.0.467229070634.issue32452@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

I clicked the "Details" link and restarted the build from there.
Closing and reopening the PR will also restart the build.

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:24:47 2018
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 02 Jan 2018 15:24:47 +0000
Subject: [issue27643] test_ctypes fails on AIX with xlc
In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za>
Message-ID: <1514906687.88.0.467229070634.issue27643@psf.upfronthosting.co.za>


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


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27643>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:25:00 2018
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 02 Jan 2018 15:25:00 +0000
Subject: [issue28290] BETA report: Python-3.6 build messages to stderr: AIX
 and "not GCC"
In-Reply-To: <1475001330.34.0.107474417097.issue28290@psf.upfronthosting.co.za>
Message-ID: <1514906700.16.0.467229070634.issue28290@psf.upfronthosting.co.za>


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


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28290>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:25:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 15:25:45 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
In-Reply-To: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>
Message-ID: <1514906745.66.0.467229070634.issue32482@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4961

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:27:36 2018
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 02 Jan 2018 15:27:36 +0000
Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c:
 Function argument assignment between types "unsigned long" and "struct
 fsid_t" is not allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1514906856.59.0.467229070634.issue32390@psf.upfronthosting.co.za>


David Edelsohn <dje.gcc at gmail.com> added the comment:

struct statvfs {
        ulong_t    f_bsize;     /* preferred file system block size          */
        ulong_t    f_frsize;    /* fundamental file system block size        */
        fsblkcnt_t f_blocks;    /* total # of blocks of f_frsize in fs       */ 
        fsblkcnt_t f_bfree;     /* total # of free blocks                    */
        fsblkcnt_t f_bavail;    /* # of blocks available to non super user   */
        fsfilcnt_t f_files;     /* total # of file nodes (inode in JFS)      */
        fsfilcnt_t f_ffree;     /* total # of free file nodes                */
        fsfilcnt_t f_favail;    /* # of nodes available to non super user    */
#ifdef _ALL_SOURCE
        fsid_t     f_fsid;      /* file system id                            */
#else
        ulong_t    f_fsid;      /* file system id                            */
#ifndef __64BIT__
        ulong_t    f_fstype;    /* file system type                          */
#endif
#endif  /* _ALL_SOURCE */
        char       f_basetype[_FSTYPSIZ]; /* Filesystem type name (eg. jfs)  */
        ulong_t    f_flag;      /* bit mask of flags                         */
        ulong_t    f_namemax;   /* maximum filename length                   */
        char       f_fstr[32];  /* filesystem-specific string */
        ulong_t    f_filler[16];/* reserved for future use                   */
};

----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:28:28 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 02 Jan 2018 15:28:28 +0000
Subject: [issue32461] the first build after a change to Makefile.pre.in uses
 the old Makefile
In-Reply-To: <1514706812.13.0.467229070634.issue32461@psf.upfronthosting.co.za>
Message-ID: <1514906908.74.0.467229070634.issue32461@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Hum, GNU make does re-execute the updated Makefile [1] after the 'Makefile' target has been remade.
The problem occurs though with the other make variants that do not have this feature.

[1] This may be shown by updating Makefile.pre.in and adding an 'echo' recipe in the 'Python/sysmodule.o' target for example, or by running 'make -d' after Makefile.pre.in has been modified and confirming that the command prints "Re-executing[1]: make -d".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32461>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:30:42 2018
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 02 Jan 2018 15:30:42 +0000
Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c:
 Function argument assignment between types "unsigned long" and "struct
 fsid_t" is not allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1514907042.87.0.467229070634.issue32390@psf.upfronthosting.co.za>


David Edelsohn <dje.gcc at gmail.com> added the comment:

/* typedef for the File System Identifier (fsid).  This must correspond 
 * to the "struct fsid" structure in _ALL_SOURCE below.
 */
typedef struct fsid_t {
#ifdef __64BIT_KERNEL
        unsigned long val[2];
#else  /* __64BIT_KERNEL */
#ifdef _ALL_SOURCE
        unsigned int val[2];
#else  /* _ALL_SOURCE */
        unsigned int __val[2];
#endif /* _ALL_SOURCE */
#endif /* __64BIT_KERNEL */
} fsid_t;

#ifdef _KERNEL
typedef struct fsid32_t {
        unsigned int val[2];
} fsid32_t;
#endif /* __64BIT_KERNEL */

typedef struct fsid64_t {
#if defined(_ALL_SOURCE) && (defined(__64BIT__) || defined(_LONG_LONG))
        uint64_t val[2];
#else /* _ALL_SOURCE */
        uint32_t __val[4];
#endif /* _ALL_SOURCE */
} fsid64_t;

/* typedef for the File System Identifier (fsid) */
struct fsid {
#ifndef __64BIT_KERNEL
        unsigned int    val[2];
#else
        unsigned long   val[2];
#endif
};

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:39:34 2018
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 02 Jan 2018 15:39:34 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1514907574.45.0.467229070634.issue28009@psf.upfronthosting.co.za>


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


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:40:35 2018
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 02 Jan 2018 15:40:35 +0000
Subject: [issue10656] "Out of tree" build fails on AIX
In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>
Message-ID: <1514907635.9.0.467229070634.issue10656@psf.upfronthosting.co.za>


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


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10656>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:40:52 2018
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 02 Jan 2018 15:40:52 +0000
Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and
 later)
In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za>
Message-ID: <1514907652.19.0.467229070634.issue27435@psf.upfronthosting.co.za>


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


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27435>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:42:17 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jan 2018 15:42:17 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514907737.98.0.467229070634.issue32452@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:


New changeset 0e0d1017a4c8ad6f77ee42d7b640463058037f62 by R. David Murray (Miss Islington (bot)) in branch '2.7':
bpo-32452: clarify term 'brackets' in generator tutorial (GH-5079) (#5082)
https://github.com/python/cpython/commit/0e0d1017a4c8ad6f77ee42d7b640463058037f62


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:44:17 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jan 2018 15:44:17 +0000
Subject: [issue32480] czipfile installation failure
In-Reply-To: <1514886981.07.0.467229070634.issue32480@psf.upfronthosting.co.za>
Message-ID: <1514907857.08.0.467229070634.issue32480@psf.upfronthosting.co.za>


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


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32480>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:52:28 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jan 2018 15:52:28 +0000
Subject: [issue32452] Brackets and Parentheses used in an ambiguous way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514908348.23.0.467229070634.issue32452@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, Mariatta.  I did click on the details link, so either the restart link isn't obvious or I don't have the correct permissions to do a restart :)

And thanks Emily for doing the PR.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:59:17 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Jan 2018 15:59:17 +0000
Subject: [issue32479] inconsistent ImportError message executing same import
 statement
In-Reply-To: <1514882888.25.0.467229070634.issue32479@psf.upfronthosting.co.za>
Message-ID: <1514908757.13.0.467229070634.issue32479@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Since the problem is specific to Python 2.7 and has been resolved in the importlib based import implementation, I'm inclined to close this as "Won't Fix".

The only reason I haven't is that if someone really wanted to dig into the Python 2.7 import implementation and figure out how to improve the situation, I'd actually be willing to review the patch.

Alternatively, it might be worthwhile for OpenStack to investigate migrating over to importlib2 for their Python 2.7 support (or at least supporting it as a debugging option).

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32479>
_______________________________________

From report at bugs.python.org  Tue Jan  2 11:07:23 2018
From: report at bugs.python.org (Iago-lito -)
Date: Tue, 02 Jan 2018 16:07:23 +0000
Subject: [issue32483] Misleading reflective behaviour due to PEP 3131 NFKC
 identifiers normalization.
Message-ID: <1514909242.99.0.467229070634.issue32483@psf.upfronthosting.co.za>


New submission from Iago-lito - <iago.bonnici at gmail.com>:

Consistent with [PEP 3131](https://www.python.org/dev/peps/pep-3131/) and NFKC normalization of identifiers, these two last lines yield an error, since `?` (U+1D70F) is automatically converted to `?` (U+03C4).

    class Base(object):
        def __init__(self):
            self.? = 5 # defined with U+1D70F

    a = Base()
    print(a.?)     # 5             # (U+1D70F) expected and intuitive
    print(a.?)     # 5 as well     # (U+03C4)  normalized version, okay.
    d = a.__dict__ # {'?':  5}     # (U+03C4)  still normalized version
    print(d['?'])  # 5             # (U+03C4)  consistent with normalization
    assert hasattr(a, '?')         # (U+03C4)  consistent with normalization
    # But if I want to retrieve it the way I entered it because I can type (U+1D70F)
    print(d['?'])  # KeyError: '?' # (U+1D70F) counterintuitive
    assert hasattr(a, '?') # Fails # (U+1D70F) counterintuitive

I've described and undestood the problem in [this post](https://stackoverflow.com/questions/48063082/).

Nothing is unconsistent here. However, I am worried that:

- this behaviour might be counterintuitive and misleading, especially if it occurs that the character user can easily enter for some reason (e.g. U+1D70F) is not equivalent to its NFKC normalization (e.g. U+03C4)

- this behaviours makes it more difficult to enjoy python's reflective `__dict__`, `hasattr` and `getattr` features in this particular case.

Maybe it is user's responsibility to be aware of this limitation, and to keep considering utf-8 coding a bad practice. In this case, maybe this particular reflective limitation could be made explicit in PEP 3131.

Or maybe it is python's responsibility to ensure intuitive and consistent behaviour even in tricky-unicode-cases. So reflective features like `__dict__.__getitem__`, `hasattr` or `getattr` would NFKC-convert their arguments before searching just like `a.?` does, so that:

    getattr(a, '?') is gettatr(a, '?')

always yields True.

I actually have no idea of the philosophy to stick to. And the only purpose of this post is to inform the community about this particular, low-priority case.

Thank you for supporting Python anyway, cheers for your patience.. and happy 2018 to everyone :)


--
Iago-lito

----------
components: Unicode
messages: 309382
nosy: Iago-lito -, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Misleading reflective behaviour due to PEP 3131 NFKC identifiers normalization.
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32483>
_______________________________________

From report at bugs.python.org  Tue Jan  2 11:23:28 2018
From: report at bugs.python.org (Iago-lito -)
Date: Tue, 02 Jan 2018 16:23:28 +0000
Subject: [issue32483] Misleading reflective behaviour due to PEP 3131 NFKC
 identifiers normalization.
In-Reply-To: <1514909242.99.0.467229070634.issue32483@psf.upfronthosting.co.za>
Message-ID: <1514910208.16.0.467229070634.issue32483@psf.upfronthosting.co.za>


Iago-lito - <iago.bonnici at gmail.com> added the comment:

I just found out about [this](https://bugs.python.org/issue13793) very close issue. Much of the philosophy has been made very clear there.

Since the solution to issue13793 is to *document* much this NFKC normalization. Then I think I'd be a good thing to make an explicit statement about these particular reflective limitations in PEP 3131 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32483>
_______________________________________

From report at bugs.python.org  Tue Jan  2 11:24:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 16:24:54 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1514910294.79.0.467229070634.issue32346@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

./python -m timeit -- "class A: pass"
- before: 6.63 usec per loop
- after:  5.41 usec per loop

./python -m timeit -s "class A: pass" -- "class B(A): pass"
- before: 7.04 usec per loop
- after:  4.91 usec per loop

./python -m timeit -s "class A: pass" -s "class B(A): pass" -- "class C(B): pass"
- before: 8.24 usec per loop
- after:  5.09 usec per loop

./python -m timeit -s "class A: pass" -s "class B(A): pass" -s "class C(B): pass" -- "class D(C): pass"
- before: 9.59 usec per loop
- after:  5.29 usec per loop

./python -m timeit -s "class A: pass" -s "class B(A): pass" -s "class C(B): pass" -s "class D(C): pass" -- "class E(D): pass"
- before: 10.9 usec per loop
- after:  5.45 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Tue Jan  2 12:13:35 2018
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 02 Jan 2018 17:13:35 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1514913215.86.0.467229070634.issue17611@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

> It looks like the build core dumped on Travis-CI

I failed to account for the extra stuff left on the stack when handling exceptions and jumping out of a finally block due to a `break`. Caught by Serhiy's tests in https://github.com/python/cpython/pull/5078.
I could add a work around, but it would be a bit hacky.

I'm now convinced that code duplication is the only way to do this properly. The only real advantage of JSR-style finally blocks is the ease of implementation of `frame.set_lineno()`.

Rather than go around in circles any more, I suggest that we merge Serhiy's PR (PR 5006). I can then cherry-pick my commits to clean up the implementation of the `with` statement (as a new PR).

I then plan to implement `try-finally` using code duplication, but that might not make it into 3.7 and we shouldn't hold up this issue any longer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  2 12:25:49 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Jan 2018 17:25:49 +0000
Subject: [issue31530] Python 2.7 readahead feature of file objects is not
 thread safe
In-Reply-To: <1505914032.54.0.91752475423.issue31530@psf.upfronthosting.co.za>
Message-ID: <1514913949.5.0.467229070634.issue31530@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset dbf52e02f18dac6f5f0a64f78932f3dc6efc056b by Benjamin Peterson in branch '2.7':
bpo-31530: fix crash when multiple threads iterate over a file, round 2 (#5060)
https://github.com/python/cpython/commit/dbf52e02f18dac6f5f0a64f78932f3dc6efc056b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31530>
_______________________________________

From report at bugs.python.org  Tue Jan  2 12:26:55 2018
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Tue, 02 Jan 2018 17:26:55 +0000
Subject: [issue27632] build on AIX fails when builddir != srcdir,
 more than bad path to ld_so_aix
In-Reply-To: <1469608112.86.0.803958819971.issue27632@psf.upfronthosting.co.za>
Message-ID: <1514914015.68.0.467229070634.issue27632@psf.upfronthosting.co.za>


Eric N. Vander Weele <ericvw at gmail.com> added the comment:

I can also confirm that OOT builds work as well. https://github.com/python/cpython/commit/395733d46bbc23d2f559eba4e5f75783f9bca6f1#diff-6fd819bc2460d3a50e561d2da6c09c02 addressed fixing this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27632>
_______________________________________

From report at bugs.python.org  Tue Jan  2 12:31:30 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Jan 2018 17:31:30 +0000
Subject: [issue31530] Python 2.7 readahead feature of file objects is not
 thread safe
In-Reply-To: <1505914032.54.0.91752475423.issue31530@psf.upfronthosting.co.za>
Message-ID: <1514914290.84.0.467229070634.issue31530@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31530>
_______________________________________

From report at bugs.python.org  Tue Jan  2 12:32:12 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jan 2018 17:32:12 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1514913215.86.0.467229070634.issue17611@psf.upfronthosting.co.za>
Message-ID: <be9456fc-e3c4-2e74-24e5-3fc001e90f49@free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le 02/01/2018 ? 18:13, Mark Shannon a ?crit?:
> 
> Rather than go around in circles any more, I suggest that we merge Serhiy's PR (PR 5006). I can then cherry-pick my commits to clean up the implementation of the `with` statement (as a new PR).

Fair enough. I'm making a final review round on Serhiy's PR and
hopefully this will be in.

Also looking forward to the cleanup followup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  2 12:52:57 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Jan 2018 17:52:57 +0000
Subject: [issue32483] Misleading reflective behaviour due to PEP 3131 NFKC
 identifiers normalization.
In-Reply-To: <1514909242.99.0.467229070634.issue32483@psf.upfronthosting.co.za>
Message-ID: <1514915577.26.0.467229070634.issue32483@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We don't generally update finalized PEPs. The official documentation for a feature is in the Python docs. Feel free to propose a PR if you think it could be improved.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> hasattr, delattr, getattr fail with unnormalized names

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32483>
_______________________________________

From report at bugs.python.org  Tue Jan  2 14:30:14 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Jan 2018 19:30:14 +0000
Subject: [issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3
In-Reply-To: <1514651174.11.0.213398074469.issue32456@psf.upfronthosting.co.za>
Message-ID: <1514921414.89.0.467229070634.issue32456@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

My guess is there is no message because in Python 3, errors are encoded according to PYTHONIOENCODING. Perhaps it works as you expect if you bypass sys.excepthook:

$ PYTHONIOENCODING=undefined python -c 'import sys, os; sys.excepthook = lambda *exc: os.write(2, ascii(exc).encode()); print(u"abc")'
(<class 'UnicodeError'>, UnicodeError('undefined encoding',), <traceback object at 0xb7037b94>)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32456>
_______________________________________

From report at bugs.python.org  Tue Jan  2 14:37:13 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Jan 2018 19:37:13 +0000
Subject: [issue32413] Document that locals() may return globals()
In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za>
Message-ID: <1514921833.74.0.467229070634.issue32413@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

FWIW a few years ago I wrote a patch for Issue 17546 that documents three personalities of ?locals?, including:

* At the module level, the dictionary returned is the global symbol table, also returned by :func:`globals`.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32413>
_______________________________________

From report at bugs.python.org  Tue Jan  2 14:39:18 2018
From: report at bugs.python.org (sds)
Date: Tue, 02 Jan 2018 19:39:18 +0000
Subject: [issue32484] ImportError for gdbm 1.14
Message-ID: <1514921958.6.0.467229070634.issue32484@psf.upfronthosting.co.za>


New submission from sds <sds at gnu.org>:

After upgrading to gdbm stable 1.14, I get this:
```
>>> import gdbm
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dlopen(/.../lib/python2.7/lib-dynload/gdbm.so, 2): Symbol not found: _gdbm_errno
  Referenced from: /.../lib/python2.7/lib-dynload/gdbm.so
  Expected in: /usr/local/opt/gdbm/lib/libgdbm.4.dylib
 in /.../lib/python2.7/lib-dynload/gdbm.so
```
This is probably related to this change:
```
* Make gdbm_error global thread safe.
```
(https://lists.gnu.org/archive/html/info-gnu/2018-01/msg00000.html)

----------
components: Library (Lib)
messages: 309392
nosy: sam-s
priority: normal
severity: normal
status: open
title: ImportError for gdbm 1.14
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32484>
_______________________________________

From report at bugs.python.org  Tue Jan  2 14:59:39 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Jan 2018 19:59:39 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1514923179.24.0.467229070634.issue32471@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I brought this up on python-ideas, but I think discussing it here may be better: I think we may need to use a data file format that has an open source implementation. The tool Yahya used (plantuml) doesn't appear to be open source, which is a problem for the long-term maintainability of the diagram. If I'm wrong about open source tools for reading .puml files to generate SVG files then my worries are alleviated, but if there aren't any then something like a dot file may be better long-term.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Tue Jan  2 17:21:01 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Tue, 02 Jan 2018 22:21:01 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1514931661.09.0.467229070634.issue29708@psf.upfronthosting.co.za>


Alexandru Ardelean <ardeleanalex at gmail.com> added the comment:

Hey,

Allow me to join the discussion here.

Context:
- I'm the maintainer of Python & Python3 in the OpenWrt distro, and (since a while) we also care about reproducible builds.
- The person [Alexander Couzens] who's leading the effort for OpenWrt, has pinged me about Python(3) and packages [to see about making them reproducible]
- In OpenWrt we *only* ship .pyc files, because of performance considerations [.pyc can be 10x faster than .py on some SoCs], and size limitation [we cannot allow auto .pyc generation since it can be expensive on RAM [ < 32 MB systems ] or flash [ ~8 MB sizes ] ; believe it or not, people run Python on something like this

Current status:
- so far I've implemented a simple change to Python & Python3 here:
  https://github.com/openwrt/packages/pull/5303/commits/1b6dd4781f901a769718c49f6f255c15fd376f6e
- that has improved reproduce-ability quite a bit : only binaries are not reproduce-able now
- when I did this [1-2 weeks ago] I did not think of checking of any bug/issue opened here [ I only thought if this now ]
- I only checked what other distros may do regarding Python:
  https://tests.reproducible-builds.org/debian/reproducible.html

References:
- initial discussion on OpenWrt: https://github.com/openwrt/packages/issues/5278
- PR with discussion: https://github.com/openwrt/packages/pull/5303
- current OpenWrt reproducible state [with the patch applied]: https://tests.reproducible-builds.org/lede/lede_ar71xx.html

I wanted to share my [and our] interest in this.

If we can help in any way, feel free to ping.

I will try to hack/patch some more stuff in the current Python releases to make them fully reproducible [for us], and probably share the results here.
When PEP 552 gets implemented and there will be a Python we will switch to them.
Atm, in trunk we package Python 2.7.14 & Python 3.6.4

Thanks
Alex

----------
nosy: +Alexandru Ardelean

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Tue Jan  2 17:25:57 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Jan 2018 22:25:57 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1514931957.18.0.467229070634.issue29708@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

PEP 552 has been implemented for 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Tue Jan  2 19:17:45 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jan 2018 00:17:45 +0000
Subject: =?utf-8?q?=5Bissue32481=5D_Hitting_the_acute_accent_=C2=B4_button_on_a_Da?=
 =?utf-8?q?nish_keyboard_causes_Python_with_tkinter_to_crash_immediately?=
 =?utf-8?q?=2E?=
In-Reply-To: <1514889745.69.0.467229070634.issue32481@psf.upfronthosting.co.za>
Message-ID: <1514938665.72.0.467229070634.issue32481@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

This is a well-known bug with older versions of Tk on macOS.  Chances are that the Python 3.6.3 you are using is using the Apple-supplied version of Tk 8.5.x which exhibits this bug.  If you are using Python 3.6.3 downloaded from python.org, as documented in the installer readme and release notice, be aware that it links with Tk 8.5, not 8.6, so you will need to install a more recent version of ActiveTcl 8.5.  More details here: https://www.python.org/download/mac/tcltk/

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32481>
_______________________________________

From report at bugs.python.org  Tue Jan  2 20:42:53 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 03 Jan 2018 01:42:53 +0000
Subject: [issue32479] inconsistent ImportError message executing same import
 statement
In-Reply-To: <1514882888.25.0.467229070634.issue32479@psf.upfronthosting.co.za>
Message-ID: <1514943773.22.0.467229070634.issue32479@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

It's fine. Let's keep this issue open for some time before close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32479>
_______________________________________

From report at bugs.python.org  Tue Jan  2 22:26:12 2018
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 03 Jan 2018 03:26:12 +0000
Subject: [issue32484] ImportError for gdbm 1.14
In-Reply-To: <1514921958.6.0.467229070634.issue32484@psf.upfronthosting.co.za>
Message-ID: <1514949972.13.0.467229070634.issue32484@psf.upfronthosting.co.za>


Change by Chi Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32484>
_______________________________________

From report at bugs.python.org  Wed Jan  3 02:13:52 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jan 2018 07:13:52 +0000
Subject: [issue32484] ImportError for gdbm 1.14
In-Reply-To: <1514921958.6.0.467229070634.issue32484@psf.upfronthosting.co.za>
Message-ID: <1514963632.57.0.467229070634.issue32484@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It seems like Python will need to be recompiled then.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32484>
_______________________________________

From report at bugs.python.org  Wed Jan  3 02:32:11 2018
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 03 Jan 2018 07:32:11 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1514964731.37.0.467229070634.issue31340@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Since this has not been reverted/changed for 3.6.4 or 3.7.0a3, another potential issue arises: C extensions that are compiled with Visual Studio 2017 are linked to a newer version of vcruntime140.dll (latest is 14.12.25810, VS2017 15.5) than the DLL shipped with the CPython 3.6.4/3.7.0a3 installer (14.0.24210, VS2015 Update 3). There is no standard way C extensions that are compiled with VS2017 can load the correct/newer vcruntime140.dll. That said, I have not noticed any problems yet while testing with Python 3.7.0a3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Wed Jan  3 02:36:31 2018
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 03 Jan 2018 07:36:31 +0000
Subject: [issue32484] ImportError for gdbm 1.14
In-Reply-To: <1514921958.6.0.467229070634.issue32484@psf.upfronthosting.co.za>
Message-ID: <1514964991.1.0.467229070634.issue32484@psf.upfronthosting.co.za>


Chi Hsuan Yen <yan12125 at gmail.com> added the comment:

I can confirm a rebuild fixes _gdbm for Python 3.6.4.

This is also a bug in gdbm - it should bump soname (gdbm.so.4 => gdbm.so.5) for such an ABI incompatibility. I've sent a report to gdbm developers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32484>
_______________________________________

From report at bugs.python.org  Wed Jan  3 03:24:52 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Wed, 03 Jan 2018 08:24:52 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1514967892.94.0.467229070634.issue29708@psf.upfronthosting.co.za>


Alexandru Ardelean <ardeleanalex at gmail.com> added the comment:

Thank you for the heads-up.
I did not follow-up too in-depth on the resolution.

I just stumbled over this last night.

Will keep an eye for 3.7, and see about 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Jan  3 03:33:17 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jan 2018 08:33:17 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1514968397.03.0.467229070634.issue29708@psf.upfronthosting.co.za>


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


----------
nosy: +Ray Donnelly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Jan  3 04:42:28 2018
From: report at bugs.python.org (Mitar)
Date: Wed, 03 Jan 2018 09:42:28 +0000
Subject: [issue12932] filecmp.dircmp does not allow non-shallow comparisons
In-Reply-To: <1315411296.33.0.213336425163.issue12932@psf.upfronthosting.co.za>
Message-ID: <1514972548.19.0.467229070634.issue12932@psf.upfronthosting.co.za>


Change by Mitar <mmitar at gmail.com>:


----------
nosy: +mitar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12932>
_______________________________________

From report at bugs.python.org  Wed Jan  3 04:43:27 2018
From: report at bugs.python.org (Mitar)
Date: Wed, 03 Jan 2018 09:43:27 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1514972607.37.0.467229070634.issue15450@psf.upfronthosting.co.za>


Change by Mitar <mmitar at gmail.com>:


----------
nosy: +mitar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Wed Jan  3 04:44:21 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Neto?=)
Date: Wed, 03 Jan 2018 09:44:21 +0000
Subject: [issue32485] Multiprocessing dict sharing between forked processes
Message-ID: <1514972661.4.0.467229070634.issue32485@psf.upfronthosting.co.za>


New submission from Andr? Neto <andre.c.neto at gmail.com>:

I'm working on a project where I need to share state between several processes (forked using gunicorn). I'm using dictionaries obtained from a multiprocessing SyncManager to achieve this.

The issue is that if I have multiple forked processes concurrently accessing to different dictionaries created by the same SyncManager, the code will randomly crash while accessing (read-only and read-write) to any of the dictionaries. This behaviour is independent of the way I access the dictionary (i.e. it happens both using the dictionary functions (e.g. has_key) or the built-in keywords (e.g. key in dict).

The attached snippet demonstrates the issue (tested only in python2.7): the function test_manyForkedProcessesSingleThreaded will crash.

The issue is also being discussed here: https://stackoverflow.com/questions/48052148/python-multiprocessing-dict-sharing-between-processes

----------
files: multiprocessing_crash.py
messages: 309402
nosy: Andr? Neto
priority: normal
severity: normal
status: open
title: Multiprocessing dict sharing between forked processes
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47361/multiprocessing_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32485>
_______________________________________

From report at bugs.python.org  Wed Jan  3 04:55:58 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Jan 2018 09:55:58 +0000
Subject: [issue32485] Multiprocessing dict sharing between forked processes
In-Reply-To: <1514972661.4.0.467229070634.issue32485@psf.upfronthosting.co.za>
Message-ID: <1514973358.76.0.467229070634.issue32485@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Does it it actually crash (segfault) or are you merely getting an exception? I'm just getting bunch of exception:

Traceback (most recent call last):
  File "multiprocessing_crash.py", line 155, in <module>
    test_manyForkedProcessesSingleThreaded(inst1, inst2, nRuns, nProcesses)
  File "multiprocessing_crash.py", line 76, in test_manyForkedProcessesSingleThreaded
    run(inst1, nRuns)
  File "multiprocessing_crash.py", line 28, in run
    inst.run()
  File "multiprocessing_crash.py", line 23, in run
    self.d[self.key] = 0
  File "<string>", line 2, in __setitem__
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in _callmethod
  File "multiprocessing_crash.py", line 155, in <module>
    test_manyForkedProcessesSingleThreaded(inst1, inst2, nRuns, nProcesses)
  File "multiprocessing_crash.py", line 82, in test_manyForkedProcessesSingleThreaded
    run(inst2, nRuns)
  File "multiprocessing_crash.py", line 28, in run
    inst.run()
  File "multiprocessing_crash.py", line 19, in run
    item = self.d.get(self.key)
  File "<string>", line 2, in get
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in _callmethod
    kind, result = conn.recv()
    kind, result = conn.recv()
cPickle.UnpicklingErrorMemoryError
: invalid load key, '#'.
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 268, in _run_finalizers
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 268, in _run_finalizers
    finalizer()
    finalizer()
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 201, in __call__
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 201, in __call__
    res = self._callback(*self._args, **self._kwargs)
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 609, in _finalize_manager
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 609, in _finalize_manager
    if process.is_alive():
    if process.is_alive():
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 155, in is_alive
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 155, in is_alive
    assert self._parent_pid == os.getpid(), 'can only test a child process'
AssertionError: can only test a child process

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32485>
_______________________________________

From report at bugs.python.org  Wed Jan  3 04:57:12 2018
From: report at bugs.python.org (Mitar)
Date: Wed, 03 Jan 2018 09:57:12 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1514973432.16.0.467229070634.issue15450@psf.upfronthosting.co.za>


Change by Mitar <mmitar at gmail.com>:


----------
pull_requests: +4962

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Wed Jan  3 05:00:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 10:00:45 +0000
Subject: [issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3
In-Reply-To: <1514651174.11.0.213398074469.issue32456@psf.upfronthosting.co.za>
Message-ID: <1514973645.97.0.467229070634.issue32456@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for solving this puzzle Martin.

The question is whether we need to do something for improving error reporting in this case or just close this issue with a resolution "not a bug" or "won't fix".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32456>
_______________________________________

From report at bugs.python.org  Wed Jan  3 05:12:58 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Neto?=)
Date: Wed, 03 Jan 2018 10:12:58 +0000
Subject: [issue32485] Multiprocessing dict sharing between forked processes
In-Reply-To: <1514972661.4.0.467229070634.issue32485@psf.upfronthosting.co.za>
Message-ID: <1514974378.64.0.467229070634.issue32485@psf.upfronthosting.co.za>


Andr? Neto <andre.c.neto at gmail.com> added the comment:

You are right, it does not segfault (sorry for the abuse of language). It raises an exception while accessing the shared dictionary. The exception varies but typically is:
Traceback (most recent call last):
  File "multiprocessbug.py", line 156, in <module>
    test_manyForkedProcessesSingleThreaded(inst1, inst2, nRuns, nProcesses)
  File "multiprocessbug.py", line 77, in test_manyForkedProcessesSingleThreaded
    run(inst1, nRuns)
  File "multiprocessbug.py", line 29, in run
    inst.run()
  File "multiprocessbug.py", line 18, in run
    if (self.d.has_key(self.key)):
  File "<string>", line 2, in has_key
  File "/usr/local/lib/python2.7/multiprocessing/managers.py", line 759, in _callmethod
    kind, result = conn.recv()
cPickle.UnpicklingError: invalid load key, '#'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32485>
_______________________________________

From report at bugs.python.org  Wed Jan  3 05:25:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Jan 2018 10:25:11 +0000
Subject: [issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3
In-Reply-To: <1514973645.97.0.467229070634.issue32456@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbMMuMipydjCk6=p2+deTRgkSFsY9Eq3uvqGZhNg7ewow@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Can't we check if the encoding exists using codecs.lookup() before using it
to emit a better error message?

Look at initfsencoding() in the C code which implements such check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32456>
_______________________________________

From report at bugs.python.org  Wed Jan  3 05:47:38 2018
From: report at bugs.python.org (Robert Smart)
Date: Wed, 03 Jan 2018 10:47:38 +0000
Subject: [issue32486] tail optimization for 'yield from'
Message-ID: <1514976458.2.0.467229070634.issue32486@psf.upfronthosting.co.za>


New submission from Robert Smart <robert.kenneth.smart at gmail.com>:

When a generator procedure ends with "yield from" it would be nice if this was handled efficiently (just replace the generator with the new source). Because it is natural to push things back into a generator with

def prependGen(hd,tl):
    yield hd
    yield from tl

----------
messages: 309407
nosy: Robert Smart
priority: normal
severity: normal
status: open
title: tail optimization for 'yield from'
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32486>
_______________________________________

From report at bugs.python.org  Wed Jan  3 06:01:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 11:01:14 +0000
Subject: [issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3
In-Reply-To: <1514651174.11.0.213398074469.issue32456@psf.upfronthosting.co.za>
Message-ID: <1514977274.79.0.467229070634.issue32456@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The "undefined" encoding exists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32456>
_______________________________________

From report at bugs.python.org  Wed Jan  3 06:29:41 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 03 Jan 2018 11:29:41 +0000
Subject: [issue32461] the first build after a change to Makefile.pre.in uses
 the old Makefile
In-Reply-To: <1514706812.13.0.467229070634.issue32461@psf.upfronthosting.co.za>
Message-ID: <1514978981.67.0.467229070634.issue32461@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Two problems:
* It is not clear whether one should re-run make after the Makefile file has been updated since the (stale when not using GNU make) Makefile is run to completion.
* The 'Makefile' target is remade twice when Makefile.pre.in has been changed. The 'Makefile.pre' target is a pre-requisite of only the 'Makefile' target which means that if 'Makefile.pre' is being remade then 'Makefile' will be remade next and so it is useless to run the 'Makefile' target in a sub-make within the 'Makefile.pre' target.

The implementation of the uploaded stale-makefile.patch aborts the build when 'Makefile' has been remade and we are not running GNU make. It also removes the useless sub-make in the 'Makefile.pre' target.

----------
Added file: https://bugs.python.org/file47362/stale-makefile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32461>
_______________________________________

From report at bugs.python.org  Wed Jan  3 06:29:45 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Jan 2018 11:29:45 +0000
Subject: [issue32485] Multiprocessing dict sharing between forked processes
In-Reply-To: <1514972661.4.0.467229070634.issue32485@psf.upfronthosting.co.za>
Message-ID: <1514978985.96.0.467229070634.issue32485@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Don't worry about your choice of words. We usually use the C definition of the term crash. An exception is just a bug, but a segfault may be a security issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32485>
_______________________________________

From report at bugs.python.org  Wed Jan  3 06:53:36 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 03 Jan 2018 11:53:36 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1514980416.78.0.467229070634.issue32346@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

How about reusing tp_cache instead of adding new slot?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Wed Jan  3 06:53:58 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 03 Jan 2018 11:53:58 +0000
Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c:
 Function argument assignment between types "unsigned long" and "struct
 fsid_t" is not allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1514980438.65.0.467229070634.issue32390@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The _ALL_SOURCE feature test macro is set by the AC_USE_SYSTEM_EXTENSIONS macro in configure.ac.
It is not clear why the _ALL_SOURCE macro is currently needed by Python.

The _ALL_SOURCE feature test macro is defined here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/ftms.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Wed Jan  3 08:41:10 2018
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 03 Jan 2018 13:41:10 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1514986870.5.0.467229070634.issue32390@psf.upfronthosting.co.za>


David Edelsohn <dje.gcc at gmail.com> added the comment:

_ALL_SOURCE is overkill. It probably is too big a club for this regression. However, the AIX header definition of fsid compatible with the current Python posixmodule.c code is bracketed by _ALL_SOURCE.

AFAICT, the change to posixmodule.c made assumptions about fsid based on Linux and not required by POSIX. This didn't simply introduce a testsuite regression, but broke the build on AIX. The posixmodule.c code should be corrected or should be reverted.

----------
nosy: +vstinner
title: AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed -> AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Wed Jan  3 10:41:56 2018
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 03 Jan 2018 15:41:56 +0000
Subject: [issue32487] assertRaises should return the "captured" exception
Message-ID: <1514994116.04.0.467229070634.issue32487@psf.upfronthosting.co.za>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

Sometimes it's nice to do extra checks on the error raised and captured by self.assertRaises call.

Yes, the same can be achieved using assertRaises as a context manager and then accessing the `exception` attribute in the context manager, but it looks too cumbersome to just get the exception, when it can be simply returned by the assertRaises call.

Note 1: Currently it returns None, so no backward compatibility problem.

Note 2: assertRaises in testtools does this and is very useful

----------
messages: 309414
nosy: facundobatista
priority: normal
severity: normal
stage: needs patch
status: open
title: assertRaises should return the "captured" exception
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32487>
_______________________________________

From report at bugs.python.org  Wed Jan  3 11:11:31 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Jan 2018 16:11:31 +0000
Subject: [issue32487] assertRaises should return the "captured" exception
In-Reply-To: <1514994116.04.0.467229070634.issue32487@psf.upfronthosting.co.za>
Message-ID: <1514995891.27.0.467229070634.issue32487@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This has been proposed and rejected before, for example in issue 28135.  If you want to pursue it you'll need to start a thread on python-ideas.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> assertRaises should return the exception in its simple form

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32487>
_______________________________________

From report at bugs.python.org  Wed Jan  3 11:41:18 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jan 2018 16:41:18 +0000
Subject: [issue32484] ImportError for gdbm 1.14
In-Reply-To: <1514921958.6.0.467229070634.issue32484@psf.upfronthosting.co.za>
Message-ID: <1514997678.57.0.467229070634.issue32484@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32484>
_______________________________________

From report at bugs.python.org  Wed Jan  3 11:49:41 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 03 Jan 2018 16:49:41 +0000
Subject: [issue32428] dataclasses: make it an error to have initialized
 non-fields in a dataclass
In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>
Message-ID: <1514998181.73.0.467229070634.issue32428@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> I liked the original design better, where things without annotations would just be ignored. What changed?

With the original proposal the ignored variables without annotations will behave as class variables. This "conflicts" with PEP 526 which requires class variables to be annotated with ClassVar[...]. On the other hand some people may be unhappy that they need to import `typing` to define a class variable in a dataclass. So this is a convenience vs consistence question. I am more in favour of consistence here, but only +0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Wed Jan  3 11:52:50 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 03 Jan 2018 16:52:50 +0000
Subject: [issue32428] dataclasses: make it an error to have initialized
 non-fields in a dataclass
In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>
Message-ID: <1514998370.73.0.467229070634.issue32428@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Just to clarify the previous comment, I still think that flagging this

@dataclass
class C:
    x = field()

is important, since simply ignoring a ``field()`` will be too confusing (especially for ``attrs`` users).

The previous comment is about

@dataclass
class C:
    x = 42

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:03:53 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 03 Jan 2018 17:03:53 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1514999033.59.0.467229070634.issue32390@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The following patch may be less invasive and more explicit:

diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
index 38b6c80e6b..e0bb4ba869 100644
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -9325,7 +9325,11 @@ _pystatvfs_fromstructstatvfs(struct statvfs st) {
     PyStructSequence_SET_ITEM(v, 8, PyLong_FromLong((long) st.f_flag));
     PyStructSequence_SET_ITEM(v, 9, PyLong_FromLong((long) st.f_namemax));
 #endif
+#if defined(_AIX) && defined(_ALL_SOURCE)
+    PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid.val[0]));
+#else
     PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid));
+#endif
     if (PyErr_Occurred()) {
         Py_DECREF(v);
         return NULL;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:21:14 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 03 Jan 2018 17:21:14 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1514986870.5.0.467229070634.issue32390@psf.upfronthosting.co.za>
Message-ID: <ab91b317-1783-7e7b-a675-5b57a7e5e3a6@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 03/01/2018 14:41, David Edelsohn wrote:
> David Edelsohn <dje.gcc at gmail.com> added the comment:
>
> _ALL_SOURCE is overkill. It probably is too big a club for this regression.

Maybe. Clearly it is a big club. The documentation - if you can find any 
- is ancient and/or confusing. For example the xlc compiler reference 
quide (v12 is what I referenced, not the latest, but what I found) only 
has a single reference to any "_SOURCE" macro (-D_POSIX_SOURCE).

I do not know 'why' AIX and Linux differ in the way they name things. I 
do not want to care either - which is why I, personally, am less 
concerned about the size of the club. People much more clever than I 
decided that many variable names should be without two underscores 
(_ALL_SOURCE is defined) while others felt they must have two 
underscores (_ALL_SOURCE is undefined).

IMHO: 15+ years ago IBM (AIX) worked to find a method to simplify 
porting. And, I hope somewhere someone knows what these all meant. The 
practice seems to be to always define _ALL_SOURCE (see configure.ac:
 ? +882? # checks for UNIX variants that set C preprocessor variables
 ? +883? AC_USE_SYSTEM_EXTENSIONS
 ? +884
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html

Here is where I read that _ALL_SOURCE is for AIX3. I can neither deny 
nor affirm that that is (still) accurate. But that is what working with 
autotools does. Throws a sauce over everything that may, or maynot be 
what is needed.

I considered it 'interesting' that <sys/types.h> at least talks a bit 
about _POSIX_SOURCE and _ALL_SOURCE.

>   However, the AIX header definition of fsid compatible with the current Python posixmodule.c code is bracketed by _ALL_SOURCE.
>
> AFAICT, the change to posixmodule.c made assumptions about fsid based on Linux and not required by POSIX. This didn't simply introduce a testsuite regression, but broke the build on AIX. The posixmodule.c code should be corrected or should be reverted.

Maybe reverting the change is better than using the "big club". But, 
asis, AIX is dead to development. Was it possible to have AIX included 
in the PR test process I would hope that the PR would never have been 
merged.

IMHO - this is a spelling issue, going back years. But if you use a 
UK-only spelling checker and try and use only US spelling rules - and 
v.v. - there will be 'issues'. What is the solution with the most 
clarity? Above my pay grade to answer.

In any case the previous issue that saw adding fsid as a solution was 
not fully tested across all platforms. Currently AIX is broken. Someone 
needs to decide how to restore a supported platform - and where the 
discussion on fsid either restarts or continues.

In short - I am just a messenger - you are the experts. :)

>
> ----------
> nosy: +vstinner
> title: AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed -> AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32390>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:41:13 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jan 2018 17:41:13 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515001273.02.0.467229070634.issue32346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What exactly is tp_cache? Apparently it was added by Guido in https://github.com/python/cpython/commit/687ae00460da9cac04eb1ba8f6f5ab4db25fbfc2 but never used (at least officially).

commit 687ae00460da9cac04eb1ba8f6f5ab4db25fbfc2
Author: Guido van Rossum <guido at python.org>
Date:   Mon Oct 15 22:03:32 2001 +0000

    Get rid of __defined__ and tp_defined -- there's no need to
    distinguish __dict__ and __defined__ any more.  In the C structure,
    tp_cache takes its place -- but this hasn't been implemented yet.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:48:16 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Jan 2018 17:48:16 +0000
Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor
In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za>
Message-ID: <1515001696.87.0.467229070634.issue21288@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'm working on a hashing algorith v2.0 PEP. New hashing constructors and modules will have an allow_optimization flag and oid attribute. Once finalized and implemented, hashlib.pbkdf2_hmac() will support digestmod and digest constructors that have allow_optimization=True and a valid OID class / module attributes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21288>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:49:03 2018
From: report at bugs.python.org (Dave Opstad)
Date: Wed, 03 Jan 2018 17:49:03 +0000
Subject: [issue32488] Fatal error using pydoc
Message-ID: <1515001743.82.0.467229070634.issue32488@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

I'm running 3.6.4 on Mac OS X 10.13.2, bash shell. Doing:

$ pydoc modules

causes:

Please wait a moment while I gather a list of all available modules...

Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

Reproduced this several times with the same result.

----------
components: Demos and Tools
messages: 309422
nosy: opstad
priority: normal
severity: normal
status: open
title: Fatal error using pydoc
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32488>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:53:52 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 03 Jan 2018 17:53:52 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1515002032.88.0.467229070634.issue32390@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

Ignore my last comment - I have a headache. If I could edit/delete it I would.

aka "reset 2018 - here I come!"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:54:21 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 03 Jan 2018 17:54:21 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1514565955.87.0.213398074469.issue17611@psf.upfronthosting.co.za>
Message-ID: <20180103175418.n3zk3ggqpgtdquyk@python.ca>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

On 2017-12-29, Mark Shannon wrote:
> One point I didn't cover is jumping to a new line in the debugger.
> Implementing that reliably for finally blocks with code
> duplication is tricky and would mean adding a number of marker
> bytecodes.  Which is a big point in favour of the JSR style.

Could we virtually execute the code, forwards or backwards,
starting from f_lasti?  For conditional jumps, we would follow both
branches.  Stop when we find the line number we want.  If we hit an
opcode that causes a fblock push or pop, abort.

I started implementing this as a proof of concept but didn't finish.
It seems to fit most naturally as an exported function of
Python/peephole.c.  That file already does a lot of similar stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Wed Jan  3 13:06:06 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 03 Jan 2018 18:06:06 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1514999033.59.0.467229070634.issue32390@psf.upfronthosting.co.za>
Message-ID: <35850d7d-0d95-96cb-9ccf-d4a997ae4b02@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 03/01/2018 18:03, Xavier de Gaye wrote:
> Xavier de Gaye <xdegaye at gmail.com> added the comment:
>
> The following patch may be less invasive and more explicit:
>
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> index 38b6c80e6b..e0bb4ba869 100644
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -9325,7 +9325,11 @@ _pystatvfs_fromstructstatvfs(struct statvfs st) {
>       PyStructSequence_SET_ITEM(v, 8, PyLong_FromLong((long) st.f_flag));
>       PyStructSequence_SET_ITEM(v, 9, PyLong_FromLong((long) st.f_namemax));
>   #endif
> +#if defined(_AIX) && defined(_ALL_SOURCE)
> +    PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid.val[0]));
> +#else
>       PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid));
> +#endif
>       if (PyErr_Occurred()) {
>           Py_DECREF(v);
>           return NULL;
>
> ----------
Applied to the PR. Thx.
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32390>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Wed Jan  3 13:09:26 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Jan 2018 18:09:26 +0000
Subject: [issue32488] Fatal error using pydoc
In-Reply-To: <1515001743.82.0.467229070634.issue32488@psf.upfronthosting.co.za>
Message-ID: <1515002966.87.0.467229070634.issue32488@psf.upfronthosting.co.za>


Change by R. David Murray <rdmurray at bitdance.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32488>
_______________________________________

From report at bugs.python.org  Wed Jan  3 13:11:55 2018
From: report at bugs.python.org (Dave Opstad)
Date: Wed, 03 Jan 2018 18:11:55 +0000
Subject: [issue32488] Fatal error using pydoc
In-Reply-To: <1515001743.82.0.467229070634.issue32488@psf.upfronthosting.co.za>
Message-ID: <1515003115.38.0.467229070634.issue32488@psf.upfronthosting.co.za>


Dave Opstad <dave.opstad at monotypeimaging.com> added the comment:

I think this was my mistake; when I used pydoc3 instead of pydoc it ran to completion. Please feel free to close this; sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32488>
_______________________________________

From report at bugs.python.org  Wed Jan  3 13:19:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 18:19:40 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1515003580.6.0.467229070634.issue32455@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

After resolving issue24340 I'm going to add PyCompile_OpcodeStackEffect() that takes an additional integer argument, and add an optional tristate argument to dis.stack_effect(). If it is True, return the effect when jump, if it is false, return the effect when not jump, when omitted or None, return the maximal effect.

----------
dependencies: +co_stacksize estimate can be highly off

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Wed Jan  3 13:19:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 18:19:49 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1515003589.35.0.467229070634.issue32455@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Wed Jan  3 13:20:16 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Wed, 03 Jan 2018 18:20:16 +0000
Subject: [issue32473] Readibility of ABCMeta._dump_registry()
In-Reply-To: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>
Message-ID: <1515003616.95.0.467229070634.issue32473@psf.upfronthosting.co.za>


Change by Yahya Abou Imran <yahya-abou-imran at protonmail.com>:


----------
keywords: +patch
pull_requests: +4963
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Wed Jan  3 13:24:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 18:24:32 +0000
Subject: [issue31113] Stack overflow with large program
In-Reply-To: <1501747851.67.0.0193426592051.issue31113@psf.upfronthosting.co.za>
Message-ID: <1515003872.96.0.467229070634.issue31113@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
dependencies: +co_stacksize estimate can be highly off

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31113>
_______________________________________

From report at bugs.python.org  Wed Jan  3 14:17:18 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Jan 2018 19:17:18 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1515007038.64.0.467229070634.issue32471@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I should mention that over on python-ideas people found the open source code to plantuml, so I think the format is acceptable for use in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Wed Jan  3 14:17:47 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jan 2018 19:17:47 +0000
Subject: [issue32488] Fatal error using pydoc
In-Reply-To: <1515001743.82.0.467229070634.issue32488@psf.upfronthosting.co.za>
Message-ID: <1515007067.79.0.467229070634.issue32488@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Glad you solved the immediate problem.  Under the covers, pydoc (either pydoc2 or pydoc3) tries to import all the modules associated with the interpreter instance it's running under - from the Python standard library plus any additional vendor-supplied modules and and any you install (with pip et al).  It seems likely that the Python 2 instance associated with the "pydoc" on your shell path (not "pydoc3" and Python 3) has at least one broken module installed.  It may be a case of a third-party module being compiled against one version of Python 2.7 (say, a Homebrew version) and being executed with another (say the Apple-supplied system Python 2.7).  See, for example, https://stackoverflow.com/questions/35640529/what-does-fatal-python-error-pythreadstate-get-no-current-thread-mean

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32488>
_______________________________________

From report at bugs.python.org  Wed Jan  3 14:19:26 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 03 Jan 2018 19:19:26 +0000
Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and
 later)
In-Reply-To: <1487925892.39.0.284188562445.issue27435@psf.upfronthosting.co.za>
Message-ID: <cb35fa95-08f4-73a8-9efe-b5747d5f95d6@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 24/02/2017 09:44, Michael Haubenwallner wrote:
> Michael Haubenwallner added the comment:
>
> Let's switch to github-based patches to discuss about:
> https://github.com/python/cpython/compare/2.7...haubi:issue27435/2.7
>
> For the library search path I prefer to use loadquery(L_GETLIBPATH), available via new _ctypes_aix module now, but also used with L_GETINFO in Python/dynload_aix.c already.

Back again - I could not find the _ctypes_aix you mentioned. github was 
new, and I had no time then. And what I saw in dynload_aix.c I did not 
understand. I was trying to emulate what I saw in the existing 
Lib/ctypes (i.e., resolve it in python code) rather than write code in C.

Clearly, you understand that path - I (still) do not. Obviously - making 
a library call is more efficient than making multiple subprocess calls.

I may be far enough along with git that I might be able to figure out 
how to "fetch" what you have on github as haubi:issue27435/2.7.

This may also be better, i.e., more efficient, ultimately, than what was 
merged via https://github.com/python/cpython/pull/4507

Now that I have found your work - thank you for all the time you put 
into this last year!

Michael

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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27435>
_______________________________________

From report at bugs.python.org  Wed Jan  3 15:50:56 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Jan 2018 20:50:56 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1515012656.54.0.467229070634.issue32471@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This is a nice looking diagram.  Nice work.  The existing table is great when you care about knowing what a particular ABC does, but the diagram nicely gives an overview of whole ecosystem all at once.

If the collections.abc module continues its unabated growth, the diagram will become a spaghetti bowl.  But for now, it reads nicely.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:03:18 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Jan 2018 21:03:18 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1515013398.34.0.467229070634.issue32477@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> This is a step to getting rid of the peepholer.

There is no goal to get rid of the peepholer optimizer.  Please don't invent this as a requirement.

If some optimization are more easily performed upstream, then go ahead and move them upstream.  The goal is to have a net reduction in complexity, not just the elimination of peephole.c just because you decided it should disappear.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:05:02 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Jan 2018 21:05:02 +0000
Subject: [issue32485] Multiprocessing dict sharing between forked processes
In-Reply-To: <1514972661.4.0.467229070634.issue32485@psf.upfronthosting.co.za>
Message-ID: <1515013502.91.0.467229070634.issue32485@psf.upfronthosting.co.za>


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


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32485>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:05:45 2018
From: report at bugs.python.org (David Vitek)
Date: Wed, 03 Jan 2018 21:05:45 +0000
Subject: [issue15982] asyncore.dispatcher does not handle windows socket error
 code correctly (namely WSAEWOULDBLOCK 10035)
In-Reply-To: <1348139570.15.0.496741951323.issue15982@psf.upfronthosting.co.za>
Message-ID: <1515013545.66.0.467229070634.issue15982@psf.upfronthosting.co.za>


David Vitek <dvitek at grammatech.com> added the comment:

It doesn't look like the fix for issue #16133 fixed this problem, or perhaps it only fixed it for asynchat but not asyncore.

I have attached a patch (against python 2, since this is where I needed it fixed).  The patch treats WSA flavors of all errno values in the same way that the non-WSA flavors were treated before.

It is the intent that no direct references to errno values persist after applying this patch.  The patch fixed my particular issue, but I certainly haven't tested every new error condition.

----------
keywords: +patch
nosy: +dvitek
Added file: https://bugs.python.org/file47363/p.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15982>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:11:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 21:11:07 +0000
Subject: [issue32489] Allow 'continue' in 'finally' clause
Message-ID: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

A 'continue' statement is illegal in the 'finally' clause due to a problem with the current implementation. After resolving issue17611 it will be easy to remove this restriction.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 309434
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Allow 'continue' in 'finally' clause
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32489>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:14:21 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Jan 2018 21:14:21 +0000
Subject: [issue32449] MappingView must inherit from Collection instead of Sized
In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za>
Message-ID: <1515014061.56.0.467229070634.issue32449@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Maybe I have to open a new one?

No need. Just continue here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32449>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:16:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 21:16:42 +0000
Subject: [issue32489] Allow 'continue' in 'finally' clause
In-Reply-To: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za>
Message-ID: <1515014202.79.0.467229070634.issue32489@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See the patch against PR 5006 at https://github.com/serhiy-storchaka/cpython/pull/2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32489>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:25:54 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Wed, 03 Jan 2018 21:25:54 +0000
Subject: [issue32449] MappingView must inherit from Collection instead of Sized
In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za>
Message-ID: <1515014754.36.0.467229070634.issue32449@psf.upfronthosting.co.za>


Yahya Abou Imran <yahya-abou-imran at protonmail.com> added the comment:

I'm sorry, It's already done...
https://bugs.python.org/issue32467

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32449>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:34:31 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 03 Jan 2018 21:34:31 +0000
Subject: [issue32490] subprocess: duplicate filename in exception message
Message-ID: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

Python 3.6.4 (default, Jan  3 2018, 21:10:22) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.call('nonexistent')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/subprocess.py", line 267, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/local/lib/python3.6/subprocess.py", line 709, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1344, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'nonexistent': 'nonexistent'


Note that the name of the missing file is mentioned twice in the error message.
(Strictly speaking it's once in the message, and once in the filename attribute, but for a casual observer, the effect is the same.)

----------
components: Library (Lib)
messages: 309438
nosy: jwilk
priority: normal
severity: normal
status: open
title: subprocess: duplicate filename in exception message
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:37:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 21:37:25 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1515015445.92.0.467229070634.issue32477@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Actually moving any of remaining optimizations (including two optimizations that are moved by this issue and two other that are left) slightly increases the complexity. But instead the optimizations become more general. At the end, after moving all optimizations, we could drop the auxiliary code in the peepholer (building the table of basic blocks, removing NOPs, fixing up jump targets) and the net complexity will be reduced. This can also reduce the time and memory consumption of compilation.

Thus getting rid of the peepholer optimizer working with the bytecode is my goal. But some peephole optimizations will work with the intermediate fixed-size representations used by the compiler, before generating the concrete bytecode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:52:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jan 2018 21:52:19 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1515016339.43.0.467229070634.issue32477@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But some peephole optimizations will work with the intermediate fixed-size representations used by the compiler, before generating the concrete bytecode.

Then perhaps the goal should be to make the peephole operate on that intermediate representation?

I think it's valuable to have a separate C module for optimizations, instead of cramming them in compiler.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:53:15 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 03 Jan 2018 21:53:15 +0000
Subject: [issue32489] Allow 'continue' in 'finally' clause
In-Reply-To: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za>
Message-ID: <1515016395.63.0.467229070634.issue32489@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think this should be accepted once the code is reviewed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32489>
_______________________________________

From report at bugs.python.org  Wed Jan  3 17:06:53 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 03 Jan 2018 22:06:53 +0000
Subject: [issue32428] dataclasses: make it an error to have initialized
 non-fields in a dataclass
In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>
Message-ID: <1515017213.43.0.467229070634.issue32428@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> > I liked the original design better, where things without annotations would just be ignored. What changed?

> With the original proposal the ignored variables without annotations will behave as class variables. This "conflicts" with PEP 526 which requires class variables to be annotated with ClassVar[...]. On the other hand some people may be unhappy that they need to import `typing` to define a class variable in a dataclass. So this is a convenience vs consistence question. I am more in favour of consistence here, but only +0.

There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so the type checker can be made to understand. PEP 557 allows omitting ClassVar in case you don't care about type checkers. So I think we should stick with the current spec of PEP 557 (which lets you omit ClassVar), except for this special case:

> I still think that flagging this
> 
> @dataclass
> class C:
>     x = field()
> 
> is important, since simply ignoring a ``field()`` will be too confusing (especially for ``attrs`` users).

Agreed. That's a special case and I'm fine with flagging it as an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Wed Jan  3 17:09:45 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 03 Jan 2018 22:09:45 +0000
Subject: [issue32428] dataclasses: make it an error to have initialized
 non-fields in a dataclass
In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>
Message-ID: <1515017385.0.0.467229070634.issue32428@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so the type checker can be made to understand. PEP 557 allows omitting ClassVar in case you don't care about type checkers. So I think we should stick with the current spec of PEP 557 (which lets you omit ClassVar), except for this special case: ...

OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Wed Jan  3 17:17:59 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 03 Jan 2018 22:17:59 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515017879.3.0.467229070634.issue32346@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't recall what I meant to use tp_cache for, but everything I can find about it says it's unused, so let's kill it if we can. I guess the ABI requires that we keep the slot around until we find a new use for it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Wed Jan  3 17:30:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 22:30:04 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1515018604.6.0.467229070634.issue32477@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> I think it's valuable to have a separate C module for optimizations, instead of cramming them in compiler.c.

This would require major rewriting. PR 5077 adds just two functions in compile.c. But they use 4 structures defined locally in this file. If move these two functions in a separate file we will need to move these 4 structures and related definitions to the common header file. And maybe it will be in vain if once all these optimizations will be moved to other parts of the compiler. Some of jumps optimization already are performed on instructions emitting stage. Dead code elimination perhaps could be performed at the stage of assembling the bytecode from basic blocks. Constant tuples folding could be implemented by at least three ways besides the current implementation, I'm testing what of them is the simplest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Wed Jan  3 17:33:01 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jan 2018 22:33:01 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1515018781.77.0.467229070634.issue32477@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, on the other hand, the change you're proposing is hardly necessary, unless it actually demonstrates a noticeable improvement on some workload.  So perhaps we should leave the peepholer alone until someone has a better idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Wed Jan  3 17:44:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Jan 2018 22:44:16 +0000
Subject: [issue15982] asyncore.dispatcher does not handle windows socket error
 code correctly (namely WSAEWOULDBLOCK 10035)
In-Reply-To: <1348139570.15.0.496741951323.issue15982@psf.upfronthosting.co.za>
Message-ID: <1515019456.14.0.467229070634.issue15982@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I reopen the issue since David Vitek proposed a patch.

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15982>
_______________________________________

From report at bugs.python.org  Wed Jan  3 18:31:52 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jan 2018 23:31:52 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1515022312.75.0.467229070634.issue32455@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

What was the rationale for exposing these interfaces in the first place? If they're not useful, I'd rather deprecate and remove them.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Wed Jan  3 18:35:25 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Jan 2018 23:35:25 +0000
Subject: [issue32491] base64.decode: linebreaks are not ignored
Message-ID: <1515022525.85.0.467229070634.issue32491@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

I've tried reading various RFCs around Base64 encoding, but I couldn't make the ends meet.  Yet there is an inconsistency between base64.decodebytes() and base64.decode() in that how they handle linebreaks that were used to collate the encoded text.  Below is an example of what I'm talking about:

>>> import base64
>>> foo = base64.encodebytes(b'123456789')
>>> foo
b'MTIzNDU2Nzg5\n'
>>> foo = b'MTIzND\n' + b'U2Nzg5\n'
>>> foo
b'MTIzND\nU2Nzg5\n'
>>> base64.decodebytes(foo)
b'123456789'
>>> from io import BytesIO
>>> bytes_in = BytesIO(foo)
>>> bytes_out = BytesIO()
>>> bytes_in.seek(0)
0
>>> base64.decode(bytes_in, bytes_out)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/somewhere/lib/python3.6/base64.py", line 512, in decode
    s = binascii.a2b_base64(line)
binascii.Error: Incorrect padding
>>> bytes_in = BytesIO(base64.encodebytes(b'123456789'))
>>> bytes_in.seek(0)
0
>>> base64.decode(bytes_in, bytes_out)
>>> bytes_out.getvalue()
b'123456789'

Obviously, I'd expect encodebytes() and encode both to either accept or to reject the same input.

Thanks.

Oleg

via Oleg Sivokon on python-dev (who was having trouble getting bugs.python.org account creation to work)

----------
components: Library (Lib)
messages: 309449
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: base64.decode: linebreaks are not ignored
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32491>
_______________________________________

From report at bugs.python.org  Wed Jan  3 19:14:04 2018
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 04 Jan 2018 00:14:04 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1515024844.24.0.467229070634.issue32455@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

The rationale: without this information, it is impossible for anybody else to write a bytecode compiler / assembler, because when you create a code object you have to specify its stack depth.  I used this information for my "maynard" bytecode assembler / disassembler.

That said, I'm not sure who needs these super-fancy versions Serhiy is proposing.  To calculate stack depth, all you really need is the *maximum* stack depth per instruction.  You might slightly over-allocate but it shouldn't really be much of a problem.

Serhiy: what's your use case for all these complicated new features?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Wed Jan  3 19:52:25 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jan 2018 00:52:25 +0000
Subject: [issue32491] base64.decode: linebreaks are not ignored
In-Reply-To: <1515022525.85.0.467229070634.issue32491@psf.upfronthosting.co.za>
Message-ID: <1515027145.44.0.467229070634.issue32491@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This reduces to the following:

>>> from binascii import a2b_base64 as f
>>> f(b'MTIzND\nU2Nzg5\n')
b'123456789'
>>> f(b'MTIzND\n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
binascii.Error: Incorrect padding

That is, decode does its decoding line by line, whereas decodebytes passes the entire object to a2b_base64 as a single entity.  Apparently a2b_base64 looks at the padding for the entirety of what it is given, which I believe is in accordance with the RFC.  This means that decode is fundamentally broken per the RFC, and there is no obvious way to fix it without adding an incremental decoder to binascii.  And an incremental decoder probably belongs in codecs (assuming we ever resolved the transcode interface issue, I can't actually remember...).

Note that it will work as long as an "integral" number of base64 encoding units are in each line.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32491>
_______________________________________

From report at bugs.python.org  Wed Jan  3 19:57:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 00:57:30 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1515027450.87.0.467229070634.issue32455@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

1. This will actually simplify the code for calculating the stack size. Instead of supporting special cases for jumping instructions in stackdepth_walk() you could just write something like

new_depth = depth + PyCompile_OpcodeStackEffectEx(opcode, oparg, 0);
if (new_depth > maxdepth)
    maxdepth = new_depth;
if (isjump) {
    target_depth = depth + PyCompile_OpcodeStackEffectEx(opcode, oparg, 1);
    maxdepth = stackdepth_walk(c, instr->i_target, target_depth, maxdepth);
}
depth = new_depth;

After adding new opcodes or changing existing opcodes you would need to change the code only in one place.

2. This will simplify third-party compilers (like https://github.com/vstinner/bytecode). They wouldn't need to duplicate the complicated code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Wed Jan  3 20:24:02 2018
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 04 Jan 2018 01:24:02 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1515029042.98.0.467229070634.issue32455@psf.upfronthosting.co.za>


Change by Larry Hastings <larry at hastings.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Wed Jan  3 20:31:26 2018
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 04 Jan 2018 01:31:26 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1515029486.46.0.467229070634.issue32455@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

> 1. This will actually simplify the code for calculating the stack size.

Simplify whose code, the caller or the callee?  It seems like it's simplifying the life of the callee (PyCompile_OpcodeStackEffectEx) at the expense of pushing complexity into the caller.


> 2. This will simplify third-party compilers (like
> https://github.com/vstinner/bytecode). They wouldn't need to
> duplicate the complicated code.

What complicated code?  Compilers simply call PyCompile_OpcodeStackEffect(), passing in an opcode + oparg pair, and it simply returns the maximum stack effect.  No crazy "is it a jump" logic needed.  Again: this may mean overallocating the stack.  But CPython has behaved like this for twenty years and I'm not convinced it's a problem that needs solving.


Victor, do you want to use Serhiy's proposed API in your library?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Wed Jan  3 22:44:16 2018
From: report at bugs.python.org (Martin Panter)
Date: Thu, 04 Jan 2018 03:44:16 +0000
Subject: [issue32491] base64.decode: linebreaks are not ignored
In-Reply-To: <1515022525.85.0.467229070634.issue32491@psf.upfronthosting.co.za>
Message-ID: <1515037456.67.0.467229070634.issue32491@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I wrote an incremental base-64 decoder for the "codecs" module in Issue 27799, which you could use. It just does some preprocessing using a regular expression to pick four-character chunks before passing the data to a2b_base64. Or maybe implementing it properly in the "binascii" module is better.

Quickly reading RFC 2045, I saw it says "All line breaks or other characters not found in Table 1 [64 alphabet characters plus padding character] must be ignored by decoding software." So this is a real bug, although I think a base-64 encoder that triggers it would be rare.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32491>
_______________________________________

From report at bugs.python.org  Thu Jan  4 02:51:33 2018
From: report at bugs.python.org (Paul Rudin)
Date: Thu, 04 Jan 2018 07:51:33 +0000
Subject: [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1515052293.6.0.467229070634.issue17972@psf.upfronthosting.co.za>


Paul Rudin <paul at rudin.co.uk> added the comment:

If some are to be considered private then the questions are: which ones and how to fix. Presumably renaming to start with "_" might break existing code, so maybe adding an __all__, and just including the public objects is better? That could break code existing relying on * imports I suppose. Deprecation is another possibility, although feels a little odd for things never documented.

formatannotation and formatannotationrelativeto look like a helper functions for formatargspec and are probably not intended as part of the public interface.

Similarly walktree looks like a helper for getclasstree (and its docstring describes it as such).

----------
nosy: +PaulRudin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Thu Jan  4 03:36:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 08:36:17 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
In-Reply-To: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>
Message-ID: <1515054977.08.0.467229070634.issue32482@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0bcba372bcd564555c98a65be4fb1309ff1ae5d5 by Serhiy Storchaka in branch '2.7':
bpo-32482: Improve syntax and grammar tests. (#5085)
https://github.com/python/cpython/commit/0bcba372bcd564555c98a65be4fb1309ff1ae5d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Thu Jan  4 03:36:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 08:36:38 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
In-Reply-To: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>
Message-ID: <1515054998.01.0.467229070634.issue32482@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0cc99c8cd70d422e4b345837a907db30e9180ab9 by Serhiy Storchaka in branch 'master':
bpo-32482: Fix suspicious code in tests for syntax and grammar. (#5086)
https://github.com/python/cpython/commit/0cc99c8cd70d422e4b345837a907db30e9180ab9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Thu Jan  4 03:37:11 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 04 Jan 2018 08:37:11 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
In-Reply-To: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>
Message-ID: <1515055031.74.0.467229070634.issue32482@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4964

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:06:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:06:15 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>
Message-ID: <1515056775.55.0.467229070634.issue32308@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset fbb490fd2f38bd817d99c20c05121ad0168a38ee by Serhiy Storchaka in branch 'master':
bpo-32308: Replace empty matches adjacent to a previous non-empty match in re.sub(). (#4846)
https://github.com/python/cpython/commit/fbb490fd2f38bd817d99c20c05121ad0168a38ee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:06:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:06:40 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>
Message-ID: <1515056800.14.0.467229070634.issue32308@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:08:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:08:26 +0000
Subject: [issue32211] Document the bug in re.findall() and re.finditer() in
 2.7 and 3.6
In-Reply-To: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za>
Message-ID: <1515056906.71.0.467229070634.issue32211@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1e6d8525f9dd3dcdc83adb93b164082c8b95d17a by Serhiy Storchaka in branch '3.6':
bpo-32211: Document the existing bug in re.findall() and re.finditer(). (#4695)
https://github.com/python/cpython/commit/1e6d8525f9dd3dcdc83adb93b164082c8b95d17a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32211>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:15:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:15:46 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1515057346.58.0.467229070634.issue31778@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d8ac4d1d5ac256ebf3d8d38c226049abec82a2a0 by Serhiy Storchaka in branch 'master':
bpo-31778: Make ast.literal_eval() more strict. (#4035)
https://github.com/python/cpython/commit/d8ac4d1d5ac256ebf3d8d38c226049abec82a2a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:27:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:27:28 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1515058048.79.0.467229070634.issue31778@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:32:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:32:12 +0000
Subject: [issue32211] Document the bug in re.findall() and re.finditer() in
 2.7 and 3.6
In-Reply-To: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za>
Message-ID: <1515058332.35.0.467229070634.issue32211@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4965

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32211>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:32:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:32:55 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
In-Reply-To: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>
Message-ID: <1515058375.44.0.467229070634.issue32482@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a70d5ff992e5e123a3fa6f0e7f672026db8ed1f7 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-32482: Fix suspicious code in tests for syntax and grammar. (GH-5086) (#5095)
https://github.com/python/cpython/commit/a70d5ff992e5e123a3fa6f0e7f672026db8ed1f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:34:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:34:08 +0000
Subject: [issue32211] Document the bug in re.findall() and re.finditer() in
 2.7 and 3.6
In-Reply-To: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za>
Message-ID: <1515058448.6.0.467229070634.issue32211@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32211>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:34:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 09:34:31 +0000
Subject: [issue32482] Improve tests for syntax and grammar in 2.7
In-Reply-To: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>
Message-ID: <1515058471.44.0.467229070634.issue32482@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Thu Jan  4 04:50:03 2018
From: report at bugs.python.org (=?utf-8?q?Maciej_Urba=C5=84ski?=)
Date: Thu, 04 Jan 2018 09:50:03 +0000
Subject: [issue26528] NameError for built in function open when re-raising
 stored exception from yielded function
In-Reply-To: <1457611797.69.0.202848672993.issue26528@psf.upfronthosting.co.za>
Message-ID: <1515059403.66.0.467229070634.issue26528@psf.upfronthosting.co.za>


Maciej Urba?ski <rooter at kyberian.net> added the comment:

Reproduced in both v3.6.4 and v3.7.0a3

----------
nosy: +rooter
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26528>
_______________________________________

From report at bugs.python.org  Thu Jan  4 07:08:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 12:08:33 +0000
Subject: [issue32211] Document the bug in re.findall() and re.finditer() in
 2.7 and 3.6
In-Reply-To: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za>
Message-ID: <1515067713.78.0.467229070634.issue32211@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ca54740f257086393106d242644d450485180b96 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-32211: Document the existing bug in re.findall() and re.finditer(). (GH-4695). (#5096)
https://github.com/python/cpython/commit/ca54740f257086393106d242644d450485180b96


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32211>
_______________________________________

From report at bugs.python.org  Thu Jan  4 08:08:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 13:08:07 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1515071287.67.0.467229070634.issue32226@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4966

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Thu Jan  4 08:22:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 13:22:15 +0000
Subject: [issue31506] Improve the error message logic for object_new &
 object_init
In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za>
Message-ID: <1515072135.6.0.467229070634.issue31506@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Error messages "object.__init__() takes no arguments" and "object.__new__() takes no arguments" are wrong. They contradicts the following error messages:

>>> object.__init__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor '__init__' of 'object' object needs an argument
>>> object.__new__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object.__new__(): not enough arguments

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31506>
_______________________________________

From report at bugs.python.org  Thu Jan  4 08:26:00 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Jan 2018 13:26:00 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515072360.25.0.467229070634.issue32346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I see, so I should be able to reuse tp_cache for this PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Thu Jan  4 09:09:33 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jan 2018 14:09:33 +0000
Subject: [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1515074973.3.0.467229070634.issue17972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think adding an __all__ in 3.7 would be reasonable.  You are right that we can't simply rename them for backward compatibility reasons.  We could rename them, and leave a stub function (that calls the renamed function) but issues a deprecation warning.  We've done that for other old internal APIs that we wanted to mark as private elsewhere in the stdlib.  The question is, is it worth the trouble to do it?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Thu Jan  4 09:27:30 2018
From: report at bugs.python.org (WildCard65)
Date: Thu, 04 Jan 2018 14:27:30 +0000
Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515076050.92.0.467229070634.issue25095@psf.upfronthosting.co.za>


WildCard65 <lollol222gg at gmail.com> added the comment:

Adding onto this issue, I believe I tracked down the change that caused the issue: https://github.com/python/cpython/commit/c0a23e63207984304027f298eefc738b6b3c94b1

This issue also affects the test with Python 3.6

----------
nosy: +WildCard65

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Thu Jan  4 09:35:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 14:35:12 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1515076512.49.0.467229070634.issue31672@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4967

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Thu Jan  4 09:39:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 14:39:54 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1515076794.02.0.467229070634.issue31672@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 5099 reverts in 3.7 a subtle behavior change made by the fix for this issue. Before merging the fix setting flags to 0 in a Template subclass made the default pattern matching only lower case letters. Currently setting flags to 0 doesn't have any effect.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Thu Jan  4 09:45:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 14:45:34 +0000
Subject: [issue31170] Update to expat 2.2.4 (expat: utf8_toUtf8 cannot
 properly handle exhausting buffer)
In-Reply-To: <1502340505.45.0.797067466934.issue31170@psf.upfronthosting.co.za>
Message-ID: <1515077134.72.0.467229070634.issue31170@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Can this issue be closed now?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31170>
_______________________________________

From report at bugs.python.org  Thu Jan  4 09:56:34 2018
From: report at bugs.python.org (WildCard65)
Date: Thu, 04 Jan 2018 14:56:34 +0000
Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515077794.58.0.467229070634.issue25095@psf.upfronthosting.co.za>


WildCard65 <lollol222gg at gmail.com> added the comment:

I believe I found the issue, might be an issue between sending the request + calling get_response() and the time it takes for server to process response, my print cases:

test_err (test.test_httpservers.RequestHandlerLoggingTestCase) ... Creating a new connection to 127.0.0.1:50141
Connecting to server
Sending ERROR request, captured stderr instance is <_io.StringIO object at 0x05E5EC00>
HANDLING AN ERROR REQUEST! SENDING RESPONSE!
Request sent, starting to read response
<http.client.HTTPResponse object at 0x05E6D7E0>
RESPONSE SENT!
Response obtained, err should be set, <_io.StringIO object at 0x05E5EC00>
Running test's assert
ok
test_get (test.test_httpservers.RequestHandlerLoggingTestCase) ... Creating a new connection to 127.0.0.1:50143
Connecting to server
Sending GET request, captured stderr instance is <_io.StringIO object at 0x05E5EC00>
Request sent, starting to read response
HANDLING A GET REQUEST! SENDING RESPONSE!
RESPONSE SENT! ENDING HEADERS!
HEADERS ENDED!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Thu Jan  4 10:52:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Jan 2018 15:52:09 +0000
Subject: [issue31170] Update to expat 2.2.4 (expat: utf8_toUtf8 cannot
 properly handle exhausting buffer)
In-Reply-To: <1502340505.45.0.797067466934.issue31170@psf.upfronthosting.co.za>
Message-ID: <1515081129.43.0.467229070634.issue31170@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Ah yes, it can be closed. I was waiting 3.4 and 3.5 fixes to be fixed, which is now the case.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31170>
_______________________________________

From report at bugs.python.org  Thu Jan  4 12:20:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 17:20:14 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1515086414.59.0.467229070634.issue31672@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 87be28f4a1c5b76926c71a3d9f92503f9eb82d51 by Serhiy Storchaka in branch 'master':
bpo-31672: Restore the former behavior when override flags in Template. (#5099)
https://github.com/python/cpython/commit/87be28f4a1c5b76926c71a3d9f92503f9eb82d51


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Thu Jan  4 12:28:43 2018
From: report at bugs.python.org (William Pickard)
Date: Thu, 04 Jan 2018 17:28:43 +0000
Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515086923.06.0.467229070634.issue25095@psf.upfronthosting.co.za>


William Pickard <lollol222gg at gmail.com> added the comment:

Scratch the previous message about the possible cause, I found the true cause, getresponse() is waiting for a specific header, one that BaseHTTPRequestHandler.send_error sends and BaseHTTPRequestHandler.send_response() doesn't, that header is "Connection" with message "close" (http.server#450), adding that to RequestHandlerLoggingTestCase.request_handler.do_GET before self.end_headers() fixes the deadlock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Thu Jan  4 12:30:07 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 04 Jan 2018 17:30:07 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515087007.32.0.467229070634.issue32346@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

In my environment, python -X importtime -c 'import asyncio' speed up from 53.2ms to 51ms.
While I like faster startup time, I don't know 4% speed up is worth enough for
this complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Thu Jan  4 12:40:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 17:40:09 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1515087609.14.0.467229070634.issue31672@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Results.

There are 4 cases:

1) default idpattern and flags
2) overridden only idpattern
3) overridden only flags
4) overridden both idpattern and flags

The case 1 was the one that was broken when this issue was opened. The initial Inada's version fixed the case 1, but broke the case 2. His final version (applied also to 3.6) fixed the case 1, but broke the case 3. This is a win, because cases 1 and 2 look much more common than the case 3. And finally PR 5099 has fixed also the case 3. The case 4 obviously is not affected by any changes of default values.

Now all four cases are correct in 3.7 and the only broken case in 3.6 is the uncommon case 3.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:00:48 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Jan 2018 18:00:48 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515088848.48.0.467229070634.issue32346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> While I like faster startup time, I don't know 4% speed up is worth enough for this complexity.

There's no magic bullet that I know of to reduce startup time by a large amount.  So we're left with optimizing progressively.  For comparison, https://github.com/python/cpython/pull/3279 had an even smaller effect on startup time.

This change has the nice property that it's a genuine speed-up on a generic operation, and it reduces the cost of adding slots as well as the cost of having long inheritance chains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:05:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Jan 2018 18:05:43 +0000
Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair
Message-ID: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Attribute access for named tuples can be made as fast as attribute access of instances of classes with slots.  All that is needed is a C subclass of property with it own __get__ that directly look's up the tuple field using PyTuple_GET_ITEM using an index stored in a C struct rather than as an integer object.

----------
components: Extension Modules
messages: 309477
nosy: rhettinger
priority: normal
severity: normal
status: open
title: C Fast path for namedtuple's property/itemgetter pair
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:07:23 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Jan 2018 18:07:23 +0000
Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair
In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>
Message-ID: <1515089243.92.0.467229070634.issue32492@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4968
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:24:14 2018
From: report at bugs.python.org (William Pickard)
Date: Thu, 04 Jan 2018 18:24:14 +0000
Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515090254.23.0.467229070634.issue25095@psf.upfronthosting.co.za>


Change by William Pickard <lollol222gg at gmail.com>:


----------
keywords: +patch
pull_requests: +4969
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:39:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 18:39:47 +0000
Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair
In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>
Message-ID: <1515091187.01.0.467229070634.issue32492@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Alternatively we could consider the way of optimizing property or itemgetter (or both). This may be more complex solution, but if the added complexity is not too large, this solution may be more preferable because it will speed up not only namedtuple.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:57:50 2018
From: report at bugs.python.org (David Carlier)
Date: Thu, 04 Jan 2018 18:57:50 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
Message-ID: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>


New submission from David Carlier <dcarlier at afilias.info>:

UUID module build fails on FreeBSD since it supports uuid_create function.

----------
components: FreeBSD
messages: 309479
nosy: David Carlier, koobs
priority: normal
pull_requests: 4970
severity: normal
status: open
title: UUID Module - FreeBSD build failure
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Thu Jan  4 15:14:47 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 04 Jan 2018 20:14:47 +0000
Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515096887.49.0.467229070634.issue25095@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for tracking down the problem, William! I just took a quick look at your patch and it seems reasonable to me.

Setting protocol_version to 'HTTP/1.1' means setting the close_connection attribute of BaseHTTPRequestHandler to False which is expected and a feature of HTTP/1.1 (persistent connections)

Quoting RFC 2616:

    HTTP/1.1 defines the "close" connection option for the sender to
    signal that the connection will be closed after completion of the
    response.

    HTTP/1.1 applications that do not support persistent connections MUST
    include the "close" connection option in every message.

So I think it's OK to send a "Connection: close" header in the test (it would be nice to add a comment though)

----------
components:  -Library (Lib)
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Thu Jan  4 15:28:55 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Jan 2018 20:28:55 +0000
Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair
In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>
Message-ID: <1515097735.63.0.467229070634.issue32492@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Joe Jevnik at already worked through attempts optimize property/itemgetter.   There isn't much fruit left there.

What I've outlined here should be several times faster.  The code will end-up being very similar to the __get__ for member objects which is currently the fastest form of attribute access.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Thu Jan  4 16:03:33 2018
From: report at bugs.python.org (Greg)
Date: Thu, 04 Jan 2018 21:03:33 +0000
Subject: [issue12706] timeout sentinel in ftplib and poplib documentation
In-Reply-To: <1514573747.85.0.213398074469.issue12706@psf.upfronthosting.co.za>
Message-ID: <CA+S+hTA-pdbao0ptPwdeEBVP8qJAy5vG16tX7a3JuMX8CLQ1aw@mail.gmail.com>


Greg <elorian.mestec at gmail.com> added the comment:

Completely forgot about this, please take my patch and submit a pr

On Fri, Dec 29, 2017 at 10:55 AM, Marcel Widjaja <report at bugs.python.org>
wrote:

>
> Marcel Widjaja <mwidj at yahoo.com> added the comment:
>
> Greg, I wonder if you are planning to submit a PR for your patch? If not,
> I'm plan to take your patch, make some minor adjustment and submit a PR.
>
> ----------
> nosy: +mawidjaj
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue12706>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12706>
_______________________________________

From report at bugs.python.org  Thu Jan  4 16:41:33 2018
From: report at bugs.python.org (sds)
Date: Thu, 04 Jan 2018 21:41:33 +0000
Subject: [issue32494] interface to gdbm_count
Message-ID: <1515102093.85.0.467229070634.issue32494@psf.upfronthosting.co.za>


New submission from sds <sds at gnu.org>:

gdbm offers a function to quickly find number of records: gdbm_count()
http://www.gnu.org/software/gdbm/manual/html_node/Count.html
It would be nice to be able to call it.

----------
components: Library (Lib)
messages: 309483
nosy: sam-s
priority: normal
severity: normal
status: open
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32494>
_______________________________________

From report at bugs.python.org  Thu Jan  4 17:21:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 22:21:49 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1515104509.42.0.467229070634.issue32226@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ce5b0e9db1b9698e6ffc43ae41cf3a22ca5a6ba6 by Serhiy Storchaka in branch 'master':
bpo-32226: Make __class_getitem__ an automatic class method. (#5098)
https://github.com/python/cpython/commit/ce5b0e9db1b9698e6ffc43ae41cf3a22ca5a6ba6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Thu Jan  4 17:22:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 22:22:39 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1515104559.71.0.467229070634.issue32226@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Thu Jan  4 17:24:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 22:24:23 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1515104663.52.0.467229070634.issue32226@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please don't forgot to document this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Thu Jan  4 17:31:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 22:31:04 +0000
Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair
In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>
Message-ID: <1515105064.08.0.467229070634.issue32492@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Ah, right. property already is hardy optimized, and specialized version of itemgetter gives only around 35% of maximal speed up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Thu Jan  4 17:57:15 2018
From: report at bugs.python.org (Jay Crotts)
Date: Thu, 04 Jan 2018 22:57:15 +0000
Subject: [issue32495] Adding Timer to multiprocessing
Message-ID: <1515106635.63.0.467229070634.issue32495@psf.upfronthosting.co.za>


New submission from Jay Crotts <crotts.jay at gmail.com>:

I wanted to propose the addition of a Timer class to the multiprocessing library similar to the one that exists in the Threading module.

Timer provides an example of how to extend the Process class that might be helpful to beginners. 

The current lack of a Timer in the multiprocessing library could encourage newer programmers to use threads where processes would be more appropriate.

In the implementation below I have added the ability to specify a # of iterations that the timed function should execute, and an additional infinite argument that would make the process execute the given function until the Timer is explicitly stopped.

----------
components: Library (Lib)
files: Timer.py
messages: 309487
nosy: davin, jcrotts, pitrou
priority: normal
severity: normal
status: open
title: Adding Timer to multiprocessing
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47364/Timer.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32495>
_______________________________________

From report at bugs.python.org  Thu Jan  4 18:28:09 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 04 Jan 2018 23:28:09 +0000
Subject: [issue32496] lib2to3 fails to parse a ** of a conditional expression
Message-ID: <1515108489.44.0.467229070634.issue32496@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

see the attached sample code demonstrating the problem.

basically lib2to3 fails to parse:

  dummy(**kwargs if kwargs else dict())

with an error like:

    raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=1, value='if', context=(' ', (3, 21))

----------
components: 2to3 (2.x to 3.x conversion tool)
files: repro_2to3_prob.py
messages: 309488
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: lib2to3 fails to parse a ** of a conditional expression
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47365/repro_2to3_prob.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32496>
_______________________________________

From report at bugs.python.org  Thu Jan  4 18:43:45 2018
From: report at bugs.python.org (William Pickard)
Date: Thu, 04 Jan 2018 23:43:45 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515109425.24.0.467229070634.issue25095@psf.upfronthosting.co.za>


Change by William Pickard <lollol222gg at gmail.com>:


----------
title: test_httpservers hangs on 3.5.0, win 7 -> test_httpservers hangs since Python 3.5
type: crash -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Thu Jan  4 18:49:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Jan 2018 23:49:12 +0000
Subject: [issue32496] lib2to3 fails to parse a ** of a conditional expression
In-Reply-To: <1515108489.44.0.467229070634.issue32496@psf.upfronthosting.co.za>
Message-ID: <1515109752.5.0.467229070634.issue32496@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32496>
_______________________________________

From report at bugs.python.org  Thu Jan  4 19:08:58 2018
From: report at bugs.python.org (Sabuj Pattanayek)
Date: Fri, 05 Jan 2018 00:08:58 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1515110938.11.0.467229070634.issue27054@psf.upfronthosting.co.za>


Sabuj Pattanayek <sabujp at gmail.com> added the comment:

I can confirm that this does happen if you don't install as admin. I confirmed that I didn't have PYTHONHOME or PYTHONPATH set and I still got a similar error (except it was for the site module) for the python 3.4.4 installer. setting pythonhome and pythonpath to blank does make it work, but so does just installing the exe/msi as admin.

Note this error does not happen with the python 2.7 installers even if you don't install as admin.

----------
nosy: +Sabuj Pattanayek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu Jan  4 19:25:00 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Jan 2018 00:25:00 +0000
Subject: [issue32486] tail optimization for 'yield from'
In-Reply-To: <1514976458.2.0.467229070634.issue32486@psf.upfronthosting.co.za>
Message-ID: <1515111900.79.0.467229070634.issue32486@psf.upfronthosting.co.za>


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


----------
type: resource usage -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32486>
_______________________________________

From report at bugs.python.org  Thu Jan  4 19:25:09 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Jan 2018 00:25:09 +0000
Subject: [issue32486] tail optimization for 'yield from'
In-Reply-To: <1514976458.2.0.467229070634.issue32486@psf.upfronthosting.co.za>
Message-ID: <1515111909.73.0.467229070634.issue32486@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32486>
_______________________________________

From report at bugs.python.org  Thu Jan  4 20:06:47 2018
From: report at bugs.python.org (David Bolen)
Date: Fri, 05 Jan 2018 01:06:47 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515114407.79.0.467229070634.issue32248@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Apologies if this is obvious and already in progress, but the issue with Windows and this change appears to be that the "utf-8.file" file is being treated as text rather than binary.

So the line ending is expanding to CRLF.  The working copy of utf-8.file on my Windows workers is actually 21 bytes, not 20.

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Thu Jan  4 20:44:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 05 Jan 2018 01:44:42 +0000
Subject: [issue32457] Windows Python cannot handle an early PATH entry
 containing ".." and python.exe
In-Reply-To: <1514660312.79.0.213398074469.issue32457@psf.upfronthosting.co.za>
Message-ID: <1515116682.44.0.467229070634.issue32457@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I agree that explicitly normalizing in PC/getpathp.c is the correct approach.

As far as I'm aware, GetModuleFileNameW(NULL) can never fail other than a buffer that is too small, so that whole function can probably be simplified to abort if it happens and just remove the PATH search.

Also, we should use a similar process for PathCchCanonicalizeEx as we already use for PathCchCombineExW in this file to avoid failing on earlier OS versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32457>
_______________________________________

From report at bugs.python.org  Thu Jan  4 20:44:58 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 05 Jan 2018 01:44:58 +0000
Subject: [issue32457] Windows Python cannot handle an early PATH entry
 containing ".." and python.exe
In-Reply-To: <1514660312.79.0.213398074469.issue32457@psf.upfronthosting.co.za>
Message-ID: <1515116698.62.0.467229070634.issue32457@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
stage:  -> needs patch
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32457>
_______________________________________

From report at bugs.python.org  Thu Jan  4 22:52:40 2018
From: report at bugs.python.org (Marcel Widjaja)
Date: Fri, 05 Jan 2018 03:52:40 +0000
Subject: [issue29237] Create enum for pstats sorting options
In-Reply-To: <1484098294.24.0.117553666266.issue29237@psf.upfronthosting.co.za>
Message-ID: <1515124360.38.0.467229070634.issue29237@psf.upfronthosting.co.za>


Change by Marcel Widjaja <mwidj at yahoo.com>:


----------
keywords: +patch
pull_requests: +4972
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29237>
_______________________________________

From report at bugs.python.org  Fri Jan  5 02:34:30 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Jan 2018 07:34:30 +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: <1515137670.71.0.467229070634.issue9325@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Issue 32206 covers doing this for `pdb`. It relies on directly accessing private APIs in the `runpy` module, but we can live with that, since `pdb` is part of the standard library.

----------
dependencies: +Run modules with pdb, cProfile command-line should accept "-m module_name" as an alternative to script path

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Fri Jan  5 02:44:21 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Jan 2018 07:44:21 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1515138261.86.0.467229070634.issue32206@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Linking back to the overall RFE for improved executable module support for standard library modules that run other scripts: https://bugs.python.org/issue9325

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Fri Jan  5 04:01:25 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jan 2018 09:01:25 +0000
Subject: [issue32495] Adding Timer to multiprocessing
In-Reply-To: <1515106635.63.0.467229070634.issue32495@psf.upfronthosting.co.za>
Message-ID: <1515142885.21.0.467229070634.issue32495@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The threading.Timer class is in my experience little used, for two reasons:
1) it's not very flexible (no periodic calls, no restart...)
2) it's not efficient (as it creates a new thread for each timer)
3) (third optional reason) many applications needing time management actually use an event loop of some kind, as the need for time management is often coupled with the requirement to do network I/O

A hypothetical multiprocessing.Timer would have the same drawbacks as threading.Timer, the inefficiency being of course much worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32495>
_______________________________________

From report at bugs.python.org  Fri Jan  5 04:25:46 2018
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 05 Jan 2018 09:25:46 +0000
Subject: [issue32457] Windows Python cannot handle an early PATH entry
 containing ".." and python.exe
In-Reply-To: <1514660312.79.0.213398074469.issue32457@psf.upfronthosting.co.za>
Message-ID: <1515144346.33.0.467229070634.issue32457@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

For extra measure, you may want to normalize `prefix` prior to calculating its length n in gotlandmark(). Then it would be reliable to truncate it via `prefix[n] = '\0'` after joining with `landmark`. Or at least add a comment there or in the calling function, search_for_prefix(), that gotlandmark assumes the current value of `prefix` is a canonical, normalized path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32457>
_______________________________________

From report at bugs.python.org  Fri Jan  5 04:50:48 2018
From: report at bugs.python.org (Paul Rudin)
Date: Fri, 05 Jan 2018 09:50:48 +0000
Subject: [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1515145848.68.0.467229070634.issue17972@psf.upfronthosting.co.za>


Paul Rudin <paul at rudin.co.uk> added the comment:

Documenting and generating a deprecation warning also makes them part of the documented public api. Or are you suggesting just the warning without including in the documentation?

Incidentally, there are also the classes BlockFinder and EndOfBlock, which are helpers for getblock and presumably not intended for public consumption.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Fri Jan  5 05:15:57 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jan 2018 10:15:57 +0000
Subject: [issue31699] Deadlocks in `concurrent.futures.ProcessPoolExecutor`
 with pickling error
In-Reply-To: <1507189305.87.0.213398074469.issue31699@psf.upfronthosting.co.za>
Message-ID: <1515147357.66.0.467229070634.issue31699@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 94459fd7dc25ce19096f2080eb7339497d319eb0 by Antoine Pitrou (Thomas Moreau) in branch 'master':
bpo-31699 Deadlocks in `concurrent.futures.ProcessPoolExecutor` with pickling error (#3895)
https://github.com/python/cpython/commit/94459fd7dc25ce19096f2080eb7339497d319eb0


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31699>
_______________________________________

From report at bugs.python.org  Fri Jan  5 05:32:39 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Jan 2018 10:32:39 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515148359.54.0.467229070634.issue25095@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

In the server, the send_header("Connection", "close") call sets the ?close_connection? flag. This shuts down the connection once ?do_GET? returns. Without the flag set, the server will wait and read another request.

If you want the server to shut the connection down, I suggest to be explicit in setting ?close_connection?. It should work even if no ?Connection: close? appears in the HTTP protocol. The special behaviour of ?send_header? I think you are relying on is not documented.

On my Linux computer with the original code, I think the client shuts the connection down. This causes the server to see an empty ?raw_requestline? and return from ?handle_one_request?. It returns to ?serve_forever? where it polls the ?__shutdown_request? flag and sees that it should stop.

The client shuts down the connection only because of subtleties in how the HTTP client manages the socket and how sockets are garbage collected. The response does not have Content-Length nor Transfer-Encoding fields, and would be terminated by the server shutting the connection down. So the HTTPConnection object cannot reuse the TCP connection and hands ownership to the HTTPResponse object returned by ?getresponse?. Since this object is not saved anywhere, it gets garbage collected, which closes the socket and shuts the connection down. But perhaps on Windows the shutdown doesn?t happen, or perhaps the garbage collector is too slow.

If I am right, closing the HTTPResponse object would also fix the deadlock. It is good practice to close the underlying socket anyway:

with support.captured_stderr() as err:
    self.con.request('GET', '/')
    res = self.con.getresponse()
    
    # Shut down connection to stop the server reading from it
    res.close()
    self.con.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Jan  5 06:49:32 2018
From: report at bugs.python.org (William Pickard)
Date: Fri, 05 Jan 2018 11:49:32 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515152972.43.0.467229070634.issue25095@psf.upfronthosting.co.za>


William Pickard <lollol222gg at gmail.com> added the comment:

Martin, your suggestion will never work as if you look at the trace back posted terry.reedy and my test print statements, both the client and server get stuck waiting to read data their respective socket, hence the deadlock. Adding the header "Connection" with value of "close" is logic taken from the method "send_error()" which is what test_err executes (same test class), that header along with send_error() adding the Content-Type and Content-Length headers, those headers are what is different between do_ERROR and do_GET, I've already tried locally having do_GET set both Content-Type and Content-Length headers without the Connection header, no difference (deadlock continued).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:02:04 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 05 Jan 2018 12:02:04 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1515153724.87.0.467229070634.issue32390@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:


New changeset 502d551c6d782963d26957a9e5ff1588946f233f by xdegaye (Michael Felt) in branch 'master':
bpo-32390: Fix compilation failure on AIX after f_fsid was added to os.statvfs() (#4972)
https://github.com/python/cpython/commit/502d551c6d782963d26957a9e5ff1588946f233f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:03:32 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 05 Jan 2018 12:03:32 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1515153812.32.0.467229070634.issue32390@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Thanks Michael for your contribution in fixing this issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:24:22 2018
From: report at bugs.python.org (Arjan Keeman)
Date: Fri, 05 Jan 2018 12:24:22 +0000
Subject: [issue32497] datetime.strptime creates tz naive object from value
 containing a tzname
Message-ID: <1515155062.37.0.467229070634.issue32497@psf.upfronthosting.co.za>


New submission from Arjan Keeman <arjan.keeman at gmail.com>:

Consider the following:

tz_naive_object = datetime.strptime("2018-01-05 13:10:00 CET", "%Y-%m-%d %H:%M:%S %Z")

Python's standard library is not capable of converting the timezone name CET to a tzinfo object. Therefore the case made above returns a timezone naive datetime object.

I propose to add an extra optional argument to _strptime.py's _strptime_datetime function, and to datetime.strptime: tzname_to_tzinfo:Optional[Callable[[str],Optional[tzinfo]]]=None. This parameter can be set with a function that accepts the timezone name and returns a tzinfo object or None (like pytz.timezone). None will mean that a timezone naive object will be created.

Usage:
tz_aware_object = datetime.strptime("2018-01-05 13:10:00 CET", "%Y-%m-%d %H:%M:%S %Z", pytz.timezone)

----------
components: Library (Lib)
messages: 309502
nosy: akeeman
priority: normal
severity: normal
status: open
title: datetime.strptime creates tz naive object from value containing a tzname
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32497>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:27:44 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 05 Jan 2018 12:27:44 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1515155264.34.0.467229070634.issue32441@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

gcc is a little bit lost and prints now the following (false) warning:

gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes    -std=c99 -Wextra
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration   -I. -I./Include    -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o./Modules/posixmodule.c: In function ?os_dup2_impl?:
./Modules/posixmodule.c:7785:9: warning: ?res? may be used uninitialized in this function [-Wmaybe-uninitialized]
     int res;
         ^~~


The following change fools gcc that does not print anymore the warning:

diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
index 47b79fcc79..90d73daf97 100644
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -7845,7 +7845,7 @@ os_dup2_impl(PyObject *module, int fd, int fd2, int inheritable)
         }
     }
 
-    if (inheritable || dup3_works == 0)
+    if (inheritable || (!inheritable && dup3_works == 0))
     {
 #endif
         Py_BEGIN_ALLOW_THREADS


The change does not modify the behavior:
* dup3_works == 0 is equivalent to ((inheritable && dup3_works == 0) || (!inheritable && dup3_works == 0))
* (inheritable && dup3_works == 0) is always false
* hence dup3_works == 0 is equivalent to (!inheritable && dup3_works == 0)

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:33:10 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jan 2018 12:33:10 +0000
Subject: [issue31699] Deadlocks in `concurrent.futures.ProcessPoolExecutor`
 with pickling error
In-Reply-To: <1507189305.87.0.213398074469.issue31699@psf.upfronthosting.co.za>
Message-ID: <1515155590.8.0.467229070634.issue31699@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This non-trivial issue has been fixed now, thanks to Thomas' patch.  Thank you Thomas!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31699>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:37:07 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jan 2018 12:37:07 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1515155827.55.0.467229070634.issue32493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The AIX-specific code was contributed by Michael Felt in issue32399.

----------
nosy: +Michael.Felt, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:38:28 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jan 2018 12:38:28 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1515155908.85.0.467229070634.issue32493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Michael, does AIX have uint32_t?  If so, we could happily drop the unsigned32 reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:38:37 2018
From: report at bugs.python.org (Arjan Keeman)
Date: Fri, 05 Jan 2018 12:38:37 +0000
Subject: [issue32497] datetime.strptime creates tz naive object from value
 containing a tzname
In-Reply-To: <1515155062.37.0.467229070634.issue32497@psf.upfronthosting.co.za>
Message-ID: <1515155917.84.0.467229070634.issue32497@psf.upfronthosting.co.za>


Change by Arjan Keeman <arjan.keeman at gmail.com>:


----------
keywords: +patch
pull_requests: +4973
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32497>
_______________________________________

From report at bugs.python.org  Fri Jan  5 09:24:19 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Jan 2018 14:24:19 +0000
Subject: [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1515162259.41.0.467229070634.issue17972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just warnings, no docs.  We've done this before for other helper functions, but it is always a judgement call whether it is worth the churn.  I defer to those people who have actually done work on the module for the answer to that question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Fri Jan  5 09:42:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Jan 2018 14:42:31 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1515153812.32.0.467229070634.issue32390@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaVMNKk+AEFe8Z0onDBjjTcpuTRTtzUvn2cmPs0Sf31dA@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

A compilation error is a blocking bug. It is short and short, it can be
backported to 2.7 and 3.6 no? Is ALL_SOURCE defined vy default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Fri Jan  5 11:55:21 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 05 Jan 2018 16:55:21 +0000
Subject: [issue32497] datetime.strptime creates tz naive object from value
 containing a tzname
In-Reply-To: <1515155062.37.0.467229070634.issue32497@psf.upfronthosting.co.za>
Message-ID: <1515171321.69.0.467229070634.issue32497@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

This is essentially what the `tzinfos` argument to `dateutil.parser.parse` does. I do think something *like* this is the only reasonable way to handle %Z->tzinfo mappings.

In `dateutil` (https://dateutil.readthedocs.io/en/latest/parser.html#dateutil.parser.parse), you can either pass a mapping or callable. Most of the problems we have in dateutil relate to the fact that we're both inferring what should or should not be interpreted as a time zone *and* passing it to the mapping or callable. Given that the first problem is solved by the format specifier already having an option for %Z, the implementation of this would be much easier.

I think the options for how this could be implemented are:

1. Mapping only
2. Callable only
3. Mapping or callable

Callable-only will probably lead to plenty of problems, since there's *already* a problem in this bug report, which is that `pytz.timezone` evidently doesn't do what Arjan thinks it does, because that function only *happens* to work. It would not work with, say, `CST` or `PST`. That said, callable is the most versatile way to do it, and if we don't include it, then people will probably end up having to work around it by creating mappings whose `.get` calls arbitrary functions.

#1 is probably the least convenient and #3 is the most convenient. Either way, I'd say that the primary documented interface should be mappings, since that's least error-prone (these mappings could be curated by third party libraries for a given local context). An advantage of using mappings is that if we ever have a C implementation of strptime, it can have a fast evalution path for when the mapping is a `Dict`.

----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32497>
_______________________________________

From report at bugs.python.org  Fri Jan  5 11:56:14 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 05 Jan 2018 16:56:14 +0000
Subject: [issue32473] Readibility of ABCMeta._dump_registry()
In-Reply-To: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>
Message-ID: <1515171374.86.0.467229070634.issue32473@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Fri Jan  5 11:57:08 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 05 Jan 2018 16:57:08 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1515171428.22.0.467229070634.issue32471@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Fri Jan  5 12:07:55 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 05 Jan 2018 17:07:55 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1515172075.52.0.467229070634.issue32390@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The compilation error occurs only on the master branch, issue 32143 is the enhancement that is the  initial cause of this problem. This went unnoticed when issue 32143 was resolved because the AIX buildbots were already failing at that time for another reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Fri Jan  5 12:12:21 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 05 Jan 2018 17:12:21 +0000
Subject: [issue32497] datetime.strptime creates tz naive object from value
 containing a tzname
In-Reply-To: <1515155062.37.0.467229070634.issue32497@psf.upfronthosting.co.za>
Message-ID: <1515172341.88.0.467229070634.issue32497@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

By the way, one possibly significant problem with this interface is that it would tend to encourage the use of static timezone offsets rather than rule sets as intended by `tzinfo`. The main problem is that a simple mapping between tzname and tzinfo (whether done with a Mapping or a callable) will actually lose information about the fold that is encoded in the chosen tzname.

In dateutil, I solved this problem by attaching the timezone object and checking whether the `.tzname()` of the created datetime matches the string it was parsed from, and if not, set fold=1 and check again - if that one matches, use fold=1, otherwise just return it with fold=0. This is obviously a heuristic metric that will not always work.

Two possible more general solutions to this problem:

1. have a variant of `strptime` that returns a `datetime` and the contents of `%Z` and let users or third party libraries handle converting the string into a timezone and attaching it to the datetime.
2. have `tzinfos` take a callable like `handle_tzinfo(dt, tzstr)` which returns the localized datetime.
3. have separate `tzinfos` and `apply_tzinfo` arguments, the first generating the `tzinfo` object, the second of the format `apply_tzinfo(dt, tz)` - if the second one doesn't exist, the default implementation is just `lambda dt, tz: dt.replace(tzinfo=tz)` (or equivalent)

#1 is a pretty significant (and possibly awkward) change to the interface, and #2 makes the implementation of these mappings less convenient for the downstream users, but is probably the most elegant from an API perspective. #3 is a somewhat reasonable marriage of #1 and #2, but it's ugly and I'm fairly certain it would lead to a lot of buggy code out there from people who don't realize why you would need to implement the apply function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32497>
_______________________________________

From report at bugs.python.org  Fri Jan  5 12:13:13 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 05 Jan 2018 17:13:13 +0000
Subject: [issue32497] datetime.strptime creates tz naive object from value
 containing a tzname
In-Reply-To: <1515155062.37.0.467229070634.issue32497@psf.upfronthosting.co.za>
Message-ID: <1515172393.04.0.467229070634.issue32497@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Sorry, forgot to include the link to the dateutil implementation of the fold-resolution code: https://github.com/dateutil/dateutil/pull/517/files

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32497>
_______________________________________

From report at bugs.python.org  Fri Jan  5 12:34:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Jan 2018 17:34:05 +0000
Subject: [issue28416] defining persistent_id in _pickle.Pickler subclass
 causes reference cycle
In-Reply-To: <1476202451.78.0.408768500752.issue28416@psf.upfronthosting.co.za>
Message-ID: <1515173645.35.0.467229070634.issue28416@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28416>
_______________________________________

From report at bugs.python.org  Fri Jan  5 12:42:54 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 05 Jan 2018 17:42:54 +0000
Subject: [issue30541] Add restricted mocks to the python unittest mocking
 framework
In-Reply-To: <1496348216.16.0.694231026308.issue30541@psf.upfronthosting.co.za>
Message-ID: <1515174174.91.0.467229070634.issue30541@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
pull_requests: +4974

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30541>
_______________________________________

From report at bugs.python.org  Fri Jan  5 12:49:53 2018
From: report at bugs.python.org (Jay Crotts)
Date: Fri, 05 Jan 2018 17:49:53 +0000
Subject: [issue32495] Adding Timer to multiprocessing
In-Reply-To: <1515106635.63.0.467229070634.issue32495@psf.upfronthosting.co.za>
Message-ID: <1515174593.04.0.467229070634.issue32495@psf.upfronthosting.co.za>


Jay Crotts <crotts.jay at gmail.com> added the comment:

I think your three reasons make sense, I've only found threading.Timer helpful in pretty trivial cases.

Do you think a more flexible or efficient Timer class would be useful?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32495>
_______________________________________

From report at bugs.python.org  Fri Jan  5 13:30:03 2018
From: report at bugs.python.org (David Edelsohn)
Date: Fri, 05 Jan 2018 18:30:03 +0000
Subject: [issue32390] AIX compile error with Modules/posixmodule.c: Function
 argument assignment between types "unsigned long" and "struct fsid_t" is not
 allowed
In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za>
Message-ID: <1515177002.99.0.467229070634.issue32390@psf.upfronthosting.co.za>


David Edelsohn <dje.gcc at gmail.com> added the comment:

The AIX buildbots has been exhibiting testsuite failures, but not build (compile) failures. The buildbots do not visibly distinguish between the two cases in a strong manner.

We can disable / expect failure for the few, additional testcases on AIX so that the buildbots will report "success" to make new failures more obvious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32390>
_______________________________________

From report at bugs.python.org  Fri Jan  5 14:10:12 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Jan 2018 19:10:12 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515179412.12.0.467229070634.issue25095@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Today, at least, python -m test -v  test_httpservers does not hang for me on any of 3.5, 3.6, or  3.7, installed or repository debug.  I don't know if the offending test was just disabled or somehow fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Jan  5 14:12:03 2018
From: report at bugs.python.org (William Pickard)
Date: Fri, 05 Jan 2018 19:12:03 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515179523.0.0.467229070634.issue25095@psf.upfronthosting.co.za>


William Pickard <lollol222gg at gmail.com> added the comment:

It hangs for me on Windows 10 Professional running on a MSI gaming laptop for debug and PGO builds (Python 3.6)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Jan  5 14:15:10 2018
From: report at bugs.python.org (stein-k)
Date: Fri, 05 Jan 2018 19:15:10 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
Message-ID: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>


New submission from stein-k <karlsen.stein at gmail.com>:

urllib.parse.unquote(b'abc%20def')
...
TypeError: a bytes-like object is required, not 'str'

----------
components: Library (Lib)
messages: 309517
nosy: stein-k
priority: normal
severity: normal
status: open
title: urllib.parse.unquote raises incorrect errormessage when string parameter is bytes
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Fri Jan  5 14:44:48 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Jan 2018 19:44:48 +0000
Subject: [issue32448] subscriptable
In-Reply-To: <1514573988.38.0.213398074469.issue32448@psf.upfronthosting.co.za>
Message-ID: <1515181488.62.0.467229070634.issue32448@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that a better message would be nice.  But compiling 'a.b[c]' breaks the expression apart into the equivalent of 't=a.b; t[c]', where 't' is an anonymous reference, so as David notes, there is no 'name' left to display.  We don't have a 'not possible resoluton, so "won't fix (because not possible)" seems closest.

----------
nosy: +terry.reedy
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32448>
_______________________________________

From report at bugs.python.org  Fri Jan  5 14:57:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Jan 2018 19:57:12 +0000
Subject: [issue17607] missed peephole optimization (unnecessary jump at end of
 function after yield)
In-Reply-To: <1364791551.27.0.510465438261.issue17607@psf.upfronthosting.co.za>
Message-ID: <1515182232.37.0.467229070634.issue17607@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This optimization already is implemented in 3.5+. Actually it is implemented as a part of code generation, not a peepholer.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17607>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:14:32 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Jan 2018 20:14:32 +0000
Subject: [issue32450] non-descriptive variable name
In-Reply-To: <1514598581.85.0.213398074469.issue32450@psf.upfronthosting.co.za>
Message-ID: <1515183272.67.0.467229070634.issue32450@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'ndots' is an internal name in the import-from branch of the import statement handler.  It seems reasonable in that context.  'level' is part of the public api for the ImportFrom node class, and cannot be changed as such.  It is also the parameter that receives the ndot value in the ImportFrom call, to be assigned to the level attribute.  Making the name switch in the call is at least as reasonable as in the assignment.  I am not the expert here, but I would be inclined to rejected this as not worth the code churn.

----------
nosy: +benjamin.peterson, brett.cannon, ncoghlan, terry.reedy, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32450>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:41:54 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Jan 2018 20:41:54 +0000
Subject: [issue32458] test_asyncio failures on Windows
In-Reply-To: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za>
Message-ID: <1515184914.7.0.467229070634.issue32458@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After fresh update and debug rebuild on master(3.7), with Win10 patched last night, I got
======================================================================
FAIL: test_call_later (test.test_asyncio.test_events.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_asyncio\test_events.py", line 290, in test_call_later
    self.assertTrue(0.08 <= t1-t0 <= 0.8, t1-t0)
AssertionError: False is not true : 0.07800000000861473

I have not seen this before.  Four subsequent runs passed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32458>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:49:44 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Jan 2018 20:49:44 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515185384.16.0.467229070634.issue25095@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Sorry William, I forgot the client was waiting to read. But I don?t understand why your Connection field (which comes after the status line) allows the Python client to read the status line. Perhaps there is some malware scanner, firewall, or other proxy that intercepts the HTTP protocol? (I encountered something similar at work recently.)

You said ?my suggestion will never work?, but did you try setting ?close_connection? on its own:

def do_GET(self):
    self.send_response(HTTPStatus.OK)
    self.end_headers()
    self.close_connection = True  # Terminate response body to proxy

You tried adding Content-Length, but did you try ?Content-Length: 0?:

def do_GET(self):
    self.send_response(HTTPStatus.OK)
    self.send_header("Content-Length", "0")  # Stop proxy reading body
    self.end_headers()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:50:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 05 Jan 2018 20:50:22 +0000
Subject: [issue32499] Add dataclasses.is_dataclass(obj)
Message-ID: <1515185422.79.0.467229070634.issue32499@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

See https://mail.python.org/pipermail/python-dev/2018-January/151628.html and prior for the discussion.

Add dataclasses.is_dataclass(obj) that returns True if obj is a dataclass class or instance, else returns False.

----------
assignee: eric.smith
components: Library (Lib)
messages: 309523
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Add dataclasses.is_dataclass(obj)
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32499>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:52:50 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Jan 2018 20:52:50 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1515185570.31.0.467229070634.issue32498@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you read the traceback the message is "correct" for some definition of correct: the right hand side controls the type of the expression, so it is objecting to trying to look for the string '%' in a bytes object.

There are probably ways this could be improved, but I'm not sure it is worth it, since this is just a general behavior of the 'in' operator.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:53:46 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 05 Jan 2018 20:53:46 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1515185626.3.0.467229070634.issue30855@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I manually cleared `externals\tcltk64` on that bot some time ago, and it appears to be happy now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:56:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Jan 2018 20:56:07 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1515185767.34.0.467229070634.issue30855@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Zachary! Can this issue be closed now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:59:17 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 05 Jan 2018 20:59:17 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1515185957.34.0.467229070634.issue30855@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I think so :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Fri Jan  5 16:03:43 2018
From: report at bugs.python.org (William Pickard)
Date: Fri, 05 Jan 2018 21:03:43 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515186223.68.0.467229070634.issue25095@psf.upfronthosting.co.za>


William Pickard <lollol222gg at gmail.com> added the comment:

I have tried value 0 for "Content-Length" (along with "text/plain" for "Content-Type"), it was when I said I tried both "Content-Length" and "Content-Type", while I haven't tried directly setting "close_connection" in the handler, my solution is based on how "send_error()" works internally, not only that, but send_header is public API (by convention) and the "Connection" header is part of HTTP 1.1 so it should be documented ( reference: https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html ), so I don't really understand why my initial solution is consider "undocumented logic"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Jan  5 17:10:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Jan 2018 22:10:24 +0000
Subject: [issue32486] tail optimization for 'yield from'
In-Reply-To: <1514976458.2.0.467229070634.issue32486@psf.upfronthosting.co.za>
Message-ID: <1515190224.04.0.467229070634.issue32486@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think this should have been first floated on python-ideas list.  One objection is the same as for eliminating tail calls in general: it collapses tracebacks.

def g1():
    yield from g2()
def g2():
    yield 1/0
for i in g1(): pass

Traceback (most recent call last):
  File "F:\Python\a\tem.py", line 7, in <module>
    for i in g1(): pass
  File "F:\Python\a\tem.py", line 2, in g1
    yield from g2()
  File "F:\Python\a\tem.py", line 5, in g2
    yield 1/0
ZeroDivisionError: division by zero

There was at least some discussion of making 'yield from' internally more efficient without actual replacement.  I don't know what the current CPython implementation does.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32486>
_______________________________________

From report at bugs.python.org  Fri Jan  5 18:06:00 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Jan 2018 23:06:00 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1515193560.36.0.467229070634.issue25095@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Thanks, although the fact that ?Content-Length: 0? doesn?t work kills my theory about the proxy.

The ?close_connection? flag is also a documented public API of Python: <https://docs.python.org/3/library/http.server.html#http.server.BaseHTTPRequestHandler.close_connection>. According to the rules for framing the message body in <https://tools.ietf.org/html/rfc7230#section-3.3.3>, the presence of ?Connection: close? is not important. The server actually shutting down the connection is the key. That is why I prefer to explicitly set the flag (if it works).

Anyway, your current proposal makes the server send a valid full HTTP response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Jan  5 18:32:52 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Jan 2018 23:32:52 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515195172.47.0.467229070634.issue32248@psf.upfronthosting.co.za>


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


----------
pull_requests: +4975

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Fri Jan  5 18:33:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Jan 2018 23:33:44 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1515185957.34.0.467229070634.issue30855@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYHjJXG7xeXHK9kucyUqSj6UQ7OLiL5uyU86qrKFOYxmQ@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Awesome, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Fri Jan  5 19:15:20 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 06 Jan 2018 00:15:20 +0000
Subject: [issue30579] Allow traceback objects to be
 instantiated/mutated/annotated
In-Reply-To: <1496720513.53.0.619437315354.issue30579@psf.upfronthosting.co.za>
Message-ID: <1515197720.37.0.467229070634.issue30579@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Ping -- anyone up for reviewing PR 4793?

https://github.com/python/cpython/pull/4793

It's pretty straightforward, and I figure better to ping now and beat the end-of-month rush :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30579>
_______________________________________

From report at bugs.python.org  Fri Jan  5 19:15:27 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 06 Jan 2018 00:15:27 +0000
Subject: [issue29137] Fix fpectl-induced ABI breakage
In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za>
Message-ID: <1515197727.59.0.467229070634.issue29137@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Ping -- anyone up for reviewing PR 4789?

https://github.com/python/cpython/pull/4789

It's pretty straightforward, and I figure better to ping now and beat the end-of-month rush :-). Also, it has an autoconf refresh in it, so it's likely to develop spurious conflicts at some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29137>
_______________________________________

From report at bugs.python.org  Fri Jan  5 19:38:27 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sat, 06 Jan 2018 00:38:27 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
Message-ID: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>


New submission from Micha? G?rny <mgorny at gentoo.org>:

While debugging PyPy test failure on backports.lzma [1], I've noticed that PySequence_Check() on a dict type raises TypeError, e.g.:

  Traceback (most recent call last):
    File "test/test_lzma.py", line 273, in test_bad_args
      b"", format=lzma.FORMAT_RAW, filters={})
    File "/home/mgorny/git/backports.lzma/build/lib.linux-x86_64-3.6/backports/lzma/__init__.py", line 463, in decompress
      decomp = LZMADecompressor(format, memlimit, filters)
  TypeError: object of type 'dict' has no len()

The relevant C code is:

  static int
  parse_filter_chain_spec(lzma_filter filters[], PyObject *filterspecs)
  {
    Py_ssize_t i, num_filters;

    num_filters = PySequence_Length(filterspecs);
    ...

where filterspecs is the object corresponding to the {} dict in Python snippet.

According to the documentation [2], PySequence_Length() should be 'equivalent to the Python expression len(o).' The Python expression obviously does not raise TypeError:

  >>> len({})
  0

Therefore, I think that the behavior of PySequence_Length() is a bug, and the function should successfully return the dict length instead.

[1]:https://github.com/peterjc/backports.lzma
[2]:https://docs.python.org/3/c-api/sequence.html#c.PySequence_Length

----------
components: Extension Modules
messages: 309534
nosy: mgorny
priority: normal
severity: normal
status: open
title: PySequence_Length() raises TypeError on dict type
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Fri Jan  5 20:17:41 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 06 Jan 2018 01:17:41 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1515201461.15.0.467229070634.issue20104@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +4976

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Fri Jan  5 20:17:42 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 06 Jan 2018 01:17:42 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1515201462.03.0.467229070634.issue20104@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +4976, 4977

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Fri Jan  5 22:14:33 2018
From: report at bugs.python.org (Jay Crotts)
Date: Sat, 06 Jan 2018 03:14:33 +0000
Subject: [issue8243] curses writing to window's bottom right position raises:
 `_curses.error: addstr() returned ERR'
In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za>
Message-ID: <1515208473.77.0.467229070634.issue8243@psf.upfronthosting.co.za>


Jay Crotts <crotts.jay at gmail.com> added the comment:

I can create a documentation patch and PR if this still needs doing.

----------
nosy: +jcrotts

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8243>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:05:42 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 07:05:42 +0000
Subject: [issue32486] tail optimization for 'yield from'
In-Reply-To: <1514976458.2.0.467229070634.issue32486@psf.upfronthosting.co.za>
Message-ID: <1515222342.92.0.467229070634.issue32486@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The original yield from implementation did something like this, but we dropped it because it caused debuggability problems. See #14230

----------
nosy: +benjamin.peterson
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32486>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:08:06 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 07:08:06 +0000
Subject: [issue32450] non-descriptive variable name
In-Reply-To: <1514598581.85.0.213398074469.issue32450@psf.upfronthosting.co.za>
Message-ID: <1515222486.91.0.467229070634.issue32450@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I would accept a PR to rename the variable in ast.c to "level", but I'm not sure why it should matter to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32450>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:09:27 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 07:09:27 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1515222567.06.0.467229070634.issue32441@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I would just make a declaration a definition with a dummy value (0?) rather than complicating the branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:15:36 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 07:15:36 +0000
Subject: [issue29137] Fix fpectl-induced ABI breakage
In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za>
Message-ID: <1515222936.67.0.467229070634.issue29137@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 735ae8d139a673b30b321dc10acfd3d14f0d633b by Benjamin Peterson (Nathaniel J. Smith) in branch 'master':
bpo-29137: Remove fpectl module (#4789)
https://github.com/python/cpython/commit/735ae8d139a673b30b321dc10acfd3d14f0d633b


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29137>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:38:43 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 06 Jan 2018 07:38:43 +0000
Subject: [issue32443] Add Linux's signalfd() to the signal module
In-Reply-To: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za>
Message-ID: <1515224323.2.0.467229070634.issue32443@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32443>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:42:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 07:42:38 +0000
Subject: [issue29137] Fix fpectl-induced ABI breakage
In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za>
Message-ID: <1515224558.68.0.467229070634.issue29137@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29137>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:53:09 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 06 Jan 2018 07:53:09 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1515225189.93.0.467229070634.issue32206@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 9f1e5f1b7f074e026843a5d70834233a95a6bf9d by Nick Coghlan (Mario Corchero) in branch 'master':
bpo-32206: Pdb can now run modules (GH-4752)
https://github.com/python/cpython/commit/9f1e5f1b7f074e026843a5d70834233a95a6bf9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sat Jan  6 02:55:20 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 06 Jan 2018 07:55:20 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1515225320.42.0.467229070634.issue32206@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the patch!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sat Jan  6 03:43:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 08:43:49 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <1515228229.81.0.467229070634.issue32500@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PySequence_Length(o) is equivalent to the Python expression len(o) only if o is a sequence. dict is not a sequence. You must use a correct API:

PyObject_Size() -- for general objects.
PyMapping_Size() -- if the object is a mapping.
PyDict_Size() -- if the object is a concrete dict.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 03:50:29 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sat, 06 Jan 2018 08:50:29 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <1515228629.06.0.467229070634.issue32500@psf.upfronthosting.co.za>


Micha? G?rny <mgorny at gentoo.org> added the comment:

So is the documentation mistaken or just confusing? It says straight:

> For objects that do not provide sequence protocol, this is equivalent to the Python expression len(o).

So it the 'do not' mistaken or does it mean objects that are sequences but do not provide the sequence protocol?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 03:54:03 2018
From: report at bugs.python.org (Vladislavs Burakovs)
Date: Sat, 06 Jan 2018 08:54:03 +0000
Subject: [issue32501] Documentation for dir([object])
Message-ID: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>


New submission from Vladislavs Burakovs <solomonchild at gmail.com>:

Documentation page [1]  says "If the object has a method named __dir__(), this method will be called and must return the list of attributes.". 

It seems that on Python 3.6 it only works if the *class* has a method named __dir__. Should the documentation be changed?

Microsoft Windows [Version 10.0.16299.192]
(c) 2017 Microsoft Corporation. All rights reserved.

D:\Users\wlad>python
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class C: pass
...
>>> x = C()
>>> import types
>>> x.__dir__ = types.MethodType(lambda _:[], x)
>>> dir(x)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__']
>>> C.__dir__ = types.MethodType(lambda _:[], x)
>>> dir(x)
[]

[1] https://docs.python.org/3/library/functions.html

----------
assignee: docs at python
components: Documentation
messages: 309544
nosy: Vladislavs Burakovs, docs at python
priority: normal
severity: normal
status: open
title: Documentation for dir([object])
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Sat Jan  6 04:49:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 09:49:48 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <1515232188.57.0.467229070634.issue32500@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Agreed, it looks either mistaken or confusing. This wording is used from the first versions of the C API documentation. I don't know what is meant here.

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +docs at python, gvanrossum
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 05:35:22 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sat, 06 Jan 2018 10:35:22 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1515234922.86.0.467229070634.issue32206@psf.upfronthosting.co.za>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
pull_requests: +4978

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sat Jan  6 06:12:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 11:12:28 +0000
Subject: [issue29086] Document C API that is not part of the limited API
In-Reply-To: <1482865319.03.0.627052322458.issue29086@psf.upfronthosting.co.za>
Message-ID: <1515237148.94.0.467229070634.issue29086@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have found that there is an option :stableabi: for C API elements. But it is not used in the documentation. Shouldn't we start to use it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29086>
_______________________________________

From report at bugs.python.org  Sat Jan  6 06:23:51 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 06 Jan 2018 11:23:51 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1515237831.42.0.467229070634.issue31340@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Have you confirmed that's a problem? There are new compatibility promises that did not exist for earlier versions of the runtime, but that does not mean there are no bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Sat Jan  6 09:57:09 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 06 Jan 2018 14:57:09 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1515250629.52.0.467229070634.issue32206@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Re-opening for the CLI help updates.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sat Jan  6 10:05:56 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 06 Jan 2018 15:05:56 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1515251156.05.0.467229070634.issue32441@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Both the change in my previous post or using a definition for 'res' are not needed if 'dup3_works' is removed. That would make the code more clear for both gcc and a human reader. The attached patch removes it.

Using a definition for 'res' LGTM also.

----------
Added file: https://bugs.python.org/file47366/without-dup3_works.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Sat Jan  6 10:16:27 2018
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Jan 2018 15:16:27 +0000
Subject: [issue32501] Documentation for dir([object])
In-Reply-To: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>
Message-ID: <1515251787.73.0.467229070634.issue32501@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a general property of dunder methods in python3, and I think we have chosen not to change the wording when this has come up in other contexts.  I'm not sure, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Sat Jan  6 10:18:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 15:18:57 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515251937.36.0.467229070634.issue31993@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3cd7c6e6eb43dbd7d7180503265772a67953e682 by Serhiy Storchaka (Olivier Grisel) in branch 'master':
bpo-31993: Do not allocate large temporary buffers in pickle dump. (#4353)
https://github.com/python/cpython/commit/3cd7c6e6eb43dbd7d7180503265772a67953e682


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 10:57:01 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 15:57:01 +0000
Subject: [issue32499] Add dataclasses.is_dataclass(obj)
In-Reply-To: <1515185422.79.0.467229070634.issue32499@psf.upfronthosting.co.za>
Message-ID: <1515254221.3.0.467229070634.issue32499@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +4979
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32499>
_______________________________________

From report at bugs.python.org  Sat Jan  6 11:03:44 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 16:03:44 +0000
Subject: [issue32501] Documentation for dir([object])
In-Reply-To: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>
Message-ID: <1515254624.14.0.467229070634.issue32501@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

It's described here: https://docs.python.org/3/reference/datamodel.html#special-lookup

Maybe we should have a glossary entry for "special method lookup", and somehow link mentions like __dir__ to it?

This is slightly different from https://docs.python.org/3/reference/datamodel.html#specialnames, which already has a glossary entry.

On the other hand, unless you already understand the problem, it's going to be difficult to search for it.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Sat Jan  6 11:11:04 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 16:11:04 +0000
Subject: [issue32499] Add dataclasses.is_dataclass(obj)
In-Reply-To: <1515185422.79.0.467229070634.issue32499@psf.upfronthosting.co.za>
Message-ID: <1515255064.07.0.467229070634.issue32499@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I've updated the PEP, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32499>
_______________________________________

From report at bugs.python.org  Sat Jan  6 11:26:26 2018
From: report at bugs.python.org (Andres Petralli)
Date: Sat, 06 Jan 2018 16:26:26 +0000
Subject: [issue32502] uuid1() broken on macos high sierra
Message-ID: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>


New submission from Andres Petralli <anpetral at microsoft.com>:

uuid.py is getting a 64 bit hardware address for the loopback adapter in High Sierra, specifically in _ifconfig_getnode(). The function expects a 48 bit mac address, but is instead getting 64 bits back and converting it to an int value that is too long for the subsequent call in uuid.py. Apple must have moved to using EUI-64 for the loopback adapters.

This is a sample output of the call to ifconfig that is being parsed:

b'lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384\n'
b'\toptions=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>\n'
b'\tinet 127.0.0.1 netmask 0xff000000 \n'
b'\tinet6 ::1 prefixlen 128 \n'
b'\tlladdr 70:cd:60:ff:ab:cd:ef:12 \n'

As you can see, the lladdr is longer than the usual 48 bit mac address but is nontheless returned for the node value, which then triggers

ValueError('field 6 out of range (need a 48-bit value)')


Full traceback:


Traceback (most recent call last):
  File "/Users/andy/Desktop/test.py", line 3, in <module>
    str(uuid.uuid1())
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 607, in uuid1
    clock_seq_hi_variant, clock_seq_low, node), version=1)
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 168, in __init__
    raise ValueError('field 6 out of range (need a 48-bit value)')
ValueError: field 6 out of range (need a 48-bit value)

----------
components: macOS
messages: 309554
nosy: anpetral, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: uuid1() broken on macos high sierra
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:00:05 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Sat, 06 Jan 2018 17:00:05 +0000
Subject: [issue17763] test_pydoc fails with the installed testsuite
In-Reply-To: <1366125816.55.0.847870350484.issue17763@psf.upfronthosting.co.za>
Message-ID: <1515258005.16.0.467229070634.issue17763@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

This is caused by Brailcom's Speech Dispatcher, whose config script ran optparse on import. Apparently it was fixed in their version 0.8.6.

Some references:
https://github.com/brailcom/speechd/commit/1808ea1a6e840951ffde61e5a6476ccfc118ab5a
https://its.freebsoft.org/its/issues/29268
https://bugs.archlinux.org/task/40478
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838665

----------
nosy: +encukou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17763>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:01:31 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 06 Jan 2018 17:01:31 +0000
Subject: [issue17763] test_pydoc fails with the installed testsuite
In-Reply-To: <1366125816.55.0.847870350484.issue17763@psf.upfronthosting.co.za>
Message-ID: <1515258091.14.0.467229070634.issue17763@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17763>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:01:40 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 06 Jan 2018 17:01:40 +0000
Subject: [issue32502] uuid1() broken on macos high sierra
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <65C933AA-5559-4BE8-A653-DC4CA9D8FDE4@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 6, 2018, at 11:26, Andres Petralli <report at bugs.python.org> wrote:
> 
> Traceback (most recent call last):
>  File "/Users/andy/Desktop/test.py", line 3, in <module>
>    str(uuid.uuid1())
>  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 607, in uuid1
>    clock_seq_hi_variant, clock_seq_low, node), version=1)
>  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 168, in __init__
>    raise ValueError('field 6 out of range (need a 48-bit value)')
> ValueError: field 6 out of range (need a 48-bit value)

Interesting.  This doesn?t fail for me on 10.13.2.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:02:24 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 06 Jan 2018 17:02:24 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <1515258144.71.0.467229070634.issue32500@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

If we were to take the docs literally then PySequence_{Size,Length} should just be aliases for PyObject_Size.  But I'm reluctant to change something that has been like this for ages.

In fact maybe we should deprecate them, together with other PySequence_ and PyMapping_ operations that have more general PyObject_ alternatives?

You can read the source code to find the root cause for the behavior -- PySequence_{Size,Length} only looks for tp_as_sequence->sq_length, but dict has that field set to NULL.  (A dict's size is computed by tp_as_mapping->mp_length.)

Fixing dict by adding a redundant sq_length seems brittle (there may be many other mapping types with similar issues).

So I think we should update the docs to recommend PyObject_Size instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:11:21 2018
From: report at bugs.python.org (Olivier Grisel)
Date: Sat, 06 Jan 2018 17:11:21 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515258681.14.0.467229070634.issue31993@psf.upfronthosting.co.za>


Olivier Grisel <olivier.grisel at ensta.org> added the comment:

Shall we close this issue now that the PR has been merged to master?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:32:44 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jan 2018 17:32:44 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515259964.34.0.467229070634.issue31993@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Definitely! Thank you for your contribution :-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:34:03 2018
From: report at bugs.python.org (Olivier Grisel)
Date: Sat, 06 Jan 2018 17:34:03 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515260043.09.0.467229070634.issue31993@psf.upfronthosting.co.za>


Olivier Grisel <olivier.grisel at ensta.org> added the comment:

Thanks for the very helpful feedback and guidance during the review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:41:55 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 17:41:55 +0000
Subject: [issue32499] Add dataclasses.is_dataclass(obj)
In-Reply-To: <1515185422.79.0.467229070634.issue32499@psf.upfronthosting.co.za>
Message-ID: <1515260515.27.0.467229070634.issue32499@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset e7ba013d870012157f695ead7e3645c2828a7fc5 by Eric V. Smith in branch 'master':
bpo-32499: Add dataclasses.is_dataclass(obj), which returns True if obj is a dataclass or an instance of one. (#5113)
https://github.com/python/cpython/commit/e7ba013d870012157f695ead7e3645c2828a7fc5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32499>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:44:16 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 17:44:16 +0000
Subject: [issue32499] Add dataclasses.is_dataclass(obj)
In-Reply-To: <1515185422.79.0.467229070634.issue32499@psf.upfronthosting.co.za>
Message-ID: <1515260656.07.0.467229070634.issue32499@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32499>
_______________________________________

From report at bugs.python.org  Sat Jan  6 12:53:29 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 17:53:29 +0000
Subject: [issue32427] Rename and expose dataclasses._MISSING
In-Reply-To: <1514292226.17.0.213398074469.issue32427@psf.upfronthosting.co.za>
Message-ID: <1515261209.94.0.467229070634.issue32427@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32427>
_______________________________________

From report at bugs.python.org  Sat Jan  6 13:06:48 2018
From: report at bugs.python.org (Andres Petralli)
Date: Sat, 06 Jan 2018 18:06:48 +0000
Subject: [issue32502] uuid1() broken on macos high sierra
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1515262008.03.0.467229070634.issue32502@psf.upfronthosting.co.za>


Andres Petralli <anpetral at microsoft.com> added the comment:

Here's the output from my system. This is a Mac Pro with a firewire port. Looks as if the address was picked up from fw0: actually, not lo0. Guess _find_mac just iterates until it hits a matching word for a hw address:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
UHC58: flags=0<> mtu 0
XHC0: flags=0<> mtu 0
UHC90: flags=0<> mtu 0
UHC61: flags=0<> mtu 0
UHC29: flags=0<> mtu 0
UHC26: flags=0<> mtu 0
UHC93: flags=0<> mtu 0
EHC253: flags=0<> mtu 0
EHC250: flags=0<> mtu 0
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
	lladdr 70:cd:60:ff:ab:cd:ef:12 
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect <full-duplex>
	status: inactive

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Sat Jan  6 13:33:29 2018
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 06 Jan 2018 18:33:29 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515263609.45.0.467229070634.issue32248@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I notice that my 'Installed' builder (http://buildbot.python.org/all/#/builders/103) has been broken since PR4911 landed.  My suspicion is that it's just another directory missed in the Makefile install libinstall target, but haven't actually looked into it.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Sat Jan  6 13:36:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 18:36:38 +0000
Subject: [issue32503] Avoid creating small frames in pickle protocol 4
Message-ID: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Pickle protocol 4 uses framing for reducing the overhead of calling the read() method for small chunks of data. Most read chunks are small -- opcodes, small integers, short strings, etc, and calling read() for every 1 or 4 bytes is too expensive. But using framing itself adds an overhead. It increases the size of pickled data by 9 bytes. A frame  itself needs 3 reads -- the opcode, the frame size, and a payload. Thus it doesn't make sense to create a frame containing less than 3 chunks of data.

For example after issue31993 pickling the list [b'a'*70000, b'b'*70000] with the Python implementation produces a data containing 3 frames of sizes 3, 1 and 3. Using frames here is completely redundant.

----------
components: Library (Lib)
messages: 309564
nosy: Olivier.Grisel, alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Avoid creating small frames in pickle protocol 4
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Sat Jan  6 13:38:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 18:38:40 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515263920.14.0.467229070634.issue31993@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Humm, this feature doesn't work with C implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 13:39:07 2018
From: report at bugs.python.org (stein-k)
Date: Sat, 06 Jan 2018 18:39:07 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1515263947.19.0.467229070634.issue32498@psf.upfronthosting.co.za>


stein-k <karlsen.stein at gmail.com> added the comment:

The message is incorrect for the input to the function, and confusing because the caller did supply a bytes-like object.

The exception is from an implementation detail, and if the implementation changes the exception could as well. 

I suggest the implementation is changed to follow the example of  urllib.parse.unquote_to_bytes, which encodes its string parameter to bytes if it receives a str object.

Alternatively, a check for required type should be implemented and raise a TypeError with the correct error-message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Sat Jan  6 13:44:05 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sat, 06 Jan 2018 18:44:05 +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: <1515264245.16.0.467229070634.issue9325@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

pdb and cProfile are covered.

If no one is working on it, do you want me try to put through a patch for "profile" and "trace"?
Should I create a separate issue if so?

>From Issue 17473 it will leave only:

doctest: Which might be controversial
dis: main is execution a "_test" function. That said, running -m dis might be useful.

The rest might not need the change as:

modulefinder: __main__ is for test purposes
tabnanny: works on files and directories
pyclbr: already works with modules

----------
nosy: +mariocj89

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Sat Jan  6 13:49:22 2018
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 06 Jan 2018 18:49:22 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1515264562.63.0.467229070634.issue31340@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

> Have you confirmed that's a problem?

No, I have not noticed any problems yet with with Python 3.7.0a3 and many extensions built with VS2017.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Sat Jan  6 14:02:08 2018
From: report at bugs.python.org (atya)
Date: Sat, 06 Jan 2018 19:02:08 +0000
Subject: [issue32504] Wheel failed include data_files
Message-ID: <1515265328.42.0.467229070634.issue32504@psf.upfronthosting.co.za>


New submission from atya <newatar51 at gmail.com>:

Hi,

I created a  wheel using python3.4 install bdist_wheel command.

I have data dir and in contains files Test.png.

in setup.py I added
data_files=[
        ('/usr/share', ['data/Test.png'])
        ]

when I am instaating the wheel the data files did not copy.

----------
components: Build
messages: 309569
nosy: atya
priority: normal
severity: normal
status: open
title: Wheel failed include data_files
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32504>
_______________________________________

From report at bugs.python.org  Sat Jan  6 14:15:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 19:15:09 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515266109.53.0.467229070634.issue31993@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4980

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 14:16:07 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jan 2018 19:16:07 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515266167.38.0.467229070634.issue31993@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Humm, this feature doesn't work with C implementation.

What do you mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 14:17:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 19:17:28 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515266248.39.0.467229070634.issue31993@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 5114 implements this when serialize in C into memory.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 14:26:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 19:26:22 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1515266167.38.0.467229070634.issue31993@psf.upfronthosting.co.za>
Message-ID: <7115898.UxAeGM59bJ@saraksh>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> What do you mean?

Large bytes and strings was written inside a frame when serialize by dumps(). 
dump() (as well as Python implementations of dumps() and dump()) write them 
outside of a frame.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:01:32 2018
From: report at bugs.python.org (Gregory Szorc)
Date: Sat, 06 Jan 2018 20:01:32 +0000
Subject: [issue31148] Can we get an MSI installer for something past 3.4.4?
In-Reply-To: <1502210311.11.0.464984034279.issue31148@psf.upfronthosting.co.za>
Message-ID: <1515268892.87.0.467229070634.issue31148@psf.upfronthosting.co.za>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

I was going to update some CI that tests all supported versions of Python and pins the Python 3 versions. That CI was previously using the MSI installers for Python 3.4. To my surprise, the MSIs stopped being generated after the 3.4.4 release! https://www.python.org/ftp/python/3.4.4/ has MSIs (and MacOS .pkg files). But all subsequent releases (e.g. https://www.python.org/ftp/python/3.4.7/) do not.

I'm OK with the decision to abandon MSIs and move to the .exe installer for newer Python releases (like 3.5 and 3.6). However, ceasing to produce the MSIs (and MacOS .pkg files for that matter) midway through 3.4's support cycle feels wrong to me. 3.4.4 was the last release with binary distributions for Windows and MacOS. 3.4.5 and newer releases have fixes to security issues. That means people using the binary distributions of 3.4 on these platforms are stuck on 3.4.4 and are thus vulnerable to known security issues. That's... not great.

I think the MSI (and .pkg) distributions should be restored for 3.4. Furthermore, I would encourage Python to adopt the practice that distribution mechanisms aren't modified during a Python version's support cycle. Someone will inevitably rely on any distribution format that is published. And taking it away in a support cycle will orphan those users on an old, buggy release.

----------
nosy: +Gregory.Szorc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31148>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:09:55 2018
From: report at bugs.python.org (Yuri Kanivetsky)
Date: Sat, 06 Jan 2018 20:09:55 +0000
Subject: [issue32450] non-descriptive variable name
In-Reply-To: <1514598581.85.0.213398074469.issue32450@psf.upfronthosting.co.za>
Message-ID: <1515269395.35.0.467229070634.issue32450@psf.upfronthosting.co.za>


Yuri Kanivetsky <yuri.kanivetsky at gmail.com> added the comment:

Well, it's just that I was digging into Python's code. And it took me quite a while to figure out what the variable holds. Running into "ndots" name clarified that. That generally means that variable name doesn't describe its content well. But I'm new to Python's code, so it might not be the case. Feel free to close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32450>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:17:24 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 20:17:24 +0000
Subject: [issue32278] Allow dataclasses.make_dataclass() to omit type
 information
In-Reply-To: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za>
Message-ID: <1515269844.23.0.467229070634.issue32278@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests: +4981

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32278>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:17:33 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 20:17:33 +0000
Subject: [issue32450] non-descriptive variable name
In-Reply-To: <1514598581.85.0.213398074469.issue32450@psf.upfronthosting.co.za>
Message-ID: <1515269853.3.0.467229070634.issue32450@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32450>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:19:27 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 20:19:27 +0000
Subject: [issue32504] Wheel failed include data_files
In-Reply-To: <1515265328.42.0.467229070634.issue32504@psf.upfronthosting.co.za>
Message-ID: <1515269967.92.0.467229070634.issue32504@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please report to the wheel maintainers at https://github.com/pypa/wheel

----------
nosy: +benjamin.peterson
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32504>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:21:31 2018
From: report at bugs.python.org (Matthew Cowles)
Date: Sat, 06 Jan 2018 20:21:31 +0000
Subject: [issue32501] Documentation for dir([object])
In-Reply-To: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>
Message-ID: <1515270091.16.0.467229070634.issue32501@psf.upfronthosting.co.za>


Matthew Cowles <mdcowles at users.sourceforge.net> added the comment:

If David is right and people have previously decided not to change wording like this, can someone explain why? As it stands, the meaning is clear and incorrect.

----------
nosy: +mdcowles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:48:46 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sat, 06 Jan 2018 20:48:46 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <1515271726.26.0.467229070634.issue32500@psf.upfronthosting.co.za>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Well, my two main concerns are:

1) whether it is acceptable for PyPy to not raise TypeError in this case, or if I should report it to PyPy upstream as a bug,

2) and whether programmers can appropriately rely on PySequence_Length() raising TypeError for non-sequence types or if they should use e.g. PySequence_Check() explicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:52:28 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jan 2018 20:52:28 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1515271948.98.0.467229070634.issue32441@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I suspect the dup3_works variable is supposed to be static.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Sat Jan  6 15:56:51 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 06 Jan 2018 20:56:51 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1515263609.45.0.467229070634.issue32248@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W5FtpdK1LNWduTrHbPGtfNtHMKS-JAkow-0W-MKe8+XJQ@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

I bet Barry forgot to add some test directories to the makefile.

On Sat, Jan 6, 2018, 10:33 Zachary Ware, <report at bugs.python.org> wrote:

>
> Zachary Ware <zachary.ware at gmail.com> added the comment:
>
> I notice that my 'Installed' builder (
> http://buildbot.python.org/all/#/builders/103) has been broken since
> PR4911 landed.  My suspicion is that it's just another directory missed in
> the Makefile install libinstall target, but haven't actually looked into it.
>
> ----------
> nosy: +zach.ware
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32248>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Sat Jan  6 16:14:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 21:14:05 +0000
Subject: [issue32278] Allow dataclasses.make_dataclass() to omit type
 information
In-Reply-To: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za>
Message-ID: <1515273245.34.0.467229070634.issue32278@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset ed7d429ebb591f65cef558760fb4ebdc4fc8f8b0 by Eric V. Smith in branch 'master':
bpo-32278: Allow dataclasses.make_dataclass() to omit type information. (gh-5115)
https://github.com/python/cpython/commit/ed7d429ebb591f65cef558760fb4ebdc4fc8f8b0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32278>
_______________________________________

From report at bugs.python.org  Sat Jan  6 16:14:50 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 21:14:50 +0000
Subject: [issue32278] Allow dataclasses.make_dataclass() to omit type
 information
In-Reply-To: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za>
Message-ID: <1515273290.08.0.467229070634.issue32278@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32278>
_______________________________________

From report at bugs.python.org  Sat Jan  6 16:16:47 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 06 Jan 2018 21:16:47 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515271726.26.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+9vdoGjQRQxXbtysEeCfD6Utvh9VD6STSRMZOy7rqAgw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Since docs and implementation disagree let's call it undefined. I really
can't comment on what PyPy should do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 16:30:03 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 06 Jan 2018 21:30:03 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1515263609.45.0.467229070634.issue32248@psf.upfronthosting.co.za>
Message-ID: <A3921D95-3AB5-4C76-8CA9-4C1060EA6FD5@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 6, 2018, at 13:33, Zachary Ware <report at bugs.python.org> wrote:
> 
> I notice that my 'Installed' builder (http://buildbot.python.org/all/#/builders/103) has been broken since PR4911 landed.  My suspicion is that it's just another directory missed in the Makefile install libinstall target, but haven't actually looked into it.

Dang.  I?ll try to look into this as soon as possible, but it might be a day or so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Sat Jan  6 16:48:16 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 21:48:16 +0000
Subject: [issue32279] Pass keyword arguments from dataclasses.make_dataclass()
 to @dataclass.
In-Reply-To: <1513022338.87.0.213398074469.issue32279@psf.upfronthosting.co.za>
Message-ID: <1515275296.04.0.467229070634.issue32279@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +4982
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32279>
_______________________________________

From report at bugs.python.org  Sat Jan  6 16:51:32 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 21:51:32 +0000
Subject: [issue32279] Pass keyword arguments from dataclasses.make_dataclass()
 to @dataclass.
In-Reply-To: <1513022338.87.0.213398074469.issue32279@psf.upfronthosting.co.za>
Message-ID: <1515275492.59.0.467229070634.issue32279@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests: +4983

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32279>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:10:00 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:10:00 +0000
Subject: [issue32279] Pass keyword arguments from dataclasses.make_dataclass()
 to @dataclass.
In-Reply-To: <1513022338.87.0.213398074469.issue32279@psf.upfronthosting.co.za>
Message-ID: <1515276600.61.0.467229070634.issue32279@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset d80b443f02e087dd289ffefd04179c675304d76d by Eric V. Smith in branch 'master':
 bpo-32279: Add additional params to make_dataclass(), pass through to dataclass(). (gh-5117)
https://github.com/python/cpython/commit/d80b443f02e087dd289ffefd04179c675304d76d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32279>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:14:16 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:14:16 +0000
Subject: [issue32279] Pass keyword arguments from dataclasses.make_dataclass()
 to @dataclass.
In-Reply-To: <1513022338.87.0.213398074469.issue32279@psf.upfronthosting.co.za>
Message-ID: <1515276856.95.0.467229070634.issue32279@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32279>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:19:35 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:19:35 +0000
Subject: [issue32428] dataclasses: make it an error to have initialized
 non-fields in a dataclass
In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>
Message-ID: <1515277175.7.0.467229070634.issue32428@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm closing this, and will open another issue to raise an error for:

@dataclass
class C:
    x = field()

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:20:53 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 06 Jan 2018 22:20:53 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1515277253.03.0.467229070634.issue32441@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Good catch, the code makes much more sense now :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:21:04 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:21:04 +0000
Subject: [issue32505] dataclasses: make field() with no annotation an error
Message-ID: <1515277264.9.0.467229070634.issue32505@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

This is an attractive nuisance, especially when coming from attrs. Make it an error, since it's using field() with no annotation:

@dataclass
class C:
    x = field()

----------
assignee: eric.smith
messages: 309586
nosy: eric.smith, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: dataclasses: make field() with no annotation an error
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:21:25 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:21:25 +0000
Subject: [issue32505] dataclasses: make field() with no annotation an error
In-Reply-To: <1515277264.9.0.467229070634.issue32505@psf.upfronthosting.co.za>
Message-ID: <1515277285.48.0.467229070634.issue32505@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:23:30 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:23:30 +0000
Subject: [issue32506] dataclasses: no need for OrderedDict now that dict
 guarantees to keep insertion order
Message-ID: <1515277410.84.0.467229070634.issue32506@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

There are several places where OrderedDict escapes from dataclasses. Switching to dict means we don't have to use OrderedDict forever.

For the 3.6 backport, I'm also going to use dict. I saw an analysis (from Raymond, maybe?) that says there are no 3.6 implementations that don't guarantee insertion order for dict.

----------
assignee: eric.smith
messages: 309587
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: no need for OrderedDict now that dict guarantees to keep insertion order
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32506>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:54:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 22:54:16 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <1515279256.08.0.467229070634.issue32500@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Note that many other PySequence_* functions support only sequences. For example PySequence_Count(o1, o2) is the equivalent of the Python expression o1 + o2 only if o1 is a sequence. If pass integer objects to PySequence_Count() it will return an error.

I would remove "do not" from the documentation. Or even the whole "For objects that do not provide sequence protocol" since this is implied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 18:59:01 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 06 Jan 2018 23:59:01 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
Message-ID: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

There's enough instability due to using the proper UCRT installer (e.g. issue25546, issue25954, also others not reported on bpo) and good enough install base that we can simplify things by just installing it locally on machines that require it.

This may also require updating venv (though I think we're fine) and virtualenv (I'll ping).

My proposal is to bundle the UCRT redistributable DLLs into their own MSI and install them alongside the main executable when required. If a user later installs it properly, the up-to-date version will be used instead. This should be good enough to cover people still on Windows 7/8, and will also reduce the installer size slightly (though at the cost of potentially breaking non-standard virtual environments or entrypoint stubs that link to the CRT dynamically).

----------
assignee: steve.dower
components: Windows
messages: 309589
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Change Windows install to applocal UCRT
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sat Jan  6 18:59:26 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 06 Jan 2018 23:59:26 +0000
Subject: [issue25954] Python 3.5.1 installer fails on Windows 7
In-Reply-To: <1451100442.78.0.216176327365.issue25954@psf.upfronthosting.co.za>
Message-ID: <1515283166.03.0.467229070634.issue25954@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> Change Windows install to applocal UCRT

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25954>
_______________________________________

From report at bugs.python.org  Sat Jan  6 18:59:41 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 06 Jan 2018 23:59:41 +0000
Subject: [issue25546] python 3.5 installation problem;
 Error 0x80240017: Failed to execute MSU package
In-Reply-To: <1446565273.63.0.514880871574.issue25546@psf.upfronthosting.co.za>
Message-ID: <1515283181.87.0.467229070634.issue25546@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> Change Windows install to applocal UCRT

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

From report at bugs.python.org  Sat Jan  6 19:14:29 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 07 Jan 2018 00:14:29 +0000
Subject: [issue32428] dataclasses: make it an error to have initialized
 non-fields in a dataclass
In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>
Message-ID: <1515284069.17.0.467229070634.issue32428@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

@Eric
> I'm closing this, and will open another issue to raise an error for: ...

I think we also need a separate issue for not overriding __repr__ etc, if '__repr__' in cls.__dict__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Sat Jan  6 19:17:53 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 07 Jan 2018 00:17:53 +0000
Subject: [issue32428] dataclasses: make it an error to have initialized
 non-fields in a dataclass
In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za>
Message-ID: <1515284273.06.0.467229070634.issue32428@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Correct. I'm working on that one now. I'll open it tonight or tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32428>
_______________________________________

From report at bugs.python.org  Sat Jan  6 19:20:36 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 00:20:36 +0000
Subject: [issue31148] Can we get an MSI installer for something past 3.4.4?
In-Reply-To: <1502210311.11.0.464984034279.issue31148@psf.upfronthosting.co.za>
Message-ID: <1515284436.78.0.467229070634.issue31148@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

It is standard procedure for us to stop producing binary releases when a version switches to security-only mode. The burden on our volunteers would become overwhelming otherwise.

If you'd like to propose a change to this policy, start by posting on python-list, and then if there is general support someone there will bring the conversation to the development team. Resurrecting old bugs is not an efficient way to request this kind of change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31148>
_______________________________________

From report at bugs.python.org  Sat Jan  6 20:34:15 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 01:34:15 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515288855.1.0.467229070634.issue32507@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +4984
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sat Jan  6 20:34:16 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 01:34:16 +0000
Subject: [issue29911] Uninstall command line in Windows registry does not
 uninstall
In-Reply-To: <1490551774.28.0.407532543156.issue29911@psf.upfronthosting.co.za>
Message-ID: <1515288856.15.0.574204596225.issue29911@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +4986
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29911>
_______________________________________

From report at bugs.python.org  Sat Jan  6 20:34:16 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 01:34:16 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515288856.18.0.467229070634.issue32507@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch
pull_requests: +4984, 4985
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sat Jan  6 20:36:14 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 01:36:14 +0000
Subject: [issue28888] Installer fails when newer version of CRT is pending
 installation
In-Reply-To: <1481045991.8.0.918552180321.issue28888@psf.upfronthosting.co.za>
Message-ID: <1515288974.81.0.467229070634.issue28888@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

This will be fixed by the change for 3.7, and it's enough of an edge case for 3.6 that I'm okay with not fixing it.

----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Change Windows install to applocal UCRT

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28888>
_______________________________________

From report at bugs.python.org  Sat Jan  6 20:37:04 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 01:37:04 +0000
Subject: [issue29409] Implement PEP 529 for io.FileIO
In-Reply-To: <1485918380.71.0.564330613462.issue29409@psf.upfronthosting.co.za>
Message-ID: <1515289024.12.0.467229070634.issue29409@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29409>
_______________________________________

From report at bugs.python.org  Sat Jan  6 20:46:30 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 01:46:30 +0000
Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback
In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za>
Message-ID: <1515289590.7.0.467229070634.issue28747@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

The change to make OpenSSL a separate DLL (on Windows, at least, which is all I really care about) means this function is available via ctypes. That's good enough for me, so I'll close this.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28747>
_______________________________________

From report at bugs.python.org  Sat Jan  6 21:05:21 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 02:05:21 +0000
Subject: [issue32282] When using a Windows XP compatible toolset,
 `socketmodule.c` fails to build
In-Reply-To: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za>
Message-ID: <1515290721.35.0.467229070634.issue32282@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset af11a15c586e980a157c04ee60b6e33dc7228f3f by Steve Dower (Max B?langer) in branch 'master':
bpo-32282: Remove unnecessary check for `VersionHelpers.h` in `socketmodule.c` on Windows
https://github.com/python/cpython/commit/af11a15c586e980a157c04ee60b6e33dc7228f3f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32282>
_______________________________________

From report at bugs.python.org  Sat Jan  6 21:05:59 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Jan 2018 02:05:59 +0000
Subject: [issue32282] When using a Windows XP compatible toolset,
 `socketmodule.c` fails to build
In-Reply-To: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za>
Message-ID: <1515290759.0.0.467229070634.issue32282@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4987

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32282>
_______________________________________

From report at bugs.python.org  Sat Jan  6 21:22:32 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jan 2018 02:22:32 +0000
Subject: [issue32501] Documentation for dir([object])
In-Reply-To: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>
Message-ID: <1515291752.92.0.467229070634.issue32501@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure, but the discussion I remember was that it would require changes to an awful lot of places in the docs that would make the docs harder to read.  It is very seldom in normal Python coding that an object has a method that it does *not* get from its class, and by the time you get to the level where you are adding methods to instances it is likely you know about dunder methods only being looked up on classes.  Usually you learn about it the first time you try to put a dunder method on an instance, and you scratch your head for a while, and then you find out...but complicating the docs to mention this at every turn would be...excessive, I think.  But again, I'm not 100% sure I'm remembering the outcome of that conversation, and I can't remember where it took place (it was an issue in this tracker, but I don't know which one.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Sat Jan  6 21:37:23 2018
From: report at bugs.python.org (J Viswanathan)
Date: Sun, 07 Jan 2018 02:37:23 +0000
Subject: [issue32508] Problem while reading back from a list of lists
Message-ID: <CAPsjwoCgBoN=o=ZPyzM_1prYvRW2+5vivak3ZOUEU4nBiz+COw@mail.gmail.com>


New submission from J Viswanathan <Viswanathan10 at gmail.com>:

Please see the attached source file,  the related data file and the log
file.

When run with

 python hksu_copy.py  check_su.dat

the following is the output (which is incorrect):

-*- mode: compilation; default-directory: "c:/Users/J V/Documents/gamsdir/"
-*-
Compilation started at Sun Jan  7 07:54:52

python hksu_copy.py check_su.dat
nedge, check_k 1 1
nedge, check_k 2 2
nedge, check_k 3 4
nedge, check_k 4 2
nedge, klist 4 [1, 2, 4]
nedge, check_k 5 4
nedge, check_k 6 7
nedge, check_k 7 2
nedge, klist 7 [2, 4, 7]
nedge, check_k 8 4
nedge, check_k 9 7
nedge, check_k 10 1
nedge, klist 10 [2, 4, 7]
nedge, check_k 11 2
nedge, check_k 12 2
nedge, klist 12 [1, 2]
nedge, check_k 13 6
nedge, check_k 14 2
nedge, klist 14 [2, 6]
nedge, check_k 15 4
nedge, check_k 16 6
nedge, check_k 17 8
nedge, check_k 18 2
nedge, klist 18 [2, 4, 6, 8]
nedge, check_k 19 3
nedge, check_k 20 3
nedge, klist 20 [2, 3]
nedge, check_k 21 4
nedge, check_k 22 2
nedge, klist 22 [3, 4]
nedge, check_k 23 4
nedge, check_k 24 1
nedge, klist 24 [2, 4]
nedge, check_k 25 4
nedge, check_k 26 8
nedge, check_k 27 9
nedge, check_k 28 1
nedge, klist 28 [1, 4, 8, 9]
nedge, check_k 29 2
nedge, check_k 30 4
nedge, check_k 31 9
nedge, check_k 32 2
nedge, klist 32 [1, 2, 4, 9]
nedge, check_k 33 4
nedge, check_k 34 8
nedge, check_k 35 3
nedge, klist 35 [2, 4, 8]
nedge, check_k 36 4
nedge, check_k 37 7
nedge, check_k 38 8
nedge, check_k 39 2
nedge, klist 39 [3, 4, 7, 8]
nedge, check_k 40 3
nedge, check_k 41 4
nedge, check_k 42 2
nedge, klist 42 [2, 3, 4]
nedge, check_k 43 4
nedge, check_k 44 7
nedge, check_k 45 8
nedge, check_k 46 1
nedge, klist 46 [2, 4, 7, 8]
nedge, check_k 47 3
nedge, check_k 48 4
nedge, check_k 49 5
nedge, check_k 50 7
nedge, check_k 51 2
nedge, klist 51 [1, 3, 4, 5, 7]
nedge, check_k 52 4
nedge, check_k 53 7
nedge, check_k 54 1
nedge, klist 54 [2, 4, 7]
nedge, check_k 55 2
nedge, check_k 56 5
nedge, check_k 57 1
nedge, klist 57 [1, 2, 5]
nedge, check_k 58 2
nedge, check_k 59 5
nedge, check_k 60 9
nedge, check_k 61 2
nedge, klist 61 [1, 2, 5, 9]
nedge, check_k 62 5
nedge, check_k 63 2
nedge, klist 63 [2, 5]
nedge, check_k 64 5
nedge, check_k 65 6
nedge, check_k 66 9
nedge, check_k 67 1
nedge, klist 67 [2, 5, 6, 9]
nedge, check_k 68 5
nedge, check_k 69 1
nedge, klist 69 [1, 5]
nedge, check_k 70 3
nedge, check_k 71 5
nedge, check_k 72 9
nedge, check_k 73 5
nedge, klist 73 [1, 3, 5, 9]
nedge, check_k 74 7
nedge, check_k 75 9
nedge, check_k 76 1
nedge, klist 76 [5, 7, 9]
nedge, check_k 77 4
nedge, check_k 78 7
nedge, check_k 79 5
nedge, klist 79 [1, 4, 7]
nedge, check_k 80 5
nedge, klist 80 [5]
nedge, check_k 81 9
nedge, check_k 82 1
nedge, klist 82 [5, 9]
nedge, check_k 83 4
nedge, check_k 84 4
nedge, klist 84 [1, 4]
nedge, check_k 85 5
nedge, check_k 86 7
nedge, check_k 87 9
nedge, check_k 88 2
nedge, klist 88 [4, 5, 7, 9]
nedge, check_k 89 4
nedge, check_k 90 5
nedge, check_k 91 9
nedge, check_k 92 5
nedge, klist 92 [2, 4, 5, 9]
nedge, check_k 93 7
nedge, check_k 94 9
nedge, check_k 95 2
nedge, klist 95 [5, 7, 9]
nedge, check_k 96 5
nedge, check_k 97 9
nedge, check_k 98 4
nedge, klist 98 [2, 5, 9]
nedge, check_k 99 5
nedge, check_k 100 8
nedge, check_k 101 9
nedge, check_k 102 4
nedge, klist 102 [4, 5, 8, 9]
nedge, check_k 103 5
nedge, check_k 104 9
nedge, check_k 105 1
nedge, klist 105 [4, 5, 9]
nedge, check_k 106 3
nedge, check_k 107 9
nedge, check_k 108 1
nedge, klist 108 [1, 3, 9]
nedge, check_k 109 3
nedge, check_k 110 4
nedge, check_k 111 5
nedge, check_k 112 7
nedge, check_k 113 9
nedge, check_k 114 2
nedge, klist 114 [1, 3, 4, 5, 7, 9]
nedge, check_k 115 3
nedge, check_k 116 2
nedge, klist 116 [2, 3]
nedge, check_k 117 7
nedge, check_k 118 8
nedge, check_k 119 2
nedge, klist 119 [2, 7, 8]
nedge, check_k 120 3
nedge, check_k 121 7
nedge, check_k 122 1
nedge, klist 122 [2, 3, 7]
nedge, check_k 123 2
nedge, check_k 124 3
nedge, check_k 125 1
nedge, klist 125 [1, 2, 3]
nedge, check_k 126 2
nedge, check_k 127 4
nedge, check_k 128 5
nedge, check_k 129 1
nedge, klist 129 [1, 2, 4, 5]
nedge, check_k 130 2
nedge, check_k 131 3
nedge, check_k 132 4
nedge, check_k 133 5
nedge, check_k 134 3
nedge, klist 134 [1, 2, 3, 4, 5]
nedge, check_k 135 5
nedge, check_k 136 7
nedge, check_k 137 3
nedge, klist 137 [3, 5, 7]
nedge, check_k 138 5
nedge, check_k 139 7
nedge, klist 139 [3, 5]
nedge, check_k 140 2
nedge, klist 140 [7]
nedge, check_k 141 3
nedge, check_k 142 5
nedge, check_k 143 6
nedge, check_k 144 2
nedge, klist 144 [2, 3, 5, 6]
nedge, check_k 145 6
nedge, check_k 146 4
nedge, klist 146 [2, 6]
nedge, check_k 147 3
nedge, klist 147 [4]
nedge, check_k 148 6
nedge, check_k 149 3
nedge, klist 149 [3, 6]
nedge, check_k 150 1
nedge, klist 150 [3]
nedge, check_k 151 3
nedge, check_k 152 4
nedge, check_k 153 6
 No. of edges:  153
The last of the klists : nedge, klist 153 [1, 3, 4, 6]
 No. of left vertices :  51  No. of right vertices :  51
x :  0  klist :  [1, 3, 4, 6]
x :  1  klist :  [1, 3, 4, 6]
x :  2  klist :  [1, 3, 4, 6]
x :  3  klist :  [1, 3, 4, 6]
x :  4  klist :  [1, 3, 4, 6]
x :  5  klist :  [1, 3, 4, 6]
x :  6  klist :  [1, 3, 4, 6]
x :  7  klist :  [1, 3, 4, 6]
x :  8  klist :  [1, 3, 4, 6]
x :  9  klist :  [1, 3, 4, 6]
x :  10  klist :  [1, 3, 4, 6]
x :  11  klist :  [1, 3, 4, 6]
x :  12  klist :  [1, 3, 4, 6]
x :  13  klist :  [1, 3, 4, 6]
x :  14  klist :  [1, 3, 4, 6]
x :  15  klist :  [1, 3, 4, 6]
x :  16  klist :  [1, 3, 4, 6]
x :  17  klist :  [1, 3, 4, 6]
x :  18  klist :  [1, 3, 4, 6]
x :  19  klist :  [1, 3, 4, 6]
x :  20  klist :  [1, 3, 4, 6]
x :  21  klist :  [1, 3, 4, 6]
x :  22  klist :  [1, 3, 4, 6]
x :  23  klist :  [1, 3, 4, 6]
x :  24  klist :  [1, 3, 4, 6]
x :  25  klist :  [1, 3, 4, 6]
x :  26  klist :  [1, 3, 4, 6]
x :  27  klist :  [1, 3, 4, 6]
x :  28  klist :  [1, 3, 4, 6]
x :  29  klist :  [1, 3, 4, 6]
x :  30  klist :  [1, 3, 4, 6]
x :  31  klist :  [1, 3, 4, 6]
x :  32  klist :  [1, 3, 4, 6]
x :  33  klist :  [1, 3, 4, 6]
x :  34  klist :  [1, 3, 4, 6]
x :  35  klist :  [1, 3, 4, 6]
x :  36  klist :  [1, 3, 4, 6]
x :  37  klist :  [1, 3, 4, 6]
x :  38  klist :  [1, 3, 4, 6]
x :  39  klist :  [1, 3, 4, 6]
x :  40  klist :  [1, 3, 4, 6]
x :  41  klist :  [1, 3, 4, 6]
x :  42  klist :  [1, 3, 4, 6]
x :  43  klist :  [1, 3, 4, 6]
x :  44  klist :  [1, 3, 4, 6]
x :  45  klist :  [1, 3, 4, 6]
x :  46  klist :  [1, 3, 4, 6]
x :  47  klist :  [1, 3, 4, 6]
x :  48  klist :  [1, 3, 4, 6]
x :  49  klist :  [1, 3, 4, 6]
x :  50  klist :  [1, 3, 4, 6]

Compilation finished at Sun Jan  7 07:54:52

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

The correct  results are:

x: 0    klist: [1,2,4]
x: 1    klist  [2,4,7]
x:2     klist: [2,4,7]

etc.

----------
files: check_su.dat, compilation_log, hksu_copy.py
messages: 309597
nosy: JHari
priority: normal
severity: normal
status: open
title: Problem while reading back from a list of lists
Added file: https://bugs.python.org/file47367/hksu_copy.py
Added file: https://bugs.python.org/file47368/check_su.dat
Added file: https://bugs.python.org/file47369/compilation_log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32508>
_______________________________________
-------------- next part --------------

from re import compile, findall

from locale import atoi

uids = []
klists = []

def read_input(input):
    nedge = 0
    check_uid =[0,0,0,0]
    klist = []
    regex = compile('[^ \t\n]+')

    with  open(input, 'r') as f:

        for line in f:

            indices = findall(regex, line)
            if len(indices) != 5 :
                print ('read input: len(indices)', len(indices))
                exit
                
            nedge += 1

            lid = indices[0:4]
            check_k = atoi(indices[4])

            print ('nedge, check_k', nedge, check_k)

            if (lid == check_uid): #an existing uid
                klist.append(check_k)
            else:
                check_uid = lid
                uids.append(check_uid) # a new
                if len(klist):
                    klists.append(klist)
                    print ('nedge, klist', nedge, klist)
                    klist.clear()
                klist.append(check_k)
            #end of if block
        #end of for block
        
    print(' No. of edges: ', nedge)
    print ('The last of the klists : nedge, klist', nedge, klist)
    klists.append(klist)   # The last of the klists
    
def generate_sudoku_data():
    nleft = len(uids)
    nright = len(klists)
    print( ' No. of left vertices : ', nleft,
           ' No. of right vertices : ', nright)
    if nleft != nright:
        print ('generate_sudoku_data: nright', nright)
        exit

    for x in range(0, nleft, 1):
        klist = klists[x]
        print('x : ', x, ' klist : ', klist)



def HK(input):
    read_input(input)
    generate_sudoku_data()

if __name__ == "__main__":
    import sys
    HK(sys.argv[1])
-------------- next part --------------
1 1 1 3 1
1 1 1 3 2
1 1 1 3 4
1 1 2 2 2
1 1 2 2 4
1 1 2 2 7
1 1 2 3 2
1 1 2 3 4
1 1 2 3 7
1 1 3 1 1
1 1 3 1 2
1 2 1 4 2
1 2 1 4 6
1 2 1 6 2
1 2 1 6 4
1 2 1 6 6
1 2 1 6 8
1 2 3 4 2
1 2 3 4 3
1 2 3 5 3
1 2 3 5 4
1 2 3 6 2
1 2 3 6 4
1 3 1 7 1
1 3 1 7 4
1 3 1 7 8
1 3 1 7 9
1 3 1 8 1
1 3 1 8 2
1 3 1 8 4
1 3 1 8 9
1 3 1 9 2
1 3 1 9 4
1 3 1 9 8
1 3 2 7 3
1 3 2 7 4
1 3 2 7 7
1 3 2 7 8
1 3 2 8 2
1 3 2 8 3
1 3 2 8 4
1 3 2 9 2
1 3 2 9 4
1 3 2 9 7
1 3 2 9 8
1 3 3 7 1
1 3 3 7 3
1 3 3 7 4
1 3 3 7 5
1 3 3 7 7
1 3 3 9 2
1 3 3 9 4
1 3 3 9 7
2 1 4 2 1
2 1 4 2 2
2 1 4 2 5
2 1 4 3 1
2 1 4 3 2
2 1 4 3 5
2 1 4 3 9
2 1 5 2 2
2 1 5 2 5
2 1 5 3 2
2 1 5 3 5
2 1 5 3 6
2 1 5 3 9
2 1 6 2 1
2 1 6 2 5
2 1 6 3 1
2 1 6 3 3
2 1 6 3 5
2 1 6 3 9
2 2 4 4 5
2 2 4 4 7
2 2 4 4 9
2 2 4 6 1
2 2 4 6 4
2 2 4 6 7
2 2 5 5 5
2 2 6 4 5
2 2 6 4 9
2 2 6 6 1
2 2 6 6 4
2 3 4 7 4
2 3 4 7 5
2 3 4 7 7
2 3 4 7 9
2 3 4 8 2
2 3 4 8 4
2 3 4 8 5
2 3 4 8 9
2 3 5 7 5
2 3 5 7 7
2 3 5 7 9
2 3 5 8 2
2 3 5 8 5
2 3 5 8 9
2 3 6 7 4
2 3 6 7 5
2 3 6 7 8
2 3 6 7 9
2 3 6 8 4
2 3 6 8 5
2 3 6 8 9
3 1 7 1 1
3 1 7 1 3
3 1 7 1 9
3 1 7 3 1
3 1 7 3 3
3 1 7 3 4
3 1 7 3 5
3 1 7 3 7
3 1 7 3 9
3 1 8 1 2
3 1 8 1 3
3 1 8 2 2
3 1 8 2 7
3 1 8 2 8
3 1 8 3 2
3 1 8 3 3
3 1 8 3 7
3 1 9 1 1
3 1 9 1 2
3 1 9 1 3
3 1 9 2 1
3 1 9 2 2
3 1 9 2 4
3 1 9 2 5
3 1 9 3 1
3 1 9 3 2
3 1 9 3 3
3 1 9 3 4
3 1 9 3 5
3 2 7 4 3
3 2 7 4 5
3 2 7 4 7
3 2 7 5 3
3 2 7 5 5
3 2 7 6 7
3 2 9 4 2
3 2 9 4 3
3 2 9 4 5
3 2 9 4 6
3 2 9 6 2
3 2 9 6 6
3 3 7 9 4
3 3 8 7 3
3 3 8 7 6
3 3 8 8 3
3 3 9 7 1
3 3 9 7 3
3 3 9 7 4
3 3 9 7 6
-------------- next part --------------
-*- mode: compilation; default-directory: "c:/Users/J V/Documents/gamsdir/" -*-
Compilation started at Sun Jan  7 07:54:52

python hksu_copy.py check_su.dat
nedge, check_k 1 1
nedge, check_k 2 2
nedge, check_k 3 4
nedge, check_k 4 2
nedge, klist 4 [1, 2, 4]
nedge, check_k 5 4
nedge, check_k 6 7
nedge, check_k 7 2
nedge, klist 7 [2, 4, 7]
nedge, check_k 8 4
nedge, check_k 9 7
nedge, check_k 10 1
nedge, klist 10 [2, 4, 7]
nedge, check_k 11 2
nedge, check_k 12 2
nedge, klist 12 [1, 2]
nedge, check_k 13 6
nedge, check_k 14 2
nedge, klist 14 [2, 6]
nedge, check_k 15 4
nedge, check_k 16 6
nedge, check_k 17 8
nedge, check_k 18 2
nedge, klist 18 [2, 4, 6, 8]
nedge, check_k 19 3
nedge, check_k 20 3
nedge, klist 20 [2, 3]
nedge, check_k 21 4
nedge, check_k 22 2
nedge, klist 22 [3, 4]
nedge, check_k 23 4
nedge, check_k 24 1
nedge, klist 24 [2, 4]
nedge, check_k 25 4
nedge, check_k 26 8
nedge, check_k 27 9
nedge, check_k 28 1
nedge, klist 28 [1, 4, 8, 9]
nedge, check_k 29 2
nedge, check_k 30 4
nedge, check_k 31 9
nedge, check_k 32 2
nedge, klist 32 [1, 2, 4, 9]
nedge, check_k 33 4
nedge, check_k 34 8
nedge, check_k 35 3
nedge, klist 35 [2, 4, 8]
nedge, check_k 36 4
nedge, check_k 37 7
nedge, check_k 38 8
nedge, check_k 39 2
nedge, klist 39 [3, 4, 7, 8]
nedge, check_k 40 3
nedge, check_k 41 4
nedge, check_k 42 2
nedge, klist 42 [2, 3, 4]
nedge, check_k 43 4
nedge, check_k 44 7
nedge, check_k 45 8
nedge, check_k 46 1
nedge, klist 46 [2, 4, 7, 8]
nedge, check_k 47 3
nedge, check_k 48 4
nedge, check_k 49 5
nedge, check_k 50 7
nedge, check_k 51 2
nedge, klist 51 [1, 3, 4, 5, 7]
nedge, check_k 52 4
nedge, check_k 53 7
nedge, check_k 54 1
nedge, klist 54 [2, 4, 7]
nedge, check_k 55 2
nedge, check_k 56 5
nedge, check_k 57 1
nedge, klist 57 [1, 2, 5]
nedge, check_k 58 2
nedge, check_k 59 5
nedge, check_k 60 9
nedge, check_k 61 2
nedge, klist 61 [1, 2, 5, 9]
nedge, check_k 62 5
nedge, check_k 63 2
nedge, klist 63 [2, 5]
nedge, check_k 64 5
nedge, check_k 65 6
nedge, check_k 66 9
nedge, check_k 67 1
nedge, klist 67 [2, 5, 6, 9]
nedge, check_k 68 5
nedge, check_k 69 1
nedge, klist 69 [1, 5]
nedge, check_k 70 3
nedge, check_k 71 5
nedge, check_k 72 9
nedge, check_k 73 5
nedge, klist 73 [1, 3, 5, 9]
nedge, check_k 74 7
nedge, check_k 75 9
nedge, check_k 76 1
nedge, klist 76 [5, 7, 9]
nedge, check_k 77 4
nedge, check_k 78 7
nedge, check_k 79 5
nedge, klist 79 [1, 4, 7]
nedge, check_k 80 5
nedge, klist 80 [5]
nedge, check_k 81 9
nedge, check_k 82 1
nedge, klist 82 [5, 9]
nedge, check_k 83 4
nedge, check_k 84 4
nedge, klist 84 [1, 4]
nedge, check_k 85 5
nedge, check_k 86 7
nedge, check_k 87 9
nedge, check_k 88 2
nedge, klist 88 [4, 5, 7, 9]
nedge, check_k 89 4
nedge, check_k 90 5
nedge, check_k 91 9
nedge, check_k 92 5
nedge, klist 92 [2, 4, 5, 9]
nedge, check_k 93 7
nedge, check_k 94 9
nedge, check_k 95 2
nedge, klist 95 [5, 7, 9]
nedge, check_k 96 5
nedge, check_k 97 9
nedge, check_k 98 4
nedge, klist 98 [2, 5, 9]
nedge, check_k 99 5
nedge, check_k 100 8
nedge, check_k 101 9
nedge, check_k 102 4
nedge, klist 102 [4, 5, 8, 9]
nedge, check_k 103 5
nedge, check_k 104 9
nedge, check_k 105 1
nedge, klist 105 [4, 5, 9]
nedge, check_k 106 3
nedge, check_k 107 9
nedge, check_k 108 1
nedge, klist 108 [1, 3, 9]
nedge, check_k 109 3
nedge, check_k 110 4
nedge, check_k 111 5
nedge, check_k 112 7
nedge, check_k 113 9
nedge, check_k 114 2
nedge, klist 114 [1, 3, 4, 5, 7, 9]
nedge, check_k 115 3
nedge, check_k 116 2
nedge, klist 116 [2, 3]
nedge, check_k 117 7
nedge, check_k 118 8
nedge, check_k 119 2
nedge, klist 119 [2, 7, 8]
nedge, check_k 120 3
nedge, check_k 121 7
nedge, check_k 122 1
nedge, klist 122 [2, 3, 7]
nedge, check_k 123 2
nedge, check_k 124 3
nedge, check_k 125 1
nedge, klist 125 [1, 2, 3]
nedge, check_k 126 2
nedge, check_k 127 4
nedge, check_k 128 5
nedge, check_k 129 1
nedge, klist 129 [1, 2, 4, 5]
nedge, check_k 130 2
nedge, check_k 131 3
nedge, check_k 132 4
nedge, check_k 133 5
nedge, check_k 134 3
nedge, klist 134 [1, 2, 3, 4, 5]
nedge, check_k 135 5
nedge, check_k 136 7
nedge, check_k 137 3
nedge, klist 137 [3, 5, 7]
nedge, check_k 138 5
nedge, check_k 139 7
nedge, klist 139 [3, 5]
nedge, check_k 140 2
nedge, klist 140 [7]
nedge, check_k 141 3
nedge, check_k 142 5
nedge, check_k 143 6
nedge, check_k 144 2
nedge, klist 144 [2, 3, 5, 6]
nedge, check_k 145 6
nedge, check_k 146 4
nedge, klist 146 [2, 6]
nedge, check_k 147 3
nedge, klist 147 [4]
nedge, check_k 148 6
nedge, check_k 149 3
nedge, klist 149 [3, 6]
nedge, check_k 150 1
nedge, klist 150 [3]
nedge, check_k 151 3
nedge, check_k 152 4
nedge, check_k 153 6
 No. of edges:  153
The last of the klists : nedge, klist 153 [1, 3, 4, 6]
 No. of left vertices :  51  No. of right vertices :  51
x :  0  klist :  [1, 3, 4, 6]
x :  1  klist :  [1, 3, 4, 6]
x :  2  klist :  [1, 3, 4, 6]
x :  3  klist :  [1, 3, 4, 6]
x :  4  klist :  [1, 3, 4, 6]
x :  5  klist :  [1, 3, 4, 6]
x :  6  klist :  [1, 3, 4, 6]
x :  7  klist :  [1, 3, 4, 6]
x :  8  klist :  [1, 3, 4, 6]
x :  9  klist :  [1, 3, 4, 6]
x :  10  klist :  [1, 3, 4, 6]
x :  11  klist :  [1, 3, 4, 6]
x :  12  klist :  [1, 3, 4, 6]
x :  13  klist :  [1, 3, 4, 6]
x :  14  klist :  [1, 3, 4, 6]
x :  15  klist :  [1, 3, 4, 6]
x :  16  klist :  [1, 3, 4, 6]
x :  17  klist :  [1, 3, 4, 6]
x :  18  klist :  [1, 3, 4, 6]
x :  19  klist :  [1, 3, 4, 6]
x :  20  klist :  [1, 3, 4, 6]
x :  21  klist :  [1, 3, 4, 6]
x :  22  klist :  [1, 3, 4, 6]
x :  23  klist :  [1, 3, 4, 6]
x :  24  klist :  [1, 3, 4, 6]
x :  25  klist :  [1, 3, 4, 6]
x :  26  klist :  [1, 3, 4, 6]
x :  27  klist :  [1, 3, 4, 6]
x :  28  klist :  [1, 3, 4, 6]
x :  29  klist :  [1, 3, 4, 6]
x :  30  klist :  [1, 3, 4, 6]
x :  31  klist :  [1, 3, 4, 6]
x :  32  klist :  [1, 3, 4, 6]
x :  33  klist :  [1, 3, 4, 6]
x :  34  klist :  [1, 3, 4, 6]
x :  35  klist :  [1, 3, 4, 6]
x :  36  klist :  [1, 3, 4, 6]
x :  37  klist :  [1, 3, 4, 6]
x :  38  klist :  [1, 3, 4, 6]
x :  39  klist :  [1, 3, 4, 6]
x :  40  klist :  [1, 3, 4, 6]
x :  41  klist :  [1, 3, 4, 6]
x :  42  klist :  [1, 3, 4, 6]
x :  43  klist :  [1, 3, 4, 6]
x :  44  klist :  [1, 3, 4, 6]
x :  45  klist :  [1, 3, 4, 6]
x :  46  klist :  [1, 3, 4, 6]
x :  47  klist :  [1, 3, 4, 6]
x :  48  klist :  [1, 3, 4, 6]
x :  49  klist :  [1, 3, 4, 6]
x :  50  klist :  [1, 3, 4, 6]

Compilation finished at Sun Jan  7 07:54:52

From report at bugs.python.org  Sat Jan  6 21:52:02 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Jan 2018 02:52:02 +0000
Subject: [issue32508] Problem while reading back from a list of lists
In-Reply-To: <CAPsjwoCgBoN=o=ZPyzM_1prYvRW2+5vivak3ZOUEU4nBiz+COw@mail.gmail.com>
Message-ID: <1515293522.05.0.467229070634.issue32508@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

It isn't clear to me what bug you are reporting here:

- What do you mean by "problem reading back from a list of lists"? What sort of problem? 

- What makes you think that there is a bug in the interpreter, rather than in your own code?

We aren't going to debug your code for you: if you have found a bug, please report the simplest code that shows the bug. You may find it helpful to read this first:

http://sscce.org/

Although it is written for Java, the same applies to Python code too.

I'm closing this ticket for now.

If you simplify your code to something that demonstrates a bug in the Python interpreter, rather than a bug in your own code, please re-open this ticket with a better description of what the problem is, and the shortest, simplest demonstration of that problem that you can come up with.

Thank you.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32508>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:05:17 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Jan 2018 04:05:17 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
Message-ID: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

I'm trying to write a doctest that prints the hash and filename of a directory. The input is the test dir, but due to the unordered nature of file systems, the doctest checks for one known file:

def hash_files(root):
	"""
	>>> res = hash_files(Path(__file__).dirname())
	Discovering documents
	Hashing documents
	...
	>>> print(res)
	...
	d41d8cd98f00b204e9800998ecf8427e __init__.py
	...
	"""

However, this test fails with:

????????????????????????? [doctest] jaraco.financial.records.hash_files ??????????????????????????
047 
048 	>>> res = hash_files(Path(__file__).dirname())
049 	Discovering documents
050 	Hashing documents
051 	...
052 	>>> print(res)
Expected:
    d41d8cd98f00b204e9800998ecf8427e __init__.py
    ...
Got:
    e1f9390d13c90c7ed601afffd1b9a9f9 records.py
    6a116973e8f29c923a08c2be69b11859 ledger.py
    d41d8cd98f00b204e9800998ecf8427e __init__.py
    b83c8a54d6b71e28ccb556a828e3fa5e qif.py
    ac2d598f65b6debe9888aafe51e9570f ofx.py
    9f2572f761342d38239a1394f4337165 msmoney.py
    <BLANKLINE>



The first ellipsis is interpreted as a degenerate continuation of the input line, and it seems it's not possible to have an ellipsis at the beginning of the expected input.

Is there any workaround for this issue?

----------
messages: 309599
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: doctest syntax ambiguity between continuation line and ellipsis
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:10:21 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Jan 2018 04:10:21 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515298221.56.0.467229070634.issue32509@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I did find [this ugly workaround](https://github.com/jaraco/jaraco.financial/commit/9b866ab7117d1cfc26d7cdcec10c63a608662b46):

	>>> print('x' + res)
	x...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:11:16 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jan 2018 04:11:16 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515298276.04.0.467229070634.issue32509@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What happens if you print a placeholder line first, before your test output?  I'm not sure it will work, I seem to remember something about an ellipses starting a line just not being supported, but it was a long time ago...

So, that doesn't work, maybe do something like res = ['x' + l for l in res] so that you can use x...?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:12:11 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jan 2018 04:12:11 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515298331.07.0.467229070634.issue32509@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I see my answer crossed with your post :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:35:34 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Jan 2018 04:35:34 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515299734.96.0.467229070634.issue32509@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Here's a simple demonstration of the issue:


# --- cut %< ---
import doctest

def hash_files():
    """
    >>> hash_files()  # doctest: +ELLIPSIS
    ...
    d41d8cd98f00b204e9800998ecf8427e __init__.py
    ...

    """
    print("""\
e1f9390d13c90c7ed601afffd1b9a9f9 records.py
6a116973e8f29c923a08c2be69b11859 ledger.py
d41d8cd98f00b204e9800998ecf8427e __init__.py
b83c8a54d6b71e28ccb556a828e3fa5e qif.py
ac2d598f65b6debe9888aafe51e9570f ofx.py
9f2572f761342d38239a1394f4337165 msmoney.py
""")

doctest.run_docstring_examples(hash_files, globals())

# --- cut %< ---


The documentation does say that output must follow the final >>> or ... 

https://docs.python.org/3/library/doctest.html#how-are-docstring-examples-recognized

so I believe this is expected behaviour and not a bug.

Here is a workaround. Change the doctest to something like this:


    >>> print('#', end=''); hash_files()  # doctest: +ELLIPSIS
    #...
    d41d8cd98f00b204e9800998ecf8427e __init__.py
    ...



But a more elegant solution would be to add a new directive to tell doctest to interpret the ... or >>> as output, not input, or to add a new symbol similar to <BLANKLINE>.

I'm changing this to an enhancement request as I think this would be useful.

----------
components: +Library (Lib)
nosy: +steven.daprano, tim.peters -r.david.murray
type: behavior -> enhancement
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:37:04 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Jan 2018 04:37:04 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515299824.6.0.467229070634.issue32509@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oops, somehow managed to accidentally unsubscribe r.david.murray

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:41:16 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 07 Jan 2018 04:41:16 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515300076.48.0.467229070634.issue32509@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Right, "..." immediately after a ">>>" line is taken to indicate a code continuation line, and there's no way to stop that short of rewriting the parser.

The workaround you already found could be made more palatable if you weren't determined to make it impenetrable ;-)  For example,

"""
>>> print("not an ellipsis\\n" + res) #doctest:+ELLIPSIS
not an ellipsis
...
d41d8cd98f00b204e9800998ecf8427e __init__.py
...
"""

Or if this is a one-off, some suitable variant of this is simple:

"""
>>> "d41d8cd98f00b204e9800998ecf8427e __init__.py" in res
True
"""

I'd prefer that, since it directly says you don't care about anything other than that `res` contains a specific substring (in the original way, that has to be _inferred_ from the pattern of ellipses).

----------
nosy:  -steven.daprano
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sat Jan  6 23:57:44 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 07 Jan 2018 04:57:44 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515301064.41.0.467229070634.issue32509@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

And I somehow managed to unsubscribe Steven :-(

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sun Jan  7 00:23:34 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 07 Jan 2018 05:23:34 +0000
Subject: [issue32500] PySequence_Length() raises TypeError on dict type
In-Reply-To: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>
Message-ID: <1515302614.19.0.467229070634.issue32500@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Ah, I like dropping "For objects that do not provide sequence protocol". Go for it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sun Jan  7 00:38:37 2018
From: report at bugs.python.org (Matthew Cowles)
Date: Sun, 07 Jan 2018 05:38:37 +0000
Subject: [issue32501] Documentation for dir([object])
In-Reply-To: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>
Message-ID: <1515303517.01.0.467229070634.issue32501@psf.upfronthosting.co.za>


Matthew Cowles <mdcowles at users.sourceforge.net> added the comment:

My thanks to David for the clarification. I don't find the logic he describes (but does not necessarily subscribe to!) persuasive in this case. In my opinion, "Let's be incorrect for the sake of simplicity," is not the way to document a programming language in the language's official library documentation.

I think that saying, "If the object (technically the class) has a method named..." would add very little burden to people who don't care about the difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Sun Jan  7 01:55:28 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 06:55:28 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515308128.02.0.467229070634.issue32507@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

The PR is ready, but I'll leave this open for a few days in case anyone wants to comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sun Jan  7 02:35:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Jan 2018 07:35:09 +0000
Subject: [issue32503] Avoid creating small frames in pickle protocol 4
In-Reply-To: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>
Message-ID: <1515310509.45.0.467229070634.issue32503@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4988
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Sun Jan  7 02:42:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Jan 2018 07:42:29 +0000
Subject: [issue32503] Avoid creating small frames in pickle protocol 4
In-Reply-To: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>
Message-ID: <1515310949.05.0.467229070634.issue32503@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 5127 makes frames be created only when the size of the payload is not less than 4. Since the minimal size of 3 chunks is 3 bytes this is the absolute minimum of frame size.

It would be better to count the number of chunks instead of bytes, but this will complicate implementations, especially Python implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Sun Jan  7 02:47:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Jan 2018 07:47:40 +0000
Subject: [issue32506] dataclasses: no need for OrderedDict now that dict
 guarantees to keep insertion order
In-Reply-To: <1515277410.84.0.467229070634.issue32506@psf.upfronthosting.co.za>
Message-ID: <1515311260.45.0.467229070634.issue32506@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib)
dependencies: +Dict order is now guaranteed, so add tests and doc for it

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32506>
_______________________________________

From report at bugs.python.org  Sun Jan  7 03:36:17 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Jan 2018 08:36:17 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515314177.06.0.467229070634.issue32509@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Tim Peters said:
> Right, "..." immediately after a ">>>" line is taken to indicate a code continuation line, and there's no way to stop that short of rewriting the parser.


I haven't gone through the source in detail, but it seems to me that we could change OutputChecker.check_output to support this without touching the parser.

Ignoring issues of backwards compatibility for the moment, suppose we accept either '...' or '<ELLIPSIS>' as the wild card in the output section. Jason's example would then become:

	>>> print(res)  # docstring: +ELLIPSIS
	<ELLIPSIS>
	d41d8cd98f00b204e9800998ecf8427e __init__.py
	...

check_output could replace the substring '<ELLIPSIS>' with three dots before doing anything else, and Bob's yer uncle.

Or in this case, Uncle Timmy's yer uncle :-)

There's probably a million details I haven't thought of, but it seems like a promising approach to me. I did a quick hack of doctest, adding

    want = want.replace('<ELLIPSIS>', '...')

to the start of OutputChecker.check_output and it seems to work.

If this is acceptable, we'll probably need a directive to activate it, for the sake of backwards compatibility.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sun Jan  7 05:41:18 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Jan 2018 10:41:18 +0000
Subject: [issue32503] Avoid creating small frames in pickle protocol 4
In-Reply-To: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>
Message-ID: <1515321678.81.0.467229070634.issue32503@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think the overall gain is meaningful.  I'd rather not add too many special cases in the framing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Sun Jan  7 06:27:19 2018
From: report at bugs.python.org (Julien Palard)
Date: Sun, 07 Jan 2018 11:27:19 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1515324439.93.0.467229070634.issue32430@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

I also think PR 5062 complicate the thing I'm trying to simplify, it's the wrong direction.

I also don't understand why having a single versioned `Setup` file is not enough, can someone give a clear explanation on this point?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sun Jan  7 07:34:39 2018
From: report at bugs.python.org (Paul Moore)
Date: Sun, 07 Jan 2018 12:34:39 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515328479.63.0.467229070634.issue32507@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Does this mean that we'll need to update the bundled ucrt whenever there are security patches to the baseline version? Are we happy with the security implications of that?

I thought one of the key advantages of using the system CRT (whether the old msvcrXX.dll or the new ucrt) was that we automatically received security patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sun Jan  7 08:30:20 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Jan 2018 13:30:20 +0000
Subject: [issue30579] Allow traceback objects to be
 instantiated/mutated/annotated
In-Reply-To: <1496720513.53.0.619437315354.issue30579@psf.upfronthosting.co.za>
Message-ID: <1515331820.58.0.467229070634.issue30579@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset e46a8af450210ee5c7f0459ad6beddbc626ae60f by Nick Coghlan (Nathaniel J. Smith) in branch 'master':
bpo-30579: Allow TracebackType creation and tb_next mutation from Python (GH-4793)
https://github.com/python/cpython/commit/e46a8af450210ee5c7f0459ad6beddbc626ae60f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30579>
_______________________________________

From report at bugs.python.org  Sun Jan  7 08:31:58 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Jan 2018 13:31:58 +0000
Subject: [issue30579] Allow traceback objects to be
 instantiated/mutated/annotated
In-Reply-To: <1496720513.53.0.619437315354.issue30579@psf.upfronthosting.co.za>
Message-ID: <1515331918.46.0.467229070634.issue30579@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the patch!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30579>
_______________________________________

From report at bugs.python.org  Sun Jan  7 08:50:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Jan 2018 13:50:19 +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: <1515333019.01.0.467229070634.issue9325@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

+1 for creating separate issues and linking them from this one - while the risk of breaking anything seems low, if we do cause a regression, multiple issues and PRs provide better traceability than one giant issue for everything.

(I'm also not aware of anyone else actively working on this since Sanyam's cProfile PR, so go ahead and create issues and PRs for any which you're interested in working on)

As far as `dis` specifically goes, while the function name in `dis` is "_test()" and it doesn't provide a meaningful help message, it's a genuinely useful CLI operation: it disassembles whatever file you provide, or `stdin` if you don't provide one:

    $ echo "print('Hello')" | python3 -m dis 
      1           0 LOAD_NAME                0 (print)
                  2 LOAD_CONST               0 ('Hello')
                  4 CALL_FUNCTION            1
                  6 POP_TOP
                  8 LOAD_CONST               1 (None)
                 10 RETURN_VALUE

So a `-m` option does make sense in `dis`, but it should probably be accompanied by some other changes as well (like a better name for the private function, and `--help` support).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Sun Jan  7 08:53:42 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Jan 2018 13:53:42 +0000
Subject: [issue31975] Add a default filter for DeprecationWarning in __main__
In-Reply-To: <1510109709.08.0.213398074469.issue31975@psf.upfronthosting.co.za>
Message-ID: <1515333222.59.0.467229070634.issue31975@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think https://github.com/python/cpython/pull/4458 is ready to go now, but I expect it would benefit from a review before I merge it. If anyone has the time to take a look, it would be much appreciated :)

However, I'd also like to get it in for 3.7.0a4 this week, so I'll merge it tomorrow regardless - if we decide we need to tweak it before the first beta, we can do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31975>
_______________________________________

From report at bugs.python.org  Sun Jan  7 09:15:32 2018
From: report at bugs.python.org (Thermi)
Date: Sun, 07 Jan 2018 14:15:32 +0000
Subject: [issue32510] Broken comparisons (probably caused by wrong caching of
 values)
Message-ID: <1515334532.4.0.467229070634.issue32510@psf.upfronthosting.co.za>


New submission from Thermi <noel.kuntze+bugs-python-org at thermi.consulting>:

With Python 3.6.4 on Arch Linux, on three different hosts (one Skylake CPU, one i7-3820, one Xeon E5-2680, all running Arch Linux with the same Python version), the Python 3 interpreter behaves erratically in a script of mine.

The following symptoms occur:
1) Comparisons fail, although they logically need to succeed. The comparisons work a lot of the times, but sometimes, they don't.
2) Integers magically increase without ever being written to in the code after initially assigned in the constructor.

The behaviour changes if code is rearranged, variables and lines are added that do not pertain the broken comparisons, making accidental writes to memory or reads from unitialized memory likely.

The breakage occurs in the code between line 114 and the execution of the code in the recurse() method of the class Branch.

The script is here (https://gist.github.com/Thermi/05bc671436841670ac81b3b86217dd62). It basically only does some arithmetic with translation tables.

----------
components: Interpreter Core
messages: 309619
nosy: Thermi
priority: normal
severity: normal
status: open
title: Broken comparisons (probably caused by wrong caching of values)
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32510>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:16:55 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Jan 2018 15:16:55 +0000
Subject: [issue32510] Broken comparisons (probably caused by wrong caching of
 values)
In-Reply-To: <1515334532.4.0.467229070634.issue32510@psf.upfronthosting.co.za>
Message-ID: <1515338215.69.0.467229070634.issue32510@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

That is nearly two hundred lines of quite complex code. What results are you expecting and what results are you getting?

I've just tried running it under Python 3.3 and 3.5 on a RedHat-based Linux, and after generating a large amount of output (271315 lines, including "IMPOSSIBLE CONDITION OCCURED!" 552 times) it raised KeyError.

I then tried again on an Ubuntu-based Linux, and got the same result.

Can you demonstrate the same problem with a smaller, simpler example? What reasons do you have for believing that this is caused by "wrong caching of values"? What values do you think are being cached, and where?

You say:

"Comparisons fail, although they logically need to succeed."

Which comparisons? Can you isolate those failing comparisons without all the extraneous code?

"Integers magically increase without ever being written to in the code after initially assigned in the constructor."

Which integers? What evidence do you have that they are changing?

Bottom line is, while it is conceivable that you've found an interpreter bug that exists in at least three versions of Python, going back many years, that nobody has noticed before, I think it is far more likely that the bug is in your code. I'm going to close this ticket for now, but if you have answers for my questions and good evidence of an interpreter bug (preferably with a short and simple demonstration, see http://sscce.org/) please feel free to re-open it.

Thank you.

----------
nosy: +steven.daprano
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32510>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:24:03 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Jan 2018 15:24:03 +0000
Subject: [issue32510] Broken comparisons (probably caused by wrong caching of
 values)
In-Reply-To: <1515334532.4.0.467229070634.issue32510@psf.upfronthosting.co.za>
Message-ID: <1515338643.02.0.467229070634.issue32510@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oh, by the way... are you aware that the Recursor class defines a class attribute `branches` which is shared by all instances? You create multiple recursor objects, but they all share the same `branches` attribute. That might be intentional, but if not, that might explain the unexpected behaviour you are seeing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32510>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:27:09 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Jan 2018 15:27:09 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515338829.25.0.467229070634.issue32509@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thank you Steven for creating a reproduction of the issue; I should have done that in the first place. I have the +ELLIPSIS enabled elsewhere in the test suite, which is why it didn't appear in my example.

I should clarify - what I thought was a suitable workaround turns out is not, in part because the ellipsis must match _something_ and cannot be a degenerate match, leading to [this failure](https://travis-ci.org/jaraco/jaraco.financial/jobs/325955523). So the workaround I thought I'd devised was only suitable in some environments (where some content did appear before the target content).

I conclude that trying to match only a single line from a non-deterministically-ordered list of lines isn't a function for which ellipsis is well suited. I'll be adapting the test to simply test for the presence of the expected substring. Therefore, the use-case I presented is invalid (at least while ellipsis must match at least one character).

Still, I suspect I haven't been the only person to encounter the reported ambiguity, and I appreciate the progress toward addressing it. I like Steven's approach, as it's simple and directly addresses the ambiguity. It does have the one downside that for the purposes of the documentation, it's a little less elegant, as a literal "<ELLIPSIS>" appears in the docstring.

Perhaps instead of "ELLIPSIS", the indicator should be "ANYTHING" or similar, acting more as a first-class feature rather than a stand-in for an ellipsis. That would save the human reader the distraction and trouble of translating "<ELLIPSIS>" to "..." before interpreting the value (even if that's what the doctest interpreter does under the hood).

Alternatively, consider "<...>" as the syntax. I'm liking that because it almost looks like it's intention, avoiding much of the distraction. As I think about it more, I'm pretty sure such and approach is not viable, as it's a new syntax (non-alpha in the directive) and highly likely to conflict with existing doctests in the wild.

Another way to think about this problem is that the literal "..." is only non-viable when it's the first content in the expected output. Perhaps all that's needed is a signal that the output is starting, with something like "<OUTPUT>" or "<START>" or "<EXPECT>" or "<NULL>" or "<EMPTY>", a token like "<BLANKLINE>" except it's an empty match specifically designed to make the transition. Such a token would specifically address the issue at the border of the test and the output and would _also_ address the issue if the expected output begins with a _literal_ "...". Consider this case:

# --- cut %< ---
import doctest

def print_3_dot():
    """
    >>> print_3_dot()
    ...
    """
    print('...')

doctest.run_docstring_examples(print_3_dot, globals())
# --- cut %< ---

In that case, "<ELLIPSIS>" may also work, but only because a literal substitution is being made. One _might_ be surprised when "<ELLIPSIS>" does't match anything (when +ELLIPSIS is not enabled).

Overall, I'm now thinking the "<ELLIPSIS>" solution is suitable and clear enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:41:45 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 07 Jan 2018 15:41:45 +0000
Subject: [issue28414] SSL match_hostname fails for internationalized domain
 names
In-Reply-To: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za>
Message-ID: <1515339705.02.0.467229070634.issue28414@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +4989
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28414>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:50:08 2018
From: report at bugs.python.org (Zack Weinberg)
Date: Sun, 07 Jan 2018 15:50:08 +0000
Subject: [issue32511] Thread primitives do not report the OS-level error on
 failure
Message-ID: <1515340208.41.0.467229070634.issue32511@psf.upfronthosting.co.za>


New submission from Zack Weinberg <zackw at panix.com>:

[_]thread.start_new_thread can fail if the underlying OS primitive fails (pthread_create / _beginthreadex), but the exception that is thrown when this happens is a generic RuntimeError (it's _called_ ThreadError in the source code, but it doesn't have its own subtype, so you can't even catch it specifically) and the OS-level error code is lost.  It should instead throw (an appropriate subclass of) OSError and capture the error code, like when other OS primitives fail.

Reading through the code, it looks like _all_ of the threading code has this problem - throughout [_]threadmodule.c, thread.c, and thread_pthread.h, I see error codes being dropped on the floor or at best reported with perror or dprintf, not properly captured in an OSError.

This affects all maintained versions of Python, but sadly I expect it's messy enough to fix that it's only practical to do so on trunk.

----------
components: Library (Lib)
messages: 309623
nosy: zwol
priority: normal
severity: normal
status: open
title: Thread primitives do not report the OS-level error on failure
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32511>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:54:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Jan 2018 15:54:36 +0000
Subject: [issue31802] 'import posixpath' fails if 'os.path' has not be
 imported already.
In-Reply-To: <1508233521.36.0.213398074469.issue31802@psf.upfronthosting.co.za>
Message-ID: <1515340476.77.0.467229070634.issue31802@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3460198f6ba40a839f105c381f07179aba1e8c61 by Serhiy Storchaka in branch 'master':
bpo-31802: Fix importing native path module before importing os. (#4017)
https://github.com/python/cpython/commit/3460198f6ba40a839f105c381f07179aba1e8c61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31802>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:55:41 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Jan 2018 15:55:41 +0000
Subject: [issue31802] 'import posixpath' fails if 'os.path' has not be
 imported already.
In-Reply-To: <1508233521.36.0.213398074469.issue31802@psf.upfronthosting.co.za>
Message-ID: <1515340541.95.0.467229070634.issue31802@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4990

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31802>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:59:32 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jan 2018 15:59:32 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1515340772.76.0.467229070634.issue32498@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We generally don't do type checking (see discussions of "duck typing"). We generally do just let the implementation detail bubble up.  I don't think the encoding suggestion works, since we can't know what encoding the byte string is in, or even if it is a valid one.

I wonder if unquote should be polymorphic: accept both bytes and strings and produce the same type of output as its input.  I think there are other urllib methods that are, but I haven't checked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Sun Jan  7 11:31:27 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 07 Jan 2018 16:31:27 +0000
Subject: [issue32506] dataclasses: no need for OrderedDict now that dict
 guarantees to keep insertion order
In-Reply-To: <1515277410.84.0.467229070634.issue32506@psf.upfronthosting.co.za>
Message-ID: <1515342687.26.0.467229070634.issue32506@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +4991
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32506>
_______________________________________

From report at bugs.python.org  Sun Jan  7 11:34:15 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 07 Jan 2018 16:34:15 +0000
Subject: [issue32506] dataclasses: no need for OrderedDict now that dict
 guarantees to keep insertion order
In-Reply-To: <1515277410.84.0.467229070634.issue32506@psf.upfronthosting.co.za>
Message-ID: <1515342855.58.0.467229070634.issue32506@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests: +4992

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32506>
_______________________________________

From report at bugs.python.org  Sun Jan  7 11:35:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Jan 2018 16:35:30 +0000
Subject: [issue31802] 'import posixpath' fails if 'os.path' has not be
 imported already.
In-Reply-To: <1508233521.36.0.213398074469.issue31802@psf.upfronthosting.co.za>
Message-ID: <1515342930.31.0.467229070634.issue31802@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 94a3facc0e5ce02ef34d9fa595703cd96cb95984 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31802: Fix importing native path module before importing os. (GH-4017) (#5129)
https://github.com/python/cpython/commit/94a3facc0e5ce02ef34d9fa595703cd96cb95984


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31802>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:00:27 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 17:00:27 +0000
Subject: [issue32512] Add an option to profile to run library module as a
 script
Message-ID: <1515344427.94.0.467229070634.issue32512@psf.upfronthosting.co.za>


New submission from Mario Corchero <mariocj89 at gmail.com>:

Add an option to profile to be able to do `python3 -m profile -m my.module.name` to be able to profile the module the same way cProfile allows since issue 21862

----------
components: Library (Lib)
messages: 309627
nosy: mariocj89
priority: normal
severity: normal
status: open
title: Add an option to profile to run library module as a script
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32512>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:06:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 07 Jan 2018 17:06:05 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
Message-ID: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

Modify dataclasses to make it easier to specify special methods.

For example: currently, if you want to override __repr__, you need to specify @dataclass(repr=False), and also provide your own __repr__. Also, it's current an error to not specify repr=False and to also provide your own __repr__.  @dataclass should be able to determine that if you provide __repr__, you don't want it to provide it's own __repr__.

The methods that @dataclass will provide for you are:
__init__
__repr__
__eq__
__ne__
__lt__
__le__
__gt__
__ge__
_hash__
and if using frozen=True, also:
__setattr__
__delattr__

Per the discussion that started at https://mail.python.org/pipermail/python-dev/2017-December/151487.html, the change will be to override these methods only if:
1. the method would have been generated based on @dataclass params, and
2. the method is not present in the class's __dict__.

The first item is to allow the user to continue to suppress method generation, and the second item is so that base-class methods are not considered in the decision.

I'm still thinking through how __eq__ and __ne__ should be handled (as well as the ordering comparisons, too). I'll raise an issue on python-dev and point it here.

----------
assignee: eric.smith
messages: 309628
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: make it easier to use user-supplied special methods
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:34:29 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Sun, 07 Jan 2018 17:34:29 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1515346468.99.0.467229070634.issue32471@psf.upfronthosting.co.za>


Yahya Abou Imran <yahya-abou-imran at protonmail.com> added the comment:

I have generated SVG files.

Here is the rest of the ABCs present in the module:

https://gitlab.com/yahya-abou-imran/collections-abc-uml/blob/master/plantuml/other_collections.svg

And here is the full version with all ABCs:

https://gitlab.com/yahya-abou-imran/collections-abc-uml/blob/master/plantuml/full.svg

What do you prefer?

I'm gonna submit a PR with the full version right now. I will correct it if you think it's too big.

But I don't know how to run the server of the documentation locally, so I can't test it to see...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:43:16 2018
From: report at bugs.python.org (Filippo Giunchedi)
Date: Sun, 07 Jan 2018 17:43:16 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1515346996.54.0.467229070634.issue10496@psf.upfronthosting.co.za>


Change by Filippo Giunchedi <fgiunchedi at gmail.com>:


----------
nosy: +filippo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:51:14 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 07 Jan 2018 17:51:14 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515347474.76.0.467229070634.issue32509@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Jason, an ellipsis will match an empty string.  But if your expected output is:

"""
x...
abcd
...
"""

you're asking for output that:

- starts with "x"
- followed by 0 or more of anything
- FOLLOWED BY A NEWLINE (I think you're overlooking this part)
- followed by "abcd" and a newline
- followed by 0 or more of anything
- followed by (and ending) with a newline

So, e.g., "xabcd\n" doesn't match - not because of the ellipsis, but because of the newline following the first ellipsis.  You can repair that by changing the expected output like so:

"""
x...abcd
...
"""

This still requires that "abcd" is _followed_ by a newline, but puts no constraints on what appears before it.

In your specific context, it seems you want to say that your expected line has to appear _as_ its own line in your output, so that it must appear either at the start of the output _or_ immediately following a newline.

Neither ellipses nor a simple string search is sufficient to capture that notion.  Fancier code can do it, or a regexp search, or, e.g.,

what_i_want_without_the_trailing_newline in output.splitlines()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:54:36 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 17:54:36 +0000
Subject: [issue32512] Add an option to profile to run library module as a
 script
In-Reply-To: <1515344427.94.0.467229070634.issue32512@psf.upfronthosting.co.za>
Message-ID: <1515347676.83.0.467229070634.issue32512@psf.upfronthosting.co.za>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
keywords: +patch
pull_requests: +4993
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32512>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:59:35 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Sun, 07 Jan 2018 17:59:35 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1515347975.69.0.467229070634.issue32471@psf.upfronthosting.co.za>


Change by Yahya Abou Imran <yahya-abou-imran at protonmail.com>:


----------
keywords: +patch
pull_requests: +4994
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Sun Jan  7 13:52:45 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 07 Jan 2018 18:52:45 +0000
Subject: [issue32509] doctest syntax ambiguity between continuation line and
 ellipsis
In-Reply-To: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>
Message-ID: <1515351165.89.0.467229070634.issue32509@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

By the way, going back to your original problem, "the usual" solution to that different platforms can list directories in different orders is  simply to sort the listing yourself.  That's pretty easy in Python ;-)  Then your test can verify the hashes and names of _every_ file of interest - and would be clearer on the face of it than anything you could do to try to ignore every line save one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sun Jan  7 14:06:26 2018
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Sun, 07 Jan 2018 19:06:26 +0000
Subject: [issue32512] Add an option to profile to run library module as a
 script
In-Reply-To: <1515344427.94.0.467229070634.issue32512@psf.upfronthosting.co.za>
Message-ID: <1515351986.35.0.467229070634.issue32512@psf.upfronthosting.co.za>


Change by Eric N. Vander Weele <ericvw at gmail.com>:


----------
nosy: +ericvw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32512>
_______________________________________

From report at bugs.python.org  Sun Jan  7 14:14:37 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 19:14:37 +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: <1515352477.04.0.467229070634.issue9325@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

I've created an issue + PR for profile which basically ports the change in cProfile: issue32512

I am not able to add it as a dependency on this one (rights issue probably).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Sun Jan  7 14:18:36 2018
From: report at bugs.python.org (stein-k)
Date: Sun, 07 Jan 2018 19:18:36 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1515352716.68.0.467229070634.issue32498@psf.upfronthosting.co.za>


stein-k <karlsen.stein at gmail.com> added the comment:

The unquote function does take an encoding argument, but I am more worried about unquote_to_to_bytes which just assumes utf-8. (But this might be an implementation detail of its intended usage.)

I must agree that a polymorphic implementation would be better. Do you think this tracker is the correct place for such a change, or would an enhancement proposal be more suited?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Sun Jan  7 14:30:19 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 07 Jan 2018 19:30:19 +0000
Subject: [issue32506] dataclasses: no need for OrderedDict now that dict
 guarantees to keep insertion order
In-Reply-To: <1515277410.84.0.467229070634.issue32506@psf.upfronthosting.co.za>
Message-ID: <1515353419.38.0.467229070634.issue32506@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset d13889214a4c81b78fa8683d35bdbd17ff22f4fe by Eric V. Smith in branch 'master':
bpo-32506: Change dataclasses from OrderedDict to plain dict. (gh-5131)
https://github.com/python/cpython/commit/d13889214a4c81b78fa8683d35bdbd17ff22f4fe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32506>
_______________________________________

From report at bugs.python.org  Sun Jan  7 15:53:41 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 07 Jan 2018 20:53:41 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515358421.09.0.467229070634.issue32507@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Technically yes, though I think at this stage it will be very few machines that end up with our copy, and users can patch their own system using Windows Update even if we've installed a copy. Particularly for our user base, where I suspect most pre-Win10 Python users will have installed 3.5 or 3.6 previously and so have the proper update.

There should be very few first time Python users on older operating systems, and it will approach zero over time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sun Jan  7 15:54:56 2018
From: report at bugs.python.org (Tylor)
Date: Sun, 07 Jan 2018 20:54:56 +0000
Subject: [issue32514] 0x80070002 - The system cannot find the file specified
Message-ID: <1515358496.6.0.467229070634.issue32514@psf.upfronthosting.co.za>


New submission from Tylor <TylorBeatty1 at gmail.com>:

When attempting to install Python 3.6.4, I get the error "0x80070002 - The system cannot find the file specified." I am able to install on a different Windows User, just not the current one I am using. The account has administrator privileges as well.

----------
components: Windows
files: Python 3.6.4 (32-bit)_20180107153053[3191].log
messages: 309636
nosy: Beatty0111, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 0x80070002 - The system cannot find the file specified
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47370/Python 3.6.4 (32-bit)_20180107153053[3191].log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32514>
_______________________________________

From report at bugs.python.org  Sun Jan  7 15:56:15 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 20:56:15 +0000
Subject: [issue32512] Add an option to profile to run library module as a
 script
In-Reply-To: <1515344427.94.0.467229070634.issue32512@psf.upfronthosting.co.za>
Message-ID: <1515358575.98.0.467229070634.issue32512@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Related issue for improved executable module support for standard library modules that run other scripts: https://bugs.python.org/issue9325

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32512>
_______________________________________

From report at bugs.python.org  Sun Jan  7 15:58:47 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 20:58:47 +0000
Subject: [issue32515] Add an option to trace to run module as a script
Message-ID: <1515358727.93.0.467229070634.issue32515@psf.upfronthosting.co.za>


New submission from Mario Corchero <mariocj89 at gmail.com>:

Add an option to trace to be able to do `python3 -m trace -t --module my.module.name` to be able to trace a runnable module the same way we can do with scripts.

As we want trace to not include the lines in runpy I am going to with the approach of pdb (issue32206) over the one on profiler(issue32512). As Nick raised before this hits a private API in runpy but it is within the stdlib. Alternatives are welcomed as well! :)

Additionally, '-m' is already in use, I have added --module.

Related issue for improved executable module support for standard library modules that run other scripts: https://bugs.python.org/issue9325

----------
components: Library (Lib)
messages: 309638
nosy: mariocj89
priority: normal
severity: normal
status: open
title: Add an option to trace to run module as a script
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32515>
_______________________________________

From report at bugs.python.org  Sun Jan  7 16:00:41 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 21:00:41 +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: <1515358841.06.0.467229070634.issue9325@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Just finished a draft on the one for trace: issue32515

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Sun Jan  7 16:23:39 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 21:23:39 +0000
Subject: [issue32515] Add an option to trace to run module as a script
In-Reply-To: <1515358727.93.0.467229070634.issue32515@psf.upfronthosting.co.za>
Message-ID: <1515360219.3.0.467229070634.issue32515@psf.upfronthosting.co.za>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
keywords: +patch
pull_requests: +4995
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32515>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:36:46 2018
From: report at bugs.python.org (Paul Moore)
Date: Sun, 07 Jan 2018 22:36:46 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515364606.68.0.467229070634.issue32507@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Oh, so we're talking here about bundling the ucrt installers and then if the user doesn't already have ucrt installed system wide, we will install a local copy, but if they do, we don't do anything? If we install a local copy, then it'll be used until the user installs a system copy, at which point the local copy remains but gets ignored, correct? That seems OK, although I can see a local copy that's not used being confusing - but it's for very few users so no real issue.

I'm not sure what you're saying for venv/virtualenv though? Presumably they will need to copy the local copy if it's present, but that local copy will be ignored if there's a system copy?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:37:02 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jan 2018 22:37:02 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1515364622.22.0.467229070634.issue32498@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think Nick was the last one who touched the byte/string issues in urllib, so I've nosied him.  We'll see what he thinks (but this tracker accepts enhancement proposals as long as they are smallish ones).

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:41:46 2018
From: report at bugs.python.org (xoviat)
Date: Sun, 07 Jan 2018 22:41:46 +0000
Subject: [issue32516] Add a shared library mechanism for win32
Message-ID: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>


New submission from xoviat <xoviat at gmail.com>:

On linux and macOS, a mechanism exists to relocate shared libraries inside of a wheel. Auditwheel creates a .libs folder and places the shared libraries inside of it. The problem is that on Windows, the rpath mechanism doesn't exist. We've attempted to ameliorate the situation with NumPy by modifying the DLL search path ourselves. I think this should be done in Python itself.

Here is what I propose: for each folder in site packages that matches the foldername created by auditwheel, specifically:

1. A folder directly inside site-packages that ends with '.libs'
2. A folder two levels under site-packages that is named 'libs'

Python should add these folders to the DLL search path at some point before the matching extensions are imported, so that DLLs located in these paths can be imported by a call to LoadLibrary.

The reason that this should be done in Python is that packages shouldn't be modifying the DLL search path, but that's currently what's required.

The alternative, current, recommendation is to place shared libraries in the same folder as the extension, but this approach fails when the shared library needs to be shared between more than one extension in different subpackages, but in the same distribution package.

----------
components: Extension Modules
messages: 309642
nosy: xoviat
priority: normal
severity: normal
status: open
title: Add a shared library mechanism for win32
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:42:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 22:42:09 +0000
Subject: [issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with
 an internal compiler error in create_edge
In-Reply-To: <1510005461.16.0.213398074469.issue31963@psf.upfronthosting.co.za>
Message-ID: <1515364929.37.0.467229070634.issue31963@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Different error:

http://buildbot.python.org/all/#/builders/47/builds/428

Objects/bytearrayobject.c: In function ?bytearray_startswith?:
Objects/bytearrayobject.c:2429:1: error: the control flow of function ?bytearray_startswith? does not match its profile data (counter ?time_profiler?) [-Werror=coverage-mismatch]
 }
 ^
cc1: some warnings being treated as errors

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31963>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:43:24 2018
From: report at bugs.python.org (xoviat)
Date: Sun, 07 Jan 2018 22:43:24 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515365004.04.0.467229070634.issue32516@psf.upfronthosting.co.za>


xoviat <xoviat at gmail.com> added the comment:

Sorry, that should have read:

2. A folder two levels under site-packages that is named '.libs'

Please consult the auditwheel source to determine the specific pattern if there is doubt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:45:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 22:45:33 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1515365133.09.0.467229070634.issue23749@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

http://buildbot.python.org/all/#/builders/58/builds/435

Tests fail on x86 Windows7 3.x:

======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 440, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 398, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 440, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 398, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:47:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 22:47:58 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515365278.4.0.467229070634.issue32248@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Tests fail on Windows since the commit deae6b451fefd5fd3143dd65051e1d341e5a5f84.

Example with AMD64 Windows8.1 Non-Debug 3.x:

http://buildbot.python.org/all/#/builders/12/builds/426

======================================================================
FAIL: test_open_binary (test.test_importlib.test_open.OpenDiskTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\test_importlib\test_open.py", line 24, in test_open_binary
    self.assertEqual(result, b'Hello, UTF-8 world!\n')
AssertionError: b'Hello, UTF-8 world!\r\n' != b'Hello, UTF-8 world!\n'

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:50:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 22:50:16 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515365416.72.0.467229070634.issue32248@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Failure on x86 Gentoo Installed with X 3.x:

http://buildbot.python.org/all/#/builders/103/builds/453

4 tests failed:
    test_compileall test_import test_importlib test_inspect

test test_import crashed -- Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.7/test/libregrtest/runtest.py", line 163, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 723, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.7/test/test_import/__init__.py", line 28, in <module>
    from test.test_importlib.util import uncache
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.7/test/test_importlib/util.py", line 19, in <module>
    from . import data01
ImportError: cannot import name 'data01' from 'test.test_importlib' (/buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.7/test/test_importlib/__init__.py)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:55:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 22:55:01 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1515365701.95.0.467229070634.issue23749@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

SelectorStartTLSTests failed once on x86 Tiger 3.x in build 453, but then passed, no idea why.

http://buildbot.python.org/all/#/builders/30/builds/453

======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 440, in run_until_complete
    return future.result()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/tasks.py", line 398, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
======================================================================
ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_sslproto.py", line 285, in test_start_tls_server_1
    asyncio.wait_for(main(), loop=self.loop, timeout=10))
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 440, in run_until_complete
    return future.result()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/tasks.py", line 398, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:56:59 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 22:56:59 +0000
Subject: [issue31931] test_concurrent_futures:
 ProcessPoolSpawnExecutorTest.test_shutdown_race_issue12456() leaked dangling
 process on x86 Tiger 3.x
In-Reply-To: <1509704078.7.0.213398074469.issue31931@psf.upfronthosting.co.za>
Message-ID: <1515365819.15.0.467229070634.issue31931@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Another recent failure on x86 Tiger 3.x:

http://buildbot.python.org/all/#/builders/30/builds/441

test_max_workers_negative (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.63s ok
test_no_stale_references (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.66s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 4.72s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 3.37s Warning -- reap_children() reaped child process 1808
ok
test_submit (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.65s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.67s ok
test_traceback (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 8.59s ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.13s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.11s ok
(...)
----------------------------------------------------------------------
Ran 150 tests in 262.265s
OK
Warning -- multiprocessing.process._dangling was modified by test_concurrent_futures
  Before: <_weakrefset.WeakSet object at 0x1cd1a44>
  After:  <_weakrefset.WeakSet object at 0x1ebc84c>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31931>
_______________________________________

From report at bugs.python.org  Sun Jan  7 18:03:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 23:03:38 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on x86-64
 Sierra 3.6
Message-ID: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

On buildbot x86-64 Sierra 3.6, since build 163, test_read_pty_output() of test_asyncio started to hang:

http://buildbot.python.org/all/#/builders/20/builds/163/steps/4/logs/stdio

0:22:40 load avg: 1.73 [329/406/1] test_asyncio crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00007fffb5eee340 (most recent call first):
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/selectors.py", line 577 in select
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 1396 in _run_once
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 422 in run_forever
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 455 in run_until_complete
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py", line 1536 in test_read_pty_output
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 555 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 600 in wrapper
(...)

Difference between pythoninfo of build 162 and 163:

-os.login: buildbot
+os.login: _timed

-os.uname: posix.uname_result(sysname='Darwin', nodename='mattb-mbp2.local', release='17.2.0', version='Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64', machine='x86_64')
+os.uname: posix.uname_result(sysname='Darwin', nodename='mattb-mbp2.local', release='17.3.0', version='Darwin Kernel Version 17.3.0: Thu Nov  9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64', machine='x86_64')

-platform.platform: Darwin-17.2.0-x86_64-i386-64bit
+platform.platform: Darwin-17.3.0-x86_64-i386-64bit

-sys.version: 3.6.4+ (heads/3.6:aea95c2fbd, Jan  2 2018, 00:22:06)  [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
+sys.version: 3.6.4+ (heads/3.6:a70d5ff992, Jan  4 2018, 01:35:13)  [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]

-sysconfig[HOST_GNU_TYPE]: x86_64-apple-darwin17.2.0
+sysconfig[HOST_GNU_TYPE]: x86_64-apple-darwin17.3.0

The os.login change is interesting and curious, and it also looks like a macOS upgrade from Darwin 17.2.0 to 17.3.0.

----------
components: Tests, asyncio, macOS
messages: 309650
nosy: asvetlov, ned.deily, ronaldoussoren, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_read_pty_output() of test_asyncio hangs on x86-64 Sierra 3.6
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Sun Jan  7 19:03:35 2018
From: report at bugs.python.org (Dryden Bouamalay)
Date: Mon, 08 Jan 2018 00:03:35 +0000
Subject: [issue32511] Thread primitives do not report the OS-level error on
 failure
In-Reply-To: <1515340208.41.0.467229070634.issue32511@psf.upfronthosting.co.za>
Message-ID: <1515369815.2.0.467229070634.issue32511@psf.upfronthosting.co.za>


Change by Dryden Bouamalay <aomamemaki at gmail.com>:


----------
nosy: +drydenb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32511>
_______________________________________

From report at bugs.python.org  Sun Jan  7 19:21:39 2018
From: report at bugs.python.org (J Viswanathan)
Date: Mon, 08 Jan 2018 00:21:39 +0000
Subject: [issue32508] Problem while reading back from a list of lists
In-Reply-To: <1515293522.05.0.467229070634.issue32508@psf.upfronthosting.co.za>
Message-ID: <CAPsjwoDLU1HjBycALpwXb2L89JBACsPeJAABUM=w7cfkQ8uE+Q@mail.gmail.com>


J Viswanathan <Viswanathan10 at gmail.com> added the comment:

Thanks for your sensible advice to produce
    a short, self-contained and correct example.

        Attached is the input file (35 lines, 770 bytes) and log (14 lines)

    Description of the problem and bug:

    The data consists of 6 triplets.

        The code is to group the data according to the pair in each
        triplet.

    In the data, there are just two pairs [1,3] and [2,2]

        With the pair [1,3] the associated third item in the first
        three triplets are 1, 2, 4.

        (This is printed correctly in the first line of the output).

         The bug is seen on the 4th (non-blank) line:

         klists[0] should be [1,2,4] and not as shown.

         I sincerely hope that I am not wasting your time with a
         non-existent bug.

     J. Viswanathan.

On Sun, Jan 7, 2018 at 8:22 AM, Steven D'Aprano <report at bugs.python.org>
wrote:

>
> Steven D'Aprano <steve+python at pearwood.info> added the comment:
>
> It isn't clear to me what bug you are reporting here:
>
> - What do you mean by "problem reading back from a list of lists"? What
> sort of problem?
>
> - What makes you think that there is a bug in the interpreter, rather than
> in your own code?
>
> We aren't going to debug your code for you: if you have found a bug,
> please report the simplest code that shows the bug. You may find it helpful
> to read this first:
>
> http://sscce.org/
>
> Although it is written for Java, the same applies to Python code too.
>
> I'm closing this ticket for now.
>
> If you simplify your code to something that demonstrates a bug in the
> Python interpreter, rather than a bug in your own code, please re-open this
> ticket with a better description of what the problem is, and the shortest,
> simplest demonstration of that problem that you can come up with.
>
> Thank you.
>
> ----------
> nosy: +steven.daprano
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32508>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file47371/hksu_copy.py
Added file: https://bugs.python.org/file47372/hksu.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32508>
_______________________________________
-------------- next part --------------


vdata =  [1, 3, 1,
          1, 3, 2,
          1, 3, 4,
          2, 2, 2,
          2, 2, 4,
          2, 2, 7]

uids = []
klists = []
check_uid =[0,0]
klist = []

for x in range(6):
    xslice = vdata[3*x:3*(x+1)]
    lid = xslice[0:2]
    k = xslice[2]

    if (lid == check_uid): #an existing uid
        klist.append(k)
    else:
        check_uid = lid   # a new uid
        uids.append(check_uid) 
        if len(klist):
            klists.append(klist)
            print ('\nx : ', x, 'klist:' , klist)
            klist.clear()
        klist.append(k)

klists.append(klist)   # The last of the klists

print ('\nlen(klists) :', len(klists))

print ('\ni      uids(i)      klists[i] \n')
for i in range(2):
    print ( i, '    ', uids[i], '    ', klists[i])

-------------- next part --------------
-*- mode: compilation; default-directory: "c:/Users/J V/Documents/gamsdir/" -*-
Compilation started at Mon Jan  8 05:32:11

python hksu_copy.py

x :  3 klist: [1, 2, 4]

len(klists) : 2

i      uids(i)      klists[i] 

0      [1, 3]      [2, 4, 7]
1      [2, 2]      [2, 4, 7]

Compilation finished at Mon Jan  8 05:32:12

From report at bugs.python.org  Sun Jan  7 19:25:28 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Jan 2018 00:25:28 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1515371128.4.0.467229070634.issue20104@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution: rejected -> 
stage: needs patch -> patch review
status: closed -> open
type: performance -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Sun Jan  7 19:42:05 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 08 Jan 2018 00:42:05 +0000
Subject: [issue32514] 0x80070002 - The system cannot find the file specified
In-Reply-To: <1515358496.6.0.467229070634.issue32514@psf.upfronthosting.co.za>
Message-ID: <1515372125.87.0.467229070634.issue32514@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

In your TEMP directory there will be at least one other log file near the one you attached. Could you also include those?

I wonder if the space at the start of your user name is a problem...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32514>
_______________________________________

From report at bugs.python.org  Sun Jan  7 19:53:03 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 08 Jan 2018 00:53:03 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515372783.26.0.467229070634.issue32507@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

All correct. I believe venv is fine, as it copies all DLLs, but virtualenv is more selective and will need to be updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sun Jan  7 19:57:35 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 08 Jan 2018 00:57:35 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1515373055.72.0.467229070634.issue32513@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sun Jan  7 20:00:22 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Jan 2018 01:00:22 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1515373222.96.0.467229070634.issue32430@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

FWIW there was documentation in the README about the Setup files, removed in Subversion r57681 (= Git revision 1c896e3). It looks like it still survives in the 2.7 version.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sun Jan  7 21:13:24 2018
From: report at bugs.python.org (Tylor)
Date: Mon, 08 Jan 2018 02:13:24 +0000
Subject: [issue32514] 0x80070002 - The system cannot find the file specified
In-Reply-To: <1515358496.6.0.467229070634.issue32514@psf.upfronthosting.co.za>
Message-ID: <1515377604.1.0.467229070634.issue32514@psf.upfronthosting.co.za>


Tylor <TylorBeatty1 at gmail.com> added the comment:

Here's the second log file.

Yeah, it's actually 2 spaces. It happened when I initially setup my computer and it would not let me setup my User Account with a Microsoft Account. Therefore, I settled for a local account which I miss-named with 2 extra spaces somehow. I later attached my Microsoft Account, so while my display name does not have spaces, the directory does. I'm not sure how to change this, and I assume it would cause big issues for many programs if I were to suddenly change it.

----------
Added file: https://bugs.python.org/file47373/Python 3.6.4 (32-bit)_20180107153053_000_core_JustForMe[3206].log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32514>
_______________________________________

From report at bugs.python.org  Sun Jan  7 21:18:30 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 08 Jan 2018 02:18:30 +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: <1515377910.58.0.467229070634.issue9325@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks. I've added the dependencies, and also granted you triage permissions on the tracker, so you should be able to edit dependencies yourself in the future.

----------
dependencies: +Add an option to profile to run library module as a script, Add an option to trace to run module as a script

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Sun Jan  7 21:39:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 08 Jan 2018 02:39:19 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1515379159.62.0.467229070634.issue32498@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As David noted, we updated all the URL parsing functions to be polymorphic back in 3.2: https://docs.python.org/3/library/urllib.parse.html#parsing-ascii-encoded-bytes

We left the quoting functions alone, because they already had their own way of dealing with the bytes-vs-str distinction (quote_from_bytes, unquote_to_bytes, etc) that meant the polymorphic approach we adopted for the parsing functions didn't make sense.

That said, I think it would be reasonable to enhance unquote() to accept a bytes object, processing it as follows:

    unquote_to_bytes(string).decode(encoding, errors)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Sun Jan  7 21:45:04 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 08 Jan 2018 02:45:04 +0000
Subject: [issue31975] Add a default filter for DeprecationWarning in __main__
In-Reply-To: <1510109709.08.0.213398074469.issue31975@psf.upfronthosting.co.za>
Message-ID: <1515379504.89.0.467229070634.issue31975@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 9b99747386b690007027c3be2a5d7cfe3d3634f5 by Nick Coghlan in branch 'master':
bpo-31975 (PEP 565): Show DeprecationWarning in __main__ (GH-4458)
https://github.com/python/cpython/commit/9b99747386b690007027c3be2a5d7cfe3d3634f5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31975>
_______________________________________

From report at bugs.python.org  Sun Jan  7 21:45:38 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 08 Jan 2018 02:45:38 +0000
Subject: [issue31975] Add a default filter for DeprecationWarning in __main__
In-Reply-To: <1510109709.08.0.213398074469.issue31975@psf.upfronthosting.co.za>
Message-ID: <1515379538.18.0.467229070634.issue31975@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31975>
_______________________________________

From report at bugs.python.org  Sun Jan  7 22:48:55 2018
From: report at bugs.python.org (Nitish)
Date: Mon, 08 Jan 2018 03:48:55 +0000
Subject: [issue32511] Thread primitives do not report the OS-level error on
 failure
In-Reply-To: <1515340208.41.0.467229070634.issue32511@psf.upfronthosting.co.za>
Message-ID: <1515383335.25.0.467229070634.issue32511@psf.upfronthosting.co.za>


Change by Nitish <nitishch at protonmail.com>:


----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32511>
_______________________________________

From report at bugs.python.org  Mon Jan  8 03:09:03 2018
From: report at bugs.python.org (=?utf-8?b?5p2o6bmP?=)
Date: Mon, 08 Jan 2018 08:09:03 +0000
Subject: [issue32518] HTTPServer can't deal with persistent connection properly
Message-ID: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>


New submission from ?? <yangpengxdu at gmail.com>:

when client is using persistent connection, HTTPServer will hang with that connection. As a result, it can't deal with other clients.

----------
components: Library (Lib)
messages: 309659
nosy: ??
priority: normal
pull_requests: 4996
severity: normal
status: open
title: HTTPServer can't deal with persistent connection properly
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Mon Jan  8 05:49:35 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Jan 2018 10:49:35 +0000
Subject: [issue32518] HTTPServer can't deal with persistent connection properly
In-Reply-To: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>
Message-ID: <1515408575.72.0.467229070634.issue32518@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Perhaps this can be treated as a duplicate of Issue 31639.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Mon Jan  8 06:35:34 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 08 Jan 2018 11:35:34 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515155908.85.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <ab064a78-956d-4bf5-ea6d-3dadfeccab84@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 05/01/2018 13:38, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Michael, does AIX have uint32_t?  If so, we could happily drop the unsigned32 reference.

Yes, AIX has unit32_t.

michael at x071:[/home/michael]grep unsigned32 /usr/include/*.h 
/usr/include/sys/*.h | grep typed
/usr/include/uuid.h:typedef u_int32_t unsigned32;????? /* positive 32 
bit integer */
/usr/include/uuid.h:typedef unsigned32 boolean32;

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32493>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Mon Jan  8 06:37:22 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Jan 2018 11:37:22 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1515411442.35.0.467229070634.issue32493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Seems to be in inttypes.h:
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/inttypes.h.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Mon Jan  8 06:47:34 2018
From: report at bugs.python.org (David Carlier)
Date: Mon, 08 Jan 2018 11:47:34 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1515412054.74.0.467229070634.issue32493@psf.upfronthosting.co.za>


David Carlier <dcarlier at afilias.info> added the comment:

Perfect. That solves in the process OpenBSD uuid module build too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Mon Jan  8 07:52:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Jan 2018 12:52:28 +0000
Subject: [issue26959] pickle: respect dispatch for functions again
In-Reply-To: <1462407226.68.0.381104260984.issue26959@psf.upfronthosting.co.za>
Message-ID: <1515415948.35.0.467229070634.issue26959@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26959>
_______________________________________

From report at bugs.python.org  Mon Jan  8 07:59:32 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jan 2018 12:59:32 +0000
Subject: [issue32518] HTTPServer can't deal with persistent connection properly
In-Reply-To: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>
Message-ID: <1515416372.25.0.467229070634.issue32518@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, I would say it is.

Note that this isn't going to get "fixed" in 2.7, because 2.7 doesn't get new features, and the proposed change to the CLI is a new feature.  As noted in that issue discussion we aren't going to change the inheritance hierarchy of the classes.  It is up to the library user to make that choice and implement it.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> HTTPServer can't deal with persistent connection properly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Mon Jan  8 09:40:40 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Jan 2018 14:40:40 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on x86-64
 Sierra 3.6
In-Reply-To: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>
Message-ID: <1515422440.7.0.467229070634.issue32517@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The darwin version change is likely due to an upgrade from macOS 10.13.1 to 10.13.2.

The user change can be due to the introduction of a new system user, but I don't know when user _timed was introduced and don't have 10.3 VMs other than one running 10.13.2.  User _timed does not exist on 10.12.6, and is hence a fairly recent addition.

The buildbot operator could verify this by checking the UID for user buildbot, this likely conflicts with user _timed. The fix for that would be the give user buildbot a new UID and chown all files in the buildbot tree to the new UID.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Mon Jan  8 09:55:56 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 08 Jan 2018 14:55:56 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515412054.74.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <eb1b8815-c7cf-bd7d-2e8f-578f35b7dc9b@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 08/01/2018 12:47, David Carlier wrote:
> David Carlier <dcarlier at afilias.info> added the comment:
>
> Perfect. That solves in the process OpenBSD uuid module build too.
>
> ----------
p.s. I did not 'invent' unsigned32 - just took the syntax from the man 
page: 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.basetrf2/uuid_create.htm 
- and I just did the grep above to show the type existed AND was 
directly related to unsigned32 - even in AIX include files.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32493>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Mon Jan  8 09:58:36 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Jan 2018 14:58:36 +0000
Subject: [issue32519] venv API docs - symlinks default incorrect
Message-ID: <1515423516.58.0.467229070634.issue32519@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In the API docs for EnvBuilder.symlinks, it states "Defaults to True on Linux and Unix systems, but False on Windows." But in fact, the implementation takes the value passed, which always defaults to False. It's only on the command-line that the default is inferred from the system. Presumably, the fix is to strike that sentence from the docs.

----------
components: Library (Lib)
messages: 309667
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: venv API docs - symlinks default incorrect

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32519>
_______________________________________

From report at bugs.python.org  Mon Jan  8 10:07:28 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 08 Jan 2018 15:07:28 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1515424048.52.0.467229070634.issue28009@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

Considering that _uuid is now working for AIX issue32399 - I need to get some things straight (aka some help please).

Does uuid.py (./Lib/uuid.py) call _uuid.py?

If not, I am curious how _uuid.c is used - because ./Lib/test/test_uuid.py does not seem to be successful in finding it:

> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(10)<module>()
-> py_uuid = support.import_fresh_module('uuid', blocked=['_uuid'])
(Pdb) n
> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(11)<module>()
-> c_uuid = support.import_fresh_module('uuid', fresh=['_uuid'])
(Pdb) n
> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(14)<module>()
-> def importable(name):
(Pdb) py_uuid
<module 'uuid' from '/data/prj/python/git/python3-3.7/Lib/uuid.py'>
(Pdb) c_uuid
(Pdb)

So, for now it seems the test is only testing 'uuid.py'. I would like to see the added value of having gotten the _uuid Module to build.

However, if this is 'working as designed' I not worry about it and just go back into the util.py - getnode() etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Mon Jan  8 10:28:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jan 2018 15:28:00 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on macOS
 10.13.2 (darwin 17.3.0)
In-Reply-To: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>
Message-ID: <1515425280.88.0.467229070634.issue32517@psf.upfronthosting.co.za>


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


----------
title: test_read_pty_output() of test_asyncio hangs on x86-64 Sierra 3.6 -> test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Mon Jan  8 10:55:31 2018
From: report at bugs.python.org (jeff deifik)
Date: Mon, 08 Jan 2018 15:55:31 +0000
Subject: [issue32520] error writing to file in binary mode - python 3.6.3
Message-ID: <1515426931.81.0.467229070634.issue32520@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I am running python 3.6.3 on cygwin / windows.

Here is a test program to demonstrate the bug:

#!/usr/bin/env python3

fp = open("bug_out.txt", "ab")
buff = 'Hello world'
print('type of buff is', type(buff))
bin_buff = bytes(buff,  'utf-8')
print('type of bin_buff is', type(bin_buff))
print(bin_buff, file=fp)

Here is the output:
./bug.py
type of buff is <class 'str'>
type of bin_buff is <class 'bytes'>
Traceback (most recent call last):
  File "./bug.py", line 8, in <module>
    print(bin_buff, file=fp)
TypeError: a bytes-like object is required, not 'str'

The python type system things bin_buff has type bytes, but when I try to print it, the print function thinks it is of type str.

----------
components: IO
messages: 309669
nosy: lopgok
priority: normal
severity: normal
status: open
title: error writing to file in binary mode - python 3.6.3
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32520>
_______________________________________

From report at bugs.python.org  Mon Jan  8 10:56:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Jan 2018 15:56:16 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515426976.5.0.467229070634.issue31993@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'll create a separate PR for the memoroview issue after merging PR 5114.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Mon Jan  8 10:56:20 2018
From: report at bugs.python.org (wwq)
Date: Mon, 08 Jan 2018 15:56:20 +0000
Subject: [issue32174] nonASCII punctuation characters can not display in
 python363.chm.
In-Reply-To: <1512013530.29.0.213398074469.issue32174@psf.upfronthosting.co.za>
Message-ID: <1515426980.71.0.467229070634.issue32174@psf.upfronthosting.co.za>


wwq <wwqgtxx at 126.com> added the comment:

I found the problem was not fixed on python364.chm but it show well on python362.chm, maybe the python.org official config was a change to let the coding error.

----------
nosy: +wwqgtxx

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32174>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:07:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Jan 2018 16:07:38 +0000
Subject: [issue32520] error writing to file in binary mode - python 3.6.3
In-Reply-To: <1515426931.81.0.467229070634.issue32520@psf.upfronthosting.co.za>
Message-ID: <1515427658.88.0.467229070634.issue32520@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

print() converts all its arguments to string by calling str(). The resulting strings are written to the output file.

print(bin_buff, file=fp) is equivalent to

    fp.write(str(bin_buff))
    fp.write('\n')

If you will run Python with options -b or -bb you will get a warning or an error from str(bin_buff) because this operation can be ambiguous. It is better to use an explicit repr() for converting bytes to str if you want to get the representation of the bytes object as a Python literal, or convert it to a string with specifying explicit encoding: str(bin_buff, 'utf-8') or bin_buf.decode('utf-8').

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32520>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:22:22 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 08 Jan 2018 16:22:22 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1515424048.52.0.467229070634.issue28009@psf.upfronthosting.co.za>
Message-ID: <03a937d6-59a5-4516-89fc-9520d8543a5f@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 08/01/2018 16:07, Michael Felt wrote:
> Michael Felt <michael at felt.demon.nl> added the comment:
>
> Considering that _uuid is now working for AIX issue32399 - I need to get some things straight (aka some help please).
>
> Does uuid.py (./Lib/uuid.py) call _uuid.py?
>
> If not, I am curious how _uuid.c is used - because ./Lib/test/test_uuid.py does not seem to be successful in finding it:
>
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(10)<module>()
> -> py_uuid = support.import_fresh_module('uuid', blocked=['_uuid'])
> (Pdb) n
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(11)<module>()
> -> c_uuid = support.import_fresh_module('uuid', fresh=['_uuid'])
> (Pdb) n
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(14)<module>()
> -> def importable(name):
> (Pdb) py_uuid
> <module 'uuid' from '/data/prj/python/git/python3-3.7/Lib/uuid.py'>
> (Pdb) c_uuid
> (Pdb)
>
> So, for now it seems the test is only testing 'uuid.py'. I would like to see the added value of having gotten the _uuid Module to build.
>
> However, if this is 'working as designed' I not worry about it and just go back into the util.py - getnode() etc.

Got this figured out. tested on too many machines - the last version 
built was on AIX5 - which does not have uuid() functions in libc.a.

Running on AIX6 - I get:

(Pdb) py_uuid
<module 'uuid' from '/data/prj/python/git/gcc-python3-3.7/Lib/uuid.py'>
(Pdb) c_uuid
<module 'uuid' from '/data/prj/python/git/gcc-python3-3.7/Lib/uuid.py'>
(Pdb) import _uuid
(Pdb) _uuid
<module '_uuid' from 
'/data/prj/python/git/gcc-python3-3.7/build/lib.aix-6.1-3.7/_uuid.so'>
(Pdb)

However, have a new question - why are py_uuid and c_uuid 'equivalent'. 
(_uuid is shown just to show that it can be imported).

A comment - perhaps a new bpo/issue topic. When trying to run the tests 
from a freshly built version - it still seems to default to looking at 
the installed version first. And that can make debugging very very hard 
(which modules are actually getting loaded?!). In this case, there also 
seem to be a python2 and python3 incompatibility - notice the python2.7 
pdb reference!

michael at x071:[/data/prj/python/git/python3-master]python -m pdb 
./Lib/test/test_uuid.py
Traceback (most recent call last):
 ? File "/opt/lib/python2.7/pdb.py", line 1314, in main
 ??? pdb._runscript(mainpyfile)
 ? File "/opt/lib/python2.7/pdb.py", line 1233, in _runscript
 ??? self.run(statement)
 ? File "/opt/lib/python2.7/bdb.py", line 400, in run
 ??? exec cmd in globals, locals
 ? File "<string>", line 1, in <module>
 ? File "./Lib/test/test_uuid.py", line 520
 ??? print(hex, end=' ')

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue28009>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:35:04 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 08 Jan 2018 16:35:04 +0000
Subject: [issue32521] NIS module fails to build due to the remove of
 interfaces related to Sun RPC from glibc.
Message-ID: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Currently on the development branch of Fedora (28), an upstream change of glibc is being pushed where the Sun RPC support is removed from our downstream glibc package in favor of the libtirpc library. More details [0].

As a result, when python is trying to build the nis extension, it will complain with:
fatal error: rpc/rpc.h: No such file or directory
#include <rpc/rpc.h>
          ^~~~~~~~~~~
compilation terminated.
 
[0] https://fedoraproject.org/wiki/Changes/SunRPCRemoval

----------
components: Extension Modules
messages: 309674
nosy: cstratak
priority: normal
severity: normal
status: open
title: NIS module fails to build due to the remove of interfaces related to Sun RPC from glibc.
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:35:17 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 08 Jan 2018 16:35:17 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515429317.64.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
title: NIS module fails to build due to the remove of interfaces related to Sun RPC from glibc. -> NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:41:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jan 2018 16:41:17 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515429677.68.0.467229070634.issue32521@psf.upfronthosting.co.za>


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


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:41:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jan 2018 16:41:57 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515429717.94.0.467229070634.issue32521@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Do you know if installing libtirpc-devel does install required rpc/rpc.h / fixes the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:43:45 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 08 Jan 2018 16:43:45 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515429825.31.0.467229070634.issue32521@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Already tried. Unfortunately it doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:45:20 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 08 Jan 2018 16:45:20 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515429920.5.0.467229070634.issue32521@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

The header is located at /usr/include/tirpc/rpc/rpc.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:48:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jan 2018 16:48:16 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515430096.21.0.467229070634.issue32521@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> The header is located at /usr/include/tirpc/rpc/rpc.h

configure.ac should be modified to detect tirpc is installed. If yes, setup.py should add /usr/include/tirpc/ to includes to build the "nis" module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:52:46 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Jan 2018 16:52:46 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515430366.28.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> christian.heimes
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 12:03:38 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Jan 2018 17:03:38 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515431018.53.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +4997
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 12:13:59 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 08 Jan 2018 17:13:59 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <03a937d6-59a5-4516-89fc-9520d8543a5f@felt.demon.nl>
Message-ID: <54818ed4-ec41-22bc-7f0c-1d71fb79bbff@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 08/01/2018 17:22, Michael wrote:
> On 08/01/2018 16:07, Michael Felt wrote:
>> Michael Felt <michael at felt.demon.nl> added the comment:
>>
>> Considering that _uuid is now working for AIX issue32399 -

some time differences - this is on POWER6 (10 years old system) - I 
expect POWER8 and POWER9 to be much quicker in exact times.

michael at x071:[/data/prj/python/git/xlc-python3-3.7]./python
Python 3.7.0a3+ (heads/master:9b99747, Jan? 8 2018, 15:50:03) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
 >>>
michael at x071:[/data/prj/python/git/xlc-python3-3.7]./python -m timeit -n 
1000000 -r 5 'import uuid; getnode = uuid.getnode()'
1000000 loops, best of 5: 911 nsec per loop

michael at x071:[/data/prj/python/git/xlc-python3-3.7]python
Python 2.7.12 (default, Sep 29 2016, 12:02:17) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
 >>>
michael at x071:[/data/prj/python/git/xlc-python3-3.7]python -m timeit -n 
1000000 -r 5 'import uuid; getnode = uuid.getnode()'
1000000 loops, best of 5: 2.86 usec per loop
michael at x071:[/data/prj/python/git/xlc-python3-3.7]

The second example is a) before the _uuid support was in the code, and 
b) even if in the code would not have been built on AIX5.

The relative difference is: 911/2860 :: 31.85/100 - or roughly 3x faster 
with _uuid.

As far as this issue is concerned - with _uuid active the buggy code I 
mentioned for getnode() is defunct as it does not get called/parsed. 
However, I shall continue with it.

Question: (must have questions!) - the behavior of getnode() without 
_uuid is a 'random' value for getnode() with my current setup BUT using 
the _uuid module it is a 'constant' that is related to (one of) the 
network interface(s). What is the desired behavior, specifically, of 
uuid.getnode() - constant, or 'random'?

>>
>> Does uuid.py (./Lib/uuid.py) call _uuid.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Mon Jan  8 12:33:30 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 08 Jan 2018 17:33:30 +0000
Subject: [issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with
 an internal compiler error in create_edge
In-Reply-To: <1510005461.16.0.213398074469.issue31963@psf.upfronthosting.co.za>
Message-ID: <1515432810.87.0.467229070634.issue31963@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

That's mysterious.  I reviewed the 'stdout' log from the buildbot.  The removal of profile data is run early in the build:

find . -name '*.gc??' -exec rm -f {} ';'

Later, the bytearrayobject is compiled with profile generation enabled:

gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fprofile-generate  -I. -I./Include    -DPy_BUILD_CORE -o Objects/bytearrayobject.o Objects/bytearrayobject.c

When the unit tests run, we get errors:

profiling:/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Objects/bytearrayobject.gcda:Merge mismatch for function 35

The second build (with profile use) fails because of the missing profile information:

gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fprofile-use -fprofile-correction  -I. -I./Include    -DPy_BUILD_CORE -o Objects/bytearrayobject.o Objects/bytearrayobject.c
Objects/bytearrayobject.c: In function ?bytearray_startswith?:
Objects/bytearrayobject.c:2429:1: error: the control flow of function ?bytearray_startswith? does not match its profile data (counter ?time_profiler?) [-Werror=coverage-mismatch]
 }
 ^
cc1: some warnings being treated as errors

Seems like a compiler bug to me.  Wild theory, could it be something to do with address randomization and forking?  Looks like maybe the merge mismatch errors come when the 'python' executable forks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31963>
_______________________________________

From report at bugs.python.org  Mon Jan  8 14:45:58 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Jan 2018 19:45:58 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515440758.82.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I modified setup.py to look for libtirpc. In case the library is detected, it's added as dependency and /usr/include/tirpc is included in search path.

----------
assignee: christian.heimes -> 
stage: patch review -> 
versions:  -Python 3.5, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan  8 15:31:02 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 08 Jan 2018 20:31:02 +0000
Subject: [issue32518] HTTPServer can't deal with persistent connection properly
In-Reply-To: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>
Message-ID: <1515443462.43.0.467229070634.issue32518@psf.upfronthosting.co.za>


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


----------
superseder: HTTPServer can't deal with persistent connection properly -> http.server and SimpleHTTPServer hang after a few requests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Mon Jan  8 20:47:56 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Jan 2018 01:47:56 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515462476.45.0.467229070634.issue32248@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +4998

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Mon Jan  8 21:19:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Jan 2018 02:19:51 +0000
Subject: [issue32232] building extensions as builtins is broken in 3.7
In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za>
Message-ID: <1515464391.1.0.467229070634.issue32232@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Can someone provide a pull request and a test for this prior to beta 1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32232>
_______________________________________

From report at bugs.python.org  Mon Jan  8 21:41:54 2018
From: report at bugs.python.org (=?utf-8?b?5p2o6bmP?=)
Date: Tue, 09 Jan 2018 02:41:54 +0000
Subject: [issue32518] HTTPServer can't deal with persistent connection properly
In-Reply-To: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>
Message-ID: <1515465714.56.0.467229070634.issue32518@psf.upfronthosting.co.za>


?? <yangpengxdu at gmail.com> added the comment:

OK?i got it. thanks for your reply. But i have to say, the BaseHTTPServer document is kind of confusing. It claims to support persistent connection, but actually it hangs with such situation, i can't even shut it down with shudown() method. After diving into source code of SocketServer, i finally found the myth.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Tue Jan  9 00:54:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Jan 2018 05:54:22 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515477262.91.0.467229070634.issue32521@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think this is a duplicate of #32007.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Tue Jan  9 01:02:23 2018
From: report at bugs.python.org (Tom Karzes)
Date: Tue, 09 Jan 2018 06:02:23 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1515477743.6.0.467229070634.issue9334@psf.upfronthosting.co.za>


Tom Karzes <karzes at sonic.net> added the comment:

I'm dismayed to see that this bug was reported in 2010, yet as of January 2018 has not yet been fixed.  This option parsing behavior is contrary to Unix option passing conventions.  I certainly don't mind enhancements, but the last thing that should *ever* be introduced into an option parser is ambiguity.  It's dangerous.

I'm an old-school Unix guy.  I know exactly what options I want to pass to my program, and I know exactly how they should be passed.  Options first, with option arguments immediately following the option name, followed by positional arguments (with no more options being recognized after that point).  If the first positional argument begins with a hyphen, "--" can be used to end option parsing.  That's all I want.  Simple.  Precise.  Unambiguous.  And it doesn't place any constraints on what an option value can look like.

Yes, I know I can get around the problem by using "=" to join option values to the preceding option names, but that shouldn't be necessary.

In my opinion, the entire approach of attempting to distinguish option names from arguments out of context is fatally flawed.  It cannot be done.  Period.  Furthermore, it's utterly unnecessary.  All I want is a parameter I can pass to argparse to tell it to accept the entire command line at face value, without any second-guessing.  If I specify an option that takes an integer argument, then the very next command line argument should be an integer.  If it isn't, I want an immediate error.

More to the point, if I specify an option that takes a string argument, then the very next command line argument is that string, period.  It doesn't matter if it begins with a hyphen or any other character for that matter.  It's a string.  It can contain *any* character.  And yet, argparse doesn't support this basic, fundamental functionality without the user inserting an "=" to join the arguments.  Why??

Here's an analogy:  Your favorite car company has released a new car.  It adds lots of great features, like a sun roof and a fancy navigation system.  But oops, the brakes no longer work if you're turning right when you apply them.  But not to worry!  You can always just throw it into park to stop the car.  It's worth it for the new features, right?  Wrong.

It seems to me like there are three possible solutions to this:  (1) Add a "traditional" mode to argparse that completely bypasses any attempt to classify command line arguments as "options" vs. "arguments", (2) Un-deprecate optparse, and resume development on it, adding support for some of the argparse features but without breaking standard Unix option parsing, or (3) Create yet another new option parsing package for Python, one which supports traditional Unix option parsing and doesn't introduce gratuitous ambiguities and restrictions on what strings can contain.

My specific case:  I have an option whose argument is a comma-separated list of signed integers, as a single string.  This is the format another, non-Python application requires, and it needs to be compatible.  But the following fails:  --myopt -1,2

Apparently it thinks "-1,2" is an option name.  No, it's a string option value, and should not be interpreted in any other way.  I want it passed as the option value.  I would want the same no matter *what* characters it contained.  And I don't want to have to glue the two arguments together with "=".

----------
nosy: +karzes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Tue Jan  9 01:07:30 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Jan 2018 06:07:30 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on macOS
 10.13.2 (darwin 17.3.0)
In-Reply-To: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>
Message-ID: <1515478050.45.0.467229070634.issue32517@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mattbillenstein

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Tue Jan  9 02:00:18 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 09 Jan 2018 07:00:18 +0000
Subject: [issue32474] argparse nargs should support string wrapped integers too
In-Reply-To: <1514790162.58.0.467229070634.issue32474@psf.upfronthosting.co.za>
Message-ID: <1515481218.24.0.467229070634.issue32474@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

In https://bugs.python.org/issue11354

'argparse: nargs could accept range of options count'

I explored the option allowing regex style range arguments, such as nargs='{2,4}' or an equivalent tuple nargs=(2,4).

But that builds on https://bugs.python.org/issue9849, which seeks better error checking of the `nargs` parameter.  In the current implementation, there is no checking or parsing of the value. The full range of allowable values is determined by its use in 2 methods:

_get_nargs_pattern
_format_args

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Tue Jan  9 02:11:00 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 09 Jan 2018 07:11:00 +0000
Subject: [issue32123] Make the API of argparse.HelpFormatter public
In-Reply-To: <1511517203.18.0.213398074469.issue32123@psf.upfronthosting.co.za>
Message-ID: <1515481860.34.0.467229070634.issue32123@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

To elaborate on my last comment, the existing subclasses that customize formatting modify

_fill_text
_split_lines
_get_help_string
_get_default_metavar_for_optional
_get_default_metavar_for_positional

those are all 'private' methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32123>
_______________________________________

From report at bugs.python.org  Tue Jan  9 03:14:51 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Jan 2018 08:14:51 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515485691.21.0.467229070634.issue32507@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d135f20ae8887acc7716561bc8f4c7eb6d58d24c by Steve Dower in branch 'master':
bpo-32507: Change Windows install to include app-local UCRT (#5119)
https://github.com/python/cpython/commit/d135f20ae8887acc7716561bc8f4c7eb6d58d24c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Tue Jan  9 03:16:36 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Jan 2018 08:16:36 +0000
Subject: [issue32507] Change Windows install to applocal UCRT
In-Reply-To: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>
Message-ID: <1515485796.37.0.467229070634.issue32507@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Missed the a4 cutoff, but it'll be in 3.7.0b1.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Tue Jan  9 03:45:58 2018
From: report at bugs.python.org (Matt Billenstein)
Date: Tue, 09 Jan 2018 08:45:58 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on macOS
 10.13.2 (darwin 17.3.0)
In-Reply-To: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>
Message-ID: <1515487558.96.0.467229070634.issue32517@psf.upfronthosting.co.za>


Matt Billenstein <matt at vazor.com> added the comment:

I don't see a conflict in the uids:

mattb at mattb-mbp2:~ $ id -u buildbot
506
mattb at mattb-mbp2:~ $ id -u _timed
266
mattb at mattb-mbp2:~ $ grep _timed /etc/passwd
_timed:*:266:266:Time Sync Daemon:/var/db/timed:/usr/bin/false
mattb at mattb-mbp2:~ $ grep 506 /etc/passwd
mattb at mattb-mbp2:~ $

Buildbot is started via launchd:

mattb at mattb-mbp2:~ $ sudo cat /Library/LaunchDaemons/net.buildbot.slave.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>net.buildbot.slave</string>
    <key>UserName</key>
    <string>buildbot</string>
    <key>WorkingDirectory</key>
    <string>/Users/buildbot/buildarea</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/buildbot/bin/run_slave.sh</string>
    </array>
    <key>StandardOutPath</key>
    <string>twistd.log</string>
    <key>StandardErrorPath</key>
    <string>twistd.log</string>
    <key>KeepAlive</key>
    <true/>
    <key>SessionCreate</key>
    <true/>
</dict>
</plist>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Tue Jan  9 04:08:13 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 09 Jan 2018 09:08:13 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1515488893.39.0.467229070634.issue9334@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I tend to agree with you about pre-scanning the arguments to find options. But at this point, our options to change the code are limited. The last time I looked at this (and it's been years), I came to the conclusion that the argument pre-scanning was sufficiently baked in to argparse that a separate traditional" mode was better done as a separate library.

But I lack the time and energy to research if there's an existing third party library that's acceptable, what it would take to enhance optparse, or write a new library.

It sounds like what you want is optparse, but with help in processing positional arguments. Is that a fair statement? Or is there some other feature of argparse that's preventing you from using optparse? I know for me it's help with positional arguments.

I think at some point we need to close this bug, because I don't see a way of modifying argparse to do what you (and I) want. paul.j3 explains several times in his messages on this thread that it's just how argparse fundamentally works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Tue Jan  9 04:53:27 2018
From: report at bugs.python.org (Anant Prakash)
Date: Tue, 09 Jan 2018 09:53:27 +0000
Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1515491607.81.0.467229070634.issue24459@psf.upfronthosting.co.za>


Anant Prakash <anantprakashjsr at gmail.com> added the comment:

I am going to take the patch, edit and make a github PR for this.

Any updates on this issue are welcome. Thank you

----------
nosy: +Anant Prakash

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

From report at bugs.python.org  Tue Jan  9 04:57:02 2018
From: report at bugs.python.org (Tom Karzes)
Date: Tue, 09 Jan 2018 09:57:02 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1515491822.48.0.467229070634.issue9334@psf.upfronthosting.co.za>


Tom Karzes <karzes at sonic.net> added the comment:

Here's my situation:  I originally used optparse, although some of the guys I worked with at the time were starting to use argparse.  At first I thought, I'm sticking with optparse, it's more standard than argparse and probably better supported.  But at some point optparse became documented as deprecated, with argparse being hailed as its replacement.

At that point my preference switched, again mostly because I wanted the most reliable, best supported option parsing package.  And yes, I have come to appreciate some of the features of argparse, but to me that takes a back seat to correct functionality.

The documentation for argparse promotes the idea that it completely subsumes optparse, and that applications that use optparse can easily be converted to use argparse.  And for the most part that's true, except that optparse identifies options correctly and argparse does not.  That really, really needs to be documented.

What I want is a supported, standard option parsing library that knows how to extract option values correctly.  I used to have that with optparse, but now I feel like the rug's been pulled out from under me.  optparse is supposedly deprecated, and argparse doesn't work.  So I either use a package that could be removed from Python distributions at any time, or I use a package that has dangerous bugs.  I don't find either alternative very attractive.

As I said, un-deprecating optparse would be sufficient, especially if people started adding some of the argparse functionality to it.  Creating a new package would work too.  But from what I've seen, it sounds like argparse is beyond hope of repair and will never work properly.  I.e., it's a dead-end development path.  So why isn't *argparse* deprecated?

I've always maintained that core functionality is of primary importance.  Shiny bells and whistles, no matter how useful, are of secondary importance.  In my opinion, the wrong package was deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Tue Jan  9 04:58:59 2018
From: report at bugs.python.org (Andy Balaam)
Date: Tue, 09 Jan 2018 09:58:59 +0000
Subject: [issue30782] Allow limiting the number of concurrent tasks in
 asyncio.as_completed
In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za>
Message-ID: <1515491939.91.0.467229070634.issue30782@psf.upfronthosting.co.za>


Andy Balaam <mail at artificialworlds.net> added the comment:

I would argue that this makes as_completed a lot more useful than it is now, so would be worth adding (maybe after 3.7).

But, if this does not go into asyncio, is there another library where it would belong?  Or should this be a completely new library?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30782>
_______________________________________

From report at bugs.python.org  Tue Jan  9 05:25:18 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 09 Jan 2018 10:25:18 +0000
Subject: [issue32459] Capsule API usage docs are incompatible with module
 reloading (etc)
In-Reply-To: <1514698021.73.0.467229070634.issue32459@psf.upfronthosting.co.za>
Message-ID: <1515493518.83.0.467229070634.issue32459@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
nosy: +Dormouse759, encukou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32459>
_______________________________________

From report at bugs.python.org  Tue Jan  9 08:11:07 2018
From: report at bugs.python.org (Anant Prakash)
Date: Tue, 09 Jan 2018 13:11:07 +0000
Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1515503467.5.0.467229070634.issue24459@psf.upfronthosting.co.za>


Anant Prakash <anantprakashjsr at gmail.com> added the comment:

Ignore my previous comment.
My bad.

----------

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

From report at bugs.python.org  Tue Jan  9 08:34:40 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Jan 2018 13:34:40 +0000
Subject: [issue32518] HTTPServer can't deal with persistent connection properly
In-Reply-To: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>
Message-ID: <1515504880.24.0.467229070634.issue32518@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it does support a persistent connection, but that connection lasts until it is shut down from the other side.  Documentation improvement suggestions are welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Tue Jan  9 08:36:07 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Jan 2018 13:36:07 +0000
Subject: [issue32518] HTTPServer can't deal with persistent connection properly
In-Reply-To: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>
Message-ID: <1515504967.75.0.467229070634.issue32518@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In particular, if we don't already have an example of using the threading mixin we should, so a doc RFE to add that would be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Tue Jan  9 08:49:45 2018
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 09 Jan 2018 13:49:45 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1515505785.67.0.467229070634.issue32430@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

We do use Setup/Setup.local at Google (and have for many years now), and I find it very useful. (FWIW, the 'we would use' comment in msg294174 was about the new '*disabled*' feature, not about Setup files in general.) Avoiding local changes is also important to us, because it makes it much easier to track upstream changes. If anyone was thinking of getting rid of Modules/Setup, please don't, at least not without something more sensible than setup.py to replace it :)

That said, I don't really care about the Setup.dist/Setup distinction. I vaguely recall the situation before we had Setup.dist, which I guess was slightly worse, but primarily for people who build from the source repo. Having a Setup.local file is convenient as long as the Setup file is necessary for the base build, but Setup/Setup.dist doesn't matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Tue Jan  9 09:05:39 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 09 Jan 2018 14:05:39 +0000
Subject: [issue32007] nis module fails to build against glibc-2.26
In-Reply-To: <1510419983.02.0.213398074469.issue32007@psf.upfronthosting.co.za>
Message-ID: <1515506739.23.0.467229070634.issue32007@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

#32521 is a duplicate of this issue. I didn't notice this issue when I created a fix.

- I agree with Benjamin, let's deprecate the NIS module. NIS/YP functionality has been replaced by NSS a long time ago.
- We have no infrastructure to use pkg-config from distutils yet, which is a shame.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32007>
_______________________________________

From report at bugs.python.org  Tue Jan  9 09:58:10 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 09 Jan 2018 14:58:10 +0000
Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent
 key list
In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za>
Message-ID: <1515509890.37.0.467229070634.issue29640@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

I'm a bit out of my depth here. Victor, could you chime in?

The problem with Harris' patch is that, once fork() is protected by the thread lock, acquiring that lock (by e.g. calling `PyGILState_GetThisThreadState`) from an `atfork` handler hangs deadlocks.

I thought that can be solved by doing the locking in an atfork handler, but that's not working out -- CPython's pthread_atfork (which would lock _PyThread_AcquireKeyLock for the duration of the fork) would need to be called *after* an extension's pthread_atfork (which needs the thread lock temporarily).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29640>
_______________________________________

From report at bugs.python.org  Tue Jan  9 10:21:52 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jan 2018 15:21:52 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1515511312.86.0.467229070634.issue28009@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What is the desired behavior, specifically, of 
uuid.getnode() - constant, or 'random'?

I'm also certain getnode() is supposed to return a hardware-determined number (usually the MAC address of an Ethernet interface).  A random output wouldn't need so much platform-specific harness.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Tue Jan  9 10:32:47 2018
From: report at bugs.python.org (David Carlier)
Date: Tue, 09 Jan 2018 15:32:47 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1515511967.34.0.467229070634.issue32493@psf.upfronthosting.co.za>


David Carlier <dcarlier at afilias.info> added the comment:

I guessed that :-) I trusted it worked just fine for you. To be honest I know nearly nothing about AIX specificities :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Tue Jan  9 10:46:50 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 15:46:50 +0000
Subject: [issue32522] Add precision argument to datetime.now
Message-ID: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

One thing I think that is fairly common is the desire to get the current datetime only up to a current precision, so you see a lot of things in, say, `dateutil` like this:

    dt = datetime.now().replace(hours=0, minutes=0, seconds=0, microseconds=0)

Or:

    dt = datetime.now().replace(microseconds=0)

I think it would make sense to add a `precision` keyword argument, similar to the `timespec` argument to isoformat (https://docs.python.org/3/library/datetime.html#datetime.datetime.isoformat), then you could just do:

dt = datetime.now(precision='day')

And get the current date as a datetime.

----------
components: Library (Lib)
messages: 309703
nosy: belopolsky, p-ganssle, tim.peters
priority: normal
severity: normal
status: open
title: Add precision argument to datetime.now
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 10:56:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Jan 2018 15:56:42 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515513402.38.0.467229070634.issue32522@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> dt = datetime.now(precision='day')

Why not creating a date and then convert it to a datetime object?

> dt = datetime.now().replace(microseconds=0)

Yeah, that one annoys me as well, but I learnt the .replace(microseconds=0) hack, or how to format without microseconds.

By the way, are you aware of Python 3.7 enhancement of .isoformat(), the new timespec parameter?
https://docs.python.org/dev/library/datetime.html#datetime.datetime.isoformat

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 10:58:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Jan 2018 15:58:32 +0000
Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent
 key list
In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za>
Message-ID: <1515513512.35.0.467229070634.issue29640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

There is a more general issue for any lock and fork(): bpo-6721, "Locks in the standard library should be sanitized on fork".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29640>
_______________________________________

From report at bugs.python.org  Tue Jan  9 10:59:35 2018
From: report at bugs.python.org (Marcel Plch)
Date: Tue, 09 Jan 2018 15:59:35 +0000
Subject: [issue32374] Document that m_traverse for multi-phase initialized
 modules can be called with m_state=NULL
In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za>
Message-ID: <1515513575.48.0.467229070634.issue32374@psf.upfronthosting.co.za>


Change by Marcel Plch <gmarcel.plch at gmail.com>:


----------
pull_requests: +4999

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:04:50 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 16:04:50 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515513890.14.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

An alternate possibility here might be to implement either `__round__` or a `round` function in `datetime` (which would basically automatically add this precision functionality to *all* the constructors, not just now). An example implementation:

from datetime import datetime

    class Datetime(datetime):
        def __round__(self, ndigits=None):
            if ndigits is None:
                return self

            dflt_args = {
                'month': 1,
                'day': 1,
                'hour': 0,
                'minute': 0,
                'second': 0,
                'microsecond': 0
            }

            args = list(dflt_args.keys())

            if ndigits not in dflt_args:
                raise ValueError('Unknown rounding component: %s' % ndigits)

            idx = args.index(ndigits)

            return self.replace(**{arg: dflt_args[arg] for arg in args[idx:]})


It's not great that `__round__`'s argument is `ndigits`, though. If we don't want to just add a `round` method to `datetime`, another option might be to implement `__mod__` somehow, so you could do `datetime.now() % timedelta(seconds=1)`, but that seems complicated (and also doesn't let you round to the nearest month).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:09:24 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 16:09:24 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515514164.26.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

@Victor: With regards to getting a "date as datetime", that is another way to do it that I have also done in the past (and in fact it's how the new dateutil.utils.today() function is implemented: https://github.com/dateutil/dateutil/blob/master/dateutil/utils.py#L7), but it's still not particularly elegant and doesn't obviously convey what you want there.

And yes, I'm aware of timespec, I linked it in my original report (it was actually added in Python 3.6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:11:04 2018
From: report at bugs.python.org (Pox TheGreat)
Date: Tue, 09 Jan 2018 16:11:04 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1515514264.62.0.467229070634.issue31804@psf.upfronthosting.co.za>


Pox TheGreat <poxthegreat at gmail.com> added the comment:

Unfortunately this is NOT a duplicate of https://bugs.python.org/issue28326. That issue is about a closed output stream. In that case sys.stdout and sys.stderr are file like objects which have been closed.

This issue is about sys.stdout and sys.stderr being None! This is because pythonw was used not python.

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:11:34 2018
From: report at bugs.python.org (Marcel Plch)
Date: Tue, 09 Jan 2018 16:11:34 +0000
Subject: [issue32374] Document that m_traverse for multi-phase initialized
 modules can be called with m_state=NULL
In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za>
Message-ID: <1515514294.71.0.467229070634.issue32374@psf.upfronthosting.co.za>


Marcel Plch <gmarcel.plch at gmail.com> added the comment:

I have created a PR at https://github.com/python/cpython/pull/5140
It contains documentation, plus, in --with-pydebug mode, it calls m_traverse to catch easy cases of not handling the m_state==NULL case early.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:15:16 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 16:15:16 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515514515.99.0.467229070634.issue32522@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:18:49 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Jan 2018 16:18:49 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515514729.25.0.467229070634.issue32522@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:20:55 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Jan 2018 16:20:55 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515514855.55.0.467229070634.issue32522@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The .replace(microseconds=0) hack annoys me too, but I'd be happier with a simpler solution: make datetime.now() accept a microseconds parameter, so datetime.now(microseconds=0) would be equivalent to datetime.now().replace(microseconds=0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:21:22 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Jan 2018 16:21:22 +0000
Subject: [issue32523] inconsistent spacing in changelog.html
Message-ID: <1515514882.86.0.467229070634.issue32523@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at python.org>:

The rendered changelog.html files produced "make html" have inconsistent spacing between items. Usually, the first changelog topic section (e.g. Security) starts with no blank lines between items but occasionally some subsequent sections will render with a blank link between items; this seems to be often true for the Library section, but not always. This is visible across the recent 3.x branches; here's an example with the stable 3.5 docs:

Library section has blank line separator:
https://docs.python.org/3.5/whatsnew/changelog.html#id5

Library section has no blank separators:
https://docs.python.org/3.5/whatsnew/changelog.html#id11

----------
assignee: docs at python
components: Documentation
messages: 309711
nosy: docs at python, ned.deily
priority: normal
severity: normal
status: open
title: inconsistent spacing in changelog.html
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32523>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:21:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Jan 2018 16:21:41 +0000
Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent
 key list
In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za>
Message-ID: <1515514901.33.0.467229070634.issue29640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Python 3 is not affected by this issue because it uses native thread locale storage (TLS):

* pthread: pthread_getspecific() / pthread_setspecific()
* Windows: TlsGetValue() / TlsSetValue()

I'm not sure that it's doable to backport such enhancement, since Python 2.7 supports many thread implementations, not only NT (Windows) and pthread:

* Python/thread_atheos.h
* Python/thread_beos.h
* Python/thread_cthread.h
* Python/thread_lwp.h
* Python/thread_nt.h
* Python/thread_os2.h
* Python/thread_pth.h
* Python/thread_pthread.h
* Python/thread_sgi.h
* Python/thread_solaris.h
* Python/thread_wince.h

Maybe it's doable for a Linux vendor, but it's going to be a large change that has to be maintained downstream :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29640>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:22:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Jan 2018 16:22:51 +0000
Subject: [issue32523] inconsistent spacing in changelog.html
In-Reply-To: <1515514882.86.0.467229070634.issue32523@psf.upfronthosting.co.za>
Message-ID: <1515514971.19.0.467229070634.issue32523@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

See also discussion at https://github.com/python/core-workflow/issues/209

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32523>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:33:19 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 16:33:19 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515515599.6.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

@Barry I don't think it's a good idea to duplicate the `replace` functionality in `datetime` like that. I think the main problem isn't the `.replace`, it's the fact that you have to specify exactly which components you want to set to zero - to get "the beginning of this month" or "today at midnight" or "the beginning of the current hour" or "the beginning of the current minute", you have to manually replace a whole list of these components.

It doesn't help that `datetime.today()` leaks implementation details from `date.today()`, thus making it a slower, worse version of `datetime.now()`, since the overwhelmingly most common use cases for datetime rounding are probably "get today at midnight" and "get the current time with second precision". Still, I think a more general fix would be better now and in the future.

Even if we had "get today at midnight" and a `microseconds=0` argument to `datetime.now`, without a more general version of this, if (or possibly *when*) nanosecond precision is added to `datetime`, you'd now start having to add `microseconds=0, nanoseconds=0` or something to `datetime` (depending on the implementation of nanoseconds).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:49:04 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 16:49:04 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515516544.34.0.467229070634.issue32522@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Maybe __round__ can be generalized to take a timedelta instead of ndigits?

For some related prior art, take a look at <http://code.kx.com/q/ref/arith-integer/#xbar>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:51:06 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jan 2018 16:51:06 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1515516666.88.0.467229070634.issue31804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

@Pox, nevertheless, the fix committed in https://github.com/python/cpython/pull/4073 should also fix this issue. Do you disagree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:56:48 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 16:56:48 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515517008.73.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I think if we're going to use `timedelta` then `__mod__` is the more appropriate option here, since it would be hard to interpret what `round(dt, timedelta(hours=2, microseconds=31))` would do.

Either __mod__ or __round__ with `timedelta` is a bit of a stretch in my opinion, and also is limited to well-defined units (and as such you can't round to the nearest month or year). I think a `round` taking either a string or an enum is the simplest, easiest to understand implementation (and/or adding a precision argument to `now` that is equivalent to `round(datetime.now(), precision)`).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 12:02:14 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 17:02:14 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515517334.48.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

One thing to note, the "example implementation" of __round__ above is an actual working prototype*:

>>> round(Datetime.now(), 'second')
Datetime(2018, 1, 9, 11, 59, 35)

>>> round(Datetime.now(), 'day')
Datetime(2018, 1, 9, 0, 0)

>>> round(Datetime.now(), 'minute')
Datetime(2018, 1, 9, 11, 59)


So to be clear, `ndigits` can already accept any arbitrary type, it's just the fact that it's *called* `ndigits` that may be confusing to users.

*with the exception that it has a bug, the final line should actually be:

    return self.replace(**{arg: dflt_args[arg] for arg in args[(idx+1):]})

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 12:32:40 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 17:32:40 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515519160.3.0.467229070634.issue32522@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

In my experience, when dealing with temporal data truncation (rounding towards -infinity) is more useful than any other form of rounding. See also issue 19475.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 12:38:03 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 09 Jan 2018 17:38:03 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1515511312.86.0.467229070634.issue28009@psf.upfronthosting.co.za>
Message-ID: <9e5a1465-a1a6-0ed1-a315-9ba34ae6d07a@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 09/01/2018 16:21, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> What is the desired behavior, specifically, of
> uuid.getnode() - constant, or 'random'?
>
> I'm also certain getnode() is supposed to return a hardware-determined number (usually the MAC address of an Ethernet interface).  A random output wouldn't need so much platform-specific harness.

FYI

The current implementation (Lib/uuid.py) - python2 as an example with 
with no _uuid support, compared to the master (as of yesterday) with 
_uuid support.

Program (x2.py):

michael at x071:[/data/prj/python/git]cat *master/x2.py
import uuid
import sys
print (sys.version)
print("getnode = %x\n" % uuid.getnode())
print("getnode = %x\n" % uuid.getnode())

michael at x071:[/data/prj/python/git]python *master/x2.py
2.7.12 (default, Sep 29 2016, 12:02:17) [C]
getnode = a92929dc8a78

getnode = a92929dc8a78

michael at x071:[/data/prj/python/git]python *master/x2.py
2.7.12 (default, Sep 29 2016, 12:02:17) [C]
getnode = cdff09dd1306

getnode = cdff09dd1306

So it appears, everytime python runs - without _uuid - a new "getnode()" 
value is established, for as long as the process runs (hoping!)

Below - the value returned is the MAC address of the first ethernet 
adapter (ent0)

michael at x071:[/data/prj/python/git]gcc*/python *master/x2.py
3.7.0a3+ (default, Jan? 8 2018, 16:05:08)
[GCC 4.7.4]
getnode = fad18cf76204

getnode = fad18cf76204

michael at x071:[/data/prj/python/git]xlc*/python *master/x2.py
3.7.0a3+ (heads/master:9b99747, Jan? 8 2018, 15:50:03) [C]
getnode = fad18cf76204

getnode = fad18cf76204

*****

Is there any interest for a PR on Python2.7 and/or Python3.5? I guess it 
could be considered a bug IF the getnode() value is suppossed to be 
related to the MAC address and/or consistent over sessions.

HTH, Michael

>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue28009>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Tue Jan  9 12:38:16 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Jan 2018 17:38:16 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1515519496.21.0.467229070634.issue31804@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Pox, please retest with either 3.6.4 or 3.7.0a3 (or .0a4 when released, soon).  Both were released after the merge that should fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Tue Jan  9 13:09:13 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 18:09:13 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515521353.79.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> In my experience, when dealing with temporal data truncation (rounding towards -infinity) is more useful than any other form of rounding. See also issue 19475.

Ah, I agree - if you see that's how my __round__ implementation works. I guess that's another problem with the semantics of `round` (which are assumed to round to the nearest whole number). I suppose we could implement __floor__, but then you have the counter-intuitive property that in order to get access to this method, you have to import `math.floor`.

We could add a `datetime.truncate()` method, maybe, and not try to be clever about overloading existing operations. Or punt on the idea of truncation in general and do what I proposed in the original thread and have all the truncation happen in `now`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 13:51:37 2018
From: report at bugs.python.org (Melissa Chang)
Date: Tue, 09 Jan 2018 18:51:37 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1515523897.25.0.467229070634.issue10496@psf.upfronthosting.co.za>


Change by Melissa Chang <melchang at google.com>:


----------
nosy:  -Melissa Chang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:02:46 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Jan 2018 19:02:46 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515515599.6.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <6EE4749C-BF69-4E43-9713-B5B9F047068D@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 9, 2018, at 08:33, Paul Ganssle <report at bugs.python.org> wrote:

> @Barry I don't think it's a good idea to duplicate the `replace` functionality in `datetime` like that. I think the main problem isn't the `.replace`, it's the fact that you have to specify exactly which components you want to set to zero - to get "the beginning of this month" or "today at midnight" or "the beginning of the current hour" or "the beginning of the current minute", you have to manually replace a whole list of these components.

I personally haven?t ever had to do anything but get rid of the microseconds field, so maybe my use case is too limited.  It?s a minor inconvenience and I don?t like having to throw away an intermediate datetime, so that?s the main thing I?d like to improve.  I?d also caution trying to get too fancy and complicated for use cases that are already supported or are rare.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:09:27 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 19:09:27 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515524967.1.0.467229070634.issue32522@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

The problem that I have with the round/truncate proposal is that it is not general enough.  Days, hours, minutes etc. are just arbitrary intervals that became popular for obscure historical and astronomical reasons.  In practice, you are as likely to encounter 1 second timeseries as say 10 second timeseries.  Hourly timeseries are as likely to use the "top of the hour" (0 minutes) as they are to use the "bottom of the hour" (30 minutes).  In general, you want to have a kind of "snap to grid" functionality on the time axis where "the grid" is an arbitrary RRULE.

Looking at the dateutil, I don't see a truncate to rrule function.  Maybe a good starting point would be to implement that in dateutil and if some simpler pattern emerges that can be proposed for stdlib, we can discuss it then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:18:38 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 09 Jan 2018 19:18:38 +0000
Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent
 key list
In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za>
Message-ID: <1515525518.5.0.467229070634.issue29640@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Gah! The more I look into locks & forks ... the more I learn, to put it mildly.

Instead of piling on workarounds, I'll try my hand at using native thread-local storage for pthread, and avoid the locking altogether.

Hopefully that can make it in as a bugfix? At least for this bug, it most likely *is* the most appropriate fix -- though I can only fix it for pthread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29640>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:24:23 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 19:24:23 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515525862.99.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Looking at the dateutil, I don't see a truncate to rrule function.  Maybe a good starting point would be to implement that in dateutil and if some simpler pattern emerges that can be proposed for stdlib, we can discuss it then.

I think that a "truncate to rrule" function is *way* beyond the scope of the standard library, since it would require an actual rrule implementation - about which there are still many questions. That said, to accomplish what you want, you would just use `rrule.before` (floor) or `rrule.after` (ceil):

    from dateutil.rrule import rrule, DAILY
    from datetime import datetime

    rr = rrule(freq=DAILY, byhour=15, byminute=30, dtstart=datetime(2000, 1, 1))

    print(rr.before(datetime(2011, 4, 17, 12, 18)))
    # 2011-04-16 15:30:00

    print(rr.before(datetime(2011, 4, 17, 16, 17)))
    # 2011-04-17 15:30:00


That said, I don't see why this is any different from the `timespec` option to isoformat (with the exception that this would support `day` and `month`). In fact, in Python 3.7, you can implement it in *terms* of timespec fairly easily:

    def truncate(dt, timespec):
        return dt.fromisoformat(dt.isoformat(timespec=timespec))

I think the fact that `timespec` is useful indicates why this is useful even before serialization - a lot of times you want a datetime *up to a specific precision*. I would also argue that the fact that `replace` allows you to manipulate each component individually - and the fact that replacing all elements of a datetime below a certain level is a very common idiom - demonstrates that these arbitrary truncation rulesets *are* special in that they are among the most common operations that people do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:27:23 2018
From: report at bugs.python.org (Matt Billenstein)
Date: Tue, 09 Jan 2018 19:27:23 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on macOS
 10.13.2 (darwin 17.3.0)
In-Reply-To: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>
Message-ID: <1515526043.87.0.467229070634.issue32517@psf.upfronthosting.co.za>


Matt Billenstein <matt at vazor.com> added the comment:

Note, I can repro running it by hand from the cli.  And I cannot repro on 3.x, only 3.6 on the same machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:38:10 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jan 2018 19:38:10 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1515526690.2.0.467229070634.issue32493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset b4ebaa7099c3413b42a97777581c4ca560fe7540 by Antoine Pitrou (David Carlier) in branch 'master':
bpo-32493: Not only AIX, but FreeBSD has uuid_create support (#5089)
https://github.com/python/cpython/commit/b4ebaa7099c3413b42a97777581c4ca560fe7540


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:38:34 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jan 2018 19:38:34 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1515526714.68.0.467229070634.issue32493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you for the fix David!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:41:58 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 19:41:58 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515526918.2.0.467229070634.issue32522@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

> I think that a "truncate to rrule" function is *way* beyond the scope of the standard library

I agree and I did not propose that.  What I said was that in the process of implementing truncate to rrule in dateutil you may encounter some common pattern that may benefit from a new stdlib datetime feature.

The operation that I often need is

def truncate_datetime(t:datetime, interval:timedelta, start=datetime.min) -> datetime
    """Return the largest datetime of the form start + interval * i not greater than t"""

but it is exactly the kind of one-liner that does not belong to stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:44:33 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 09 Jan 2018 19:44:33 +0000
Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent
 key list
In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za>
Message-ID: <1515527073.42.0.467229070634.issue29640@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +5000
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29640>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:45:42 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 09 Jan 2018 19:45:42 +0000
Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent
 key list
In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za>
Message-ID: <1515527142.76.0.467229070634.issue29640@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

WIP pull request: https://github.com/python/cpython/pull/5141
(I'll not get back to this for a few days, sadly.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29640>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:54:54 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 19:54:54 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515527694.42.0.467229070634.issue32522@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

> replacing all elements of a datetime below a certain level is a very common idiom

This can be accomplished rather efficiently by truncating a time tuple:

>>> t = datetime.now()
>>> datetime(*t.timetuple()[:6])
datetime.datetime(2018, 1, 9, 14, 47, 12)
>>> datetime(*t.timetuple()[:5])
datetime.datetime(2018, 1, 9, 14, 47)
>>> datetime(*t.timetuple()[:4])
datetime.datetime(2018, 1, 9, 14, 0)
>>> datetime(*t.timetuple()[:3])
datetime.datetime(2018, 1, 9, 0, 0)

if you do this often, you can wrap this in a function


_PARTS = {'seconds': 6, 'minutes': 5, ...}
def truncate_to(t, timespec):
    return datetime(*t.timetuple()[:_PARTS[timespec])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 14:54:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Jan 2018 19:54:55 +0000
Subject: [issue24340] co_stacksize estimate can be highly off
In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za>
Message-ID: <1515527695.05.0.467229070634.issue24340@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d4864c61e3e27e337762dc45e504977299bd5b46 by Serhiy Storchaka in branch 'master':
bpo-24340: Fix estimation of the code stack size. (#5076)
https://github.com/python/cpython/commit/d4864c61e3e27e337762dc45e504977299bd5b46


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24340>
_______________________________________

From report at bugs.python.org  Tue Jan  9 15:16:02 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 20:16:02 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515528962.57.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> This can be accomplished rather efficiently by truncating a time tuple:

This will not preserve tzinfo, and (though this is not a concern unless nanosecond precision is added), I don't believe it preserves microseconds either.

That said, it's also not very readable code without a wrapper - it's not obvious that you're trying to truncate, or what level you're truncating to, just reading it. I think it's worth considering "truncate" to be a first-class operation of datetimes, since it comes up very frequently - people truncating off unnecessary microseconds from `now`, people truncating the result of `datetime.now()` to get today, people getting the beginning of a given month, etc.

Of course, then the question is just "where does this wrapper live". It can live in user code, which is probably not ideal since a bunch of people are implementing their own versions of this common operation and carrying around `utils` submodules or whatever just for this, or it can live in third party libraries like `dateutil` or `boltons`, or it can live in the standard library - where it will likely get the most optimized treatment. (And, honestly, `dateutil` would provide a version-independent backport anyway).

That said, if the answer to the above is "not in the standard library", I think it makes sense to add a precision argument to `now`, since that is probably the most common use case for this sort of truncation function - and it also makes a lot of sense to allow users to specify the precision with which they get the current time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:06:30 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 21:06:30 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515531990.29.0.467229070634.issue32522@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am about +0 on adding a keyword argument to datetime.now.  Note that as I wrote in issue 19475 (msg202242), "precision" may be a misleading name because python makes no guarantee about the precision of the computer clock.

Still, this feature is not appealing enough to try to squeeze into 3.7 release schedule.  I think this should go through a round of discussion either on datetime-sig or python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:12:50 2018
From: report at bugs.python.org (Segev Finer)
Date: Tue, 09 Jan 2018 21:12:50 +0000
Subject: [issue32524] Python 2.7 leaks a packages __init__.py module object on
 SyntaxError
Message-ID: <1515532370.23.0.467229070634.issue32524@psf.upfronthosting.co.za>


New submission from Segev Finer <segev208 at gmail.com>:

With the file hello/__init__.py:

    ham = 123
    spam()spam()

I get the following:

    Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import hello
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "hello\__init__.py", line 2
        spam()spam()
                 ^
    SyntaxError: invalid syntax
    >>> import hello
    >>> print hello
    <module 'hello' from 'hello'>
    >>> print dir(hello)
    ['__doc__', '__file__', '__name__', '__package__', '__path__']
    >>>

I'd expect to get the SyntaxError twice, which is indeed what happens on at least Python 3.6 (Possibly earlier Python 3 versions).

Originally found here https://github.com/pallets/flask/issues/2423 & https://github.com/pallets/flask/pull/2588

I'm going to submit a PR with a fix.

----------
components: Interpreter Core
messages: 309736
nosy: Segev Finer
priority: normal
severity: normal
status: open
title: Python 2.7 leaks a packages __init__.py module object on SyntaxError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32524>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:17:35 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 21:17:35 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515532655.3.0.467229070634.issue32522@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

> (And, honestly, `dateutil` would provide a version-independent backport anyway).

Why not start with that?  Remember: python standard library is where code goes to die.  By implementing this feature in dateutil you will not be tied to relatively slow python release schedule.  Of course, you cannot change datetime.now from a 3rd party module, but you can provide your own dateutil.now with the desired features.

The only downside I see is that you will need to copy much of datetime.now implementation which is rather convoluted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:21:22 2018
From: report at bugs.python.org (Segev Finer)
Date: Tue, 09 Jan 2018 21:21:22 +0000
Subject: [issue32524] Python 2.7 leaks a packages __init__.py module object on
 SyntaxError
In-Reply-To: <1515532370.23.0.467229070634.issue32524@psf.upfronthosting.co.za>
Message-ID: <1515532882.29.0.467229070634.issue32524@psf.upfronthosting.co.za>


Change by Segev Finer <segev208 at gmail.com>:


----------
keywords: +patch
pull_requests: +5001
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32524>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:35:27 2018
From: report at bugs.python.org (Segev Finer)
Date: Tue, 09 Jan 2018 21:35:27 +0000
Subject: [issue30121] Windows: subprocess debug assertion on failure to
 execute the process
In-Reply-To: <1492728235.69.0.898513798091.issue30121@psf.upfronthosting.co.za>
Message-ID: <1515533727.67.0.467229070634.issue30121@psf.upfronthosting.co.za>


Change by Segev Finer <segev208 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30121>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:39:26 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Jan 2018 21:39:26 +0000
Subject: [issue32267] strptime misparses offsets with microsecond format
In-Reply-To: <1512900720.16.0.213398074469.issue32267@psf.upfronthosting.co.za>
Message-ID: <1515533966.99.0.467229070634.issue32267@psf.upfronthosting.co.za>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32267>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:44:13 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 21:44:13 +0000
Subject: [issue32522] Add precision argument to datetime.now
In-Reply-To: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>
Message-ID: <1515534253.82.0.467229070634.issue32522@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Still, this feature is not appealing enough to try to squeeze into 3.7 release schedule.  I think this should go through a round of discussion either on datetime-sig or python-ideas.

Agreed. I will put together some summary in the next week or so and send it to one of those (probably python-ideas, I guess).

> Why not start with that?  Remember: python standard library is where code goes to die.  By implementing this feature in dateutil you will not be tied to relatively slow python release schedule.  Of course, you cannot change datetime.now from a 3rd party module, but you can provide your own dateutil.now with the desired features.

This is sort of independent of whether it is implemented in `datetime`, but it's a bit more complicated than that. I have already, for example, implemented a `today()` utility that does what `datetime.today()` should do if it weren't leaking implementation details from how `date.today()` is implemented (i.e. gives you the current date at midnight), because I think that's a very common use.

The reasons I brought this here are:

1. I would *prefer* it if what I implement is more or less in line with what is implemented in the standard library if a standard library solution is going to be provided so that my `dateutil` function is more of a version-independent backport than a "second way of doing things", so the direction that Python is going can inform how I choose to implement my `dateutil` backport.

2. The solution in `dateutil`, which provides functions and classes that manipulate `datetime`, will likely be different from how it is handled upstream, so it's worth having a discussion about what to do in the standard library - the standard library, for example, can overload existing operators on `datetime`, provide alternate constructors, or modify the arguments to existing alternate constructors. The semantics of this are somewhat different from a `dateutil` function that constructs a datetime (for example, there was a lot of discussion in `dateutil.utils.today` about what the function should be called - it would be cleanly namespaced if it were `datetime.today()`, but `today()` seems like it might return a `date`, etc).

For something like this, where `dateutil` is acting more like `boltons` in that it is providing little convenience functions and extensions to the `datetime` library, I think it makes sense to see whether this might get an implementation upstream and what that implementation might look like upstream, even if what happens is that I go off and implement something similar in `dateutil` and we give it a year or two in `pip` to see what problems arise.

I'll also note that even though `dateutil` has a less constrained release schedule and gets to backport features from later Python versions (allowing for earlier adoption), it's widely-used enough that I'm not very comfortable making backwards-incompatible releases. As a result, once an interface is released, it's more or less set, so it's more or less just as important to get this right in dateutil as it is in datetime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:46:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Jan 2018 21:46:04 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1515534364.91.0.467229070634.issue17611@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5002

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:49:13 2018
From: report at bugs.python.org (benrg)
Date: Tue, 09 Jan 2018 21:49:13 +0000
Subject: [issue32525] Empty tuples are not optimized as constant expressions
Message-ID: <1515534553.56.0.467229070634.issue32525@psf.upfronthosting.co.za>


New submission from benrg <benrudiak at gmail.com>:

>From 3.3 on, the expression () is compiled to BUILD_TUPLE 0 instead of LOAD_CONST. That's probably fine and I suppose it's slightly more efficient to avoid adding an entry to the constant table.

The problem is that BUILD_TUPLE 0 is not treated as a constant for folding purposes, so any otherwise constant expression that contain () ends up compiling into O(n) bytecode instructions instead of 1. I think this is a bug (rather than an enhancement) because it seems unlikely to be the intended behavior.

In 3.2 an earlier, and in 2.7, the constant-folding behavior is different, and many constant tuples aren't recognized at compile time for reasons unclear to me, but there are definitely cases it will fold that 3.3+ won't. For example, "x in {(), None}" tests a frozenset in 3.2, but builds a set at run time in 3.3+.

----------
components: Interpreter Core
messages: 309739
nosy: benrg
priority: normal
severity: normal
status: open
title: Empty tuples are not optimized as constant expressions
type: performance
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32525>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:50:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Jan 2018 21:50:57 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1515534657.88.0.467229070634.issue17611@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 5143 is yet one alternative. It is a variant of PR 5006 that restores SETUP_EXCEPT and gets rid of the new opcode BEGIN_FINALLY. SETUP_FINALLY, SETUP_WITH and SETUP_ASYNC_WITH now push NULL on the stack instead.

PR 5143 removes and add fewer opcodes than PR 5006, but changes the behavior of more opcodes. I don't know what of them looks simpler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  9 17:11:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Jan 2018 22:11:58 +0000
Subject: [issue30121] Windows: subprocess debug assertion on failure to
 execute the process
In-Reply-To: <1492728235.69.0.898513798091.issue30121@psf.upfronthosting.co.za>
Message-ID: <1515535918.95.0.467229070634.issue30121@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Oops, I merged the pull requests, but I forgot to close the issue.

Oops, I forgot to close the issue, again... Thanks Segev for closing it, finally :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30121>
_______________________________________

From report at bugs.python.org  Tue Jan  9 17:14:45 2018
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 09 Jan 2018 22:14:45 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1515536085.96.0.467229070634.issue17611@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Can we stick to the one PR, please?
Once it is merged then we can improve things.

Also, I don't like leaving NULLs on the stack, they are an invitation to seg-fault. PR 5143 leaves more NULLs on the stack for longer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:45:00 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:45:00 +0000
Subject: [issue12815] Coverage of smtpd.py
In-Reply-To: <1314001507.51.0.00455911966964.issue12815@psf.upfronthosting.co.za>
Message-ID: <1515545100.87.0.467229070634.issue12815@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

smtpd.py is deprecated so there's really almost zero chance we'll be doing any development on it.  Please check out 

http://aiosmtpd.readthedocs.io/en/latest/

for a third party replacement (maybe pulled into the stdlib for 3.8?)

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12815>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:47:18 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:47:18 +0000
Subject: [issue19678] smtpd.py: channel should be passed to process_message
In-Reply-To: <1385031410.17.0.520349427654.issue19678@psf.upfronthosting.co.za>
Message-ID: <1515545238.56.0.467229070634.issue19678@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm going to close this as won't fix since smtpd.py is deprecated, and there's little chance that folks are still interested in working on it.  See aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19678>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:49:01 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:49:01 +0000
Subject: [issue16462] smtpd should return greeting
In-Reply-To: <1352732891.73.0.549374987784.issue16462@psf.upfronthosting.co.za>
Message-ID: <1515545341.2.0.467229070634.issue16462@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and likely won't see any fixes.  Please take a look at aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16462>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:50:19 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:50:19 +0000
Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer
In-Reply-To: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za>
Message-ID: <1515545419.18.0.467229070634.issue26036@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix simce smtpd.py is deprecated and likely won't see any future improvements.  Please take a look at aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26036>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:51:28 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:51:28 +0000
Subject: [issue25553] smtpd strips final carraige return from received message
 body
In-Reply-To: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za>
Message-ID: <1515545488.11.0.467229070634.issue25553@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and likely won't see much future improvements.  Please take a look at aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Jan  9 19:53:09 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:53:09 +0000
Subject: [issue22158] RFC 6531 (SMTPUTF8) support in smtpd.PureProxy
In-Reply-To: <1407352076.6.0.272779806488.issue22158@psf.upfronthosting.co.za>
Message-ID: <1515545589.59.0.467229070634.issue22158@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
nosy: +barry
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22158>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:53:46 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:53:46 +0000
Subject: [issue12816] smtpd uses library outside of the standard libraries
In-Reply-To: <1314002733.23.0.776557128792.issue12816@psf.upfronthosting.co.za>
Message-ID: <1515545626.13.0.467229070634.issue12816@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12816>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:54:36 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:54:36 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
 should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1515545676.22.0.467229070634.issue11260@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:54:56 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:54:56 +0000
Subject: [issue22071] Remove long-time deprecated attributes from smtpd
In-Reply-To: <1406307098.0.0.954478358175.issue22071@psf.upfronthosting.co.za>
Message-ID: <1515545696.09.0.467229070634.issue22071@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
nosy: +barry
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22071>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:55:19 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:55:19 +0000
Subject: [issue8503] smtpd SMTPServer does not allow domain filtering
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1515545719.65.0.467229070634.issue8503@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:55:40 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:55:40 +0000
Subject: [issue22159] smtpd.PureProxy and smtpd.DebuggingServer do not work
 with decode_data=True
In-Reply-To: <1407359307.97.0.457936656417.issue22159@psf.upfronthosting.co.za>
Message-ID: <1515545740.61.0.467229070634.issue22159@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
nosy: +barry
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22159>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:56:05 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:56:05 +0000
Subject: [issue19806] smtpd crashes when a multi-byte UTF-8 sequence is split
 between consecutive data packets
In-Reply-To: <1385532648.32.0.209027401379.issue19806@psf.upfronthosting.co.za>
Message-ID: <1515545765.23.0.467229070634.issue19806@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
nosy: +barry
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19806>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:56:28 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:56:28 +0000
Subject: [issue14261] Cleanup in smtpd module
In-Reply-To: <1331553850.91.0.315576733805.issue14261@psf.upfronthosting.co.za>
Message-ID: <1515545788.97.0.467229070634.issue14261@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
nosy: +barry
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14261>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:56:50 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:56:50 +0000
Subject: [issue3802] smtpd.py __getaddr insufficient handling
In-Reply-To: <1220849998.55.0.777734204126.issue3802@psf.upfronthosting.co.za>
Message-ID: <1515545810.84.0.467229070634.issue3802@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
nosy: +barry
resolution:  -> wont fix
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3802>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:57:15 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:57:15 +0000
Subject: [issue19679] smtpd.py (SMTPChannel): implement enhanced status codes
In-Reply-To: <1385031598.99.0.0454554803988.issue19679@psf.upfronthosting.co.za>
Message-ID: <1515545835.1.0.467229070634.issue19679@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19679>
_______________________________________

From report at bugs.python.org  Tue Jan  9 19:57:31 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Jan 2018 00:57:31 +0000
Subject: [issue2518] smtpd.py to handle huge email
In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za>
Message-ID: <1515545851.66.0.467229070634.issue2518@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.

----------
resolution:  -> wont fix
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2518>
_______________________________________

From report at bugs.python.org  Wed Jan 10 04:31:53 2018
From: report at bugs.python.org (Joongi Kim)
Date: Wed, 10 Jan 2018 09:31:53 +0000
Subject: [issue32526] Closing async generator while it is running does not
 raise an exception
Message-ID: <1515576713.82.0.467229070634.issue32526@psf.upfronthosting.co.za>


Change by Joongi Kim <me at daybreaker.info>:


----------
components: asyncio
nosy: achimnol, asvetlov, njs, yselivanov
priority: normal
severity: normal
status: open
title: Closing async generator while it is running does not raise an exception
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32526>
_______________________________________

From report at bugs.python.org  Wed Jan 10 04:33:29 2018
From: report at bugs.python.org (Pox TheGreat)
Date: Wed, 10 Jan 2018 09:33:29 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1515576809.47.0.467229070634.issue31804@psf.upfronthosting.co.za>


Pox TheGreat <poxthegreat at gmail.com> added the comment:

Retested it with a freshly installed 3.6.4 version. Used the following code to test:

import sys
import multiprocessing


def foo():
    return 'bar'


if __name__ == '__main__':
    proc = multiprocessing.Process(target=foo)
    proc.start()
    proc.join()
    with open('process_exit_code.txt', 'w') as f:
        f.write(sys.version)
        f.write('\nprocess exit code: ')
        f.write(str(proc.exitcode))

It is very important to run the script with pythonw, not just with python. This is the content of the resulting process_exit_code.txt file on my machine:
3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)]
process exit code: 1

As it can be seen the problem was not fixed. The process exit code should be 0. By default the new multiprocessing process created uses the same interpreter as the creator process, so it uses pythonw too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Wed Jan 10 04:39:22 2018
From: report at bugs.python.org (Joongi Kim)
Date: Wed, 10 Jan 2018 09:39:22 +0000
Subject: [issue32526] Closing async generator while it is running does not
 raise an exception
Message-ID: <1515577162.33.0.467229070634.issue32526@psf.upfronthosting.co.za>


New submission from Joongi Kim <me at daybreaker.info>:

Here is the minimal example code:

https://gist.github.com/achimnol/965a6aecf7b1f96207abf11469b68965

Just run this code using "python -m pytest -s test.py" to see what happens.
(My setup uses Python 3.6.4 and pytest 3.3.2 on macOS High Sierra 10.13.2)

I tried the same logic using synchornous APIs such as threading.Thread / time.sleep instead of loop.create_task / asyncio.sleep, it raised "ValueError: generator already executing" when tried to close the generator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32526>
_______________________________________

From report at bugs.python.org  Wed Jan 10 04:51:33 2018
From: report at bugs.python.org (Bernhard Reiter)
Date: Wed, 10 Jan 2018 09:51:33 +0000
Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener
 when called with any SSL argument
In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za>
Message-ID: <1515577893.22.0.467229070634.issue18543@psf.upfronthosting.co.za>


Bernhard Reiter <bernhard at intevation.de> added the comment:

Yesterday I ran into the same problem and I agree that it should be solved, by either documenting the issue or fixing it.

As the code in https://github.com/python/cpython/blob/master/Lib/urllib/request.py#L199
still shows the branch and
https://docs.python.org/3.7/library/urllib.request.html
today does not hint upon it, I'm adding the Python 3.7 Version indicator.

In 3.7 (dev) docs context is indicated as preferred so the situation may be a little bit better, but still not resolved.

Maybe a fix should change OpenerDirector() to be able to replace or remove a handler.

----------
nosy: +ber
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18543>
_______________________________________

From report at bugs.python.org  Wed Jan 10 05:59:53 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Jan 2018 10:59:53 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1515581993.21.0.467229070634.issue31804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not using Windows, so I'm unable to test using pythonw.  You'll have to provide a fix, or someone else will have to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Wed Jan 10 08:52:34 2018
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Orive?=)
Date: Wed, 10 Jan 2018 13:52:34 +0000
Subject: [issue29992] Expose parse_string in JSONDecoder
In-Reply-To: <1491380525.56.0.628505740968.issue29992@psf.upfronthosting.co.za>
Message-ID: <1515592354.48.0.467229070634.issue29992@psf.upfronthosting.co.za>


Adri?n Orive <aorive at ikerlan.es> added the comment:

I found the same problem. My case seems to be less exotic, as what I'm trying to do is parse some of these strings into decimal.Decimal or datetime.datetime formats. Returning a decimal as a string is becoming quite common in REST APIs to ensure there is no floating point errors.

This is not a simple "a parameter is lacking problem":

1) JSONDecoder has 6 parse_XXX attributes (parse_int, parse_float, parse_constant, parse_string, parse_object, parse_array) and only first 3 of those are offered as parameters. The three last ones fall into a different category as they are not actually parsers but part of the scanner logic, but the first 3 are simple JSON types so, why keep only 3 parsers plus the 2 additional object hooks instead of providing a full set of parsers (arrays, strings, keys)?

2) JSONDecoder.__init__ method calls json.scanner.make_scanner function, so even when subclassing JSONDecoder and modifying some attributes after calling super().__init__ it will not work, the scanner needs to be reseted.

3) make_scanner is implementented in both C (c_make_scanner) and Python (py_make_scanner), the later is used as backup in case the former could not be imported. The C and Python versions behaviour IS NOT CONSISTENT.
  - c_make_scanner IGNORES JSONDecoder's parse_string attribute. This also applies to parse_array and parse_object attributes.
  - py_make_scanner ONLY uses it for JSON object values, keys have json.decoder.scanstring hardcoded.

4) ONLY make_scanner IS BEING "EXPORTED" (__all__ = ['make_scanner']) so knowing the existence of the two versions requires getting deep into json's code. This also applies to json.decoder's scanstring, JSONObject and JSONArray.


The second point would be solved by providing all the needed params, as that would mean that you don't need to modify the attribute after calling JSONDecoder.__init__. This makes more sense than mnoving the make_scanner call out of the __init__ method as it is clearly part of the initialization. Has to be noted, however, that moving the make_scanner call from the __init__ to the raw_decode methods, despite making less sense, would only be a performance degradation for the default JSONDecover as the rest are only used once.

The forth point would be solved if both the first and the third point are solved, as these methods (c_make_scanner, py_make_scanner, scanstring, JSONObject and JSONArray) would be implementation details and would not be needed by the user, so not exporting them would be the right choice.

So my proposal focuses on fixing the first and third point, keeping in mind that it needs to be backwards compatible:

The process of decoding a JSON string into a Python object can be conceptually divided into two steps, interpretting the characters and then transforming it into the corresponding Python object. The first step is what the scanner is doing with the character matching, the number regex, scanstring, JSONObject and JSONArray. The second step is what parse_int, parse_float, parse_constant, object_hook and object_pairs_hook attributes are for. Dividing this two steps its important as the first one is an implementation detail so it can stay hardcoded (keeping the consistency of both C and Python versions), while the second one is the one where the user is given some hooks to slightly modify its behaviour.

Adding additional hooks for arrays, strings and objects' keys will give the users every customization tool available. This change plus refactoring the first steps to use names that do not get confused with these hooks or parsers will solve all the points described above.

The following files represent an operational version of the json module with these changes applies. encoder.py and tool.py have not been modified.

It has to be taken into account that some C aceletations have been disabled as the C _json module hasn't been modified and thus differ in either operation or method signature with the new version. If these changes seem to get the communities aproval and are thus gonna be applied to the standard library, in addition to the C _json module modifications to adapt to this new version, lines 123 and 311, marked with '# SWAP:' need to be also modified in order to use the C acelerations.

----------
nosy: +Adri?n Orive
Added file: https://bugs.python.org/file47374/scanner.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29992>
_______________________________________

From report at bugs.python.org  Wed Jan 10 08:53:19 2018
From: report at bugs.python.org (Saba Kauser)
Date: Wed, 10 Jan 2018 13:53:19 +0000
Subject: [issue32527] windows 7 python 3.6 : after some security updates,
 import ibm_db fails
Message-ID: <1515592399.24.0.467229070634.issue32527@psf.upfronthosting.co.za>


New submission from Saba Kauser <skauseribmdb at gmail.com>:

Hello,
I have a user who is complaining that python ibm_db module import fails after some windows 7 security update. I am not sure if this is a bug or some other setup issue but I could not find any other forum where I can post this query. Please feel free to point me to correct forum if this is not the correct place.

The error as reported by him is available here : https://github.com/ibmdb/python-ibmdb/issues/294#issuecomment-356254726

When run through pdb, the stack shows this:
C:\Users\IBM_ADMIN\Documents\Python>python -m pdb "test DB2 connection.py"
> c:\users\ibm_admin\documents\python\test db2 connection.py(3)<module>()
-> import ibm_db
(Pdb) continue
Traceback (most recent call last):
  File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1667, in main
    pdb._runscript(mainpyfile)
  File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1548, in _runscript
    self.run(statement)
  File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "c:\users\ibm_admin\documents\python\test db2 connection.py", line 3, in <module>
    import ibm_db
SystemError: <built-in function connect> returned NULL without setting an error
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> c:\users\ibm_admin\documents\python\test db2 connection.py(3)<module>()
-> import ibm_db
(Pdb)

when 'cont' is used, the control reaches python ibm_db driver that should have happened without having to 'cont'.

c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb) cont
Traceback (most recent call last):
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1667, in main
pdb._runscript(mainpyfile)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1548, in _runscript
self.run(statement)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\bdb.py", line 431, in run
exec(cmd, globals, locals)
File "", line 1, in
File "c:\users\ibm_admin\documents\python\test db2 connection.py", line 2, in
import ibm_db
SQLCODE=-30082][CLI Driver] SQL30082N Security processing failed with reason "15" ("PROCESSING FAILURE"). SQLSTATE=08001
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb) cont
Post mortem debugger finished. The test DB2 connection.py will be restarted
c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb) cont
Traceback (most recent call last):
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1667, in main
pdb._runscript(mainpyfile)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1548, in _runscript
self.run(statement)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\bdb.py", line 431, in run
exec(cmd, globals, locals)
File "", line 1, in
File "c:\users\ibm_admin\documents\python\test db2 connection.py", line 2, in
import ibm_db
SQLCODE=-30082][CLI Driver] SQL30082N Security processing failed with reason "15" ("PROCESSING FAILURE"). SQLSTATE=08001
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb)


Please note that the script works fine when run as administrator and it fails only when run as non-admin user. non-admin user too was working fine until recently when some update was applied to windows OS and then it stopped working only for non-admin user. Python and ibm_db driver both have be uninstalled and re-installed for non-admin user, but no luck.
kindly help!

----------
components: Windows
messages: 309764
nosy: paul.moore, sabakauser, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: windows 7 python 3.6 : after some security updates, import ibm_db fails
type: security
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32527>
_______________________________________

From report at bugs.python.org  Wed Jan 10 08:53:47 2018
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Orive?=)
Date: Wed, 10 Jan 2018 13:53:47 +0000
Subject: [issue29992] Expose parse_string in JSONDecoder
In-Reply-To: <1491380525.56.0.628505740968.issue29992@psf.upfronthosting.co.za>
Message-ID: <1515592427.43.0.467229070634.issue29992@psf.upfronthosting.co.za>


Adri?n Orive <aorive at ikerlan.es> added the comment:

Second file

----------
Added file: https://bugs.python.org/file47375/decoder.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29992>
_______________________________________

From report at bugs.python.org  Wed Jan 10 08:54:12 2018
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Orive?=)
Date: Wed, 10 Jan 2018 13:54:12 +0000
Subject: [issue29992] Expose parse_string in JSONDecoder
In-Reply-To: <1491380525.56.0.628505740968.issue29992@psf.upfronthosting.co.za>
Message-ID: <1515592452.34.0.467229070634.issue29992@psf.upfronthosting.co.za>


Adri?n Orive <aorive at ikerlan.es> added the comment:

Third file

----------
Added file: https://bugs.python.org/file47376/__init__.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29992>
_______________________________________

From report at bugs.python.org  Wed Jan 10 08:56:55 2018
From: report at bugs.python.org (TJG)
Date: Wed, 10 Jan 2018 13:56:55 +0000
Subject: [issue32527] windows 7 python 3.6 : after some security updates,
 import ibm_db fails
In-Reply-To: <1515592399.24.0.467229070634.issue32527@psf.upfronthosting.co.za>
Message-ID: <e80b73d7-9e3f-7a6b-019b-c58716ae087c@timgolden.me.uk>


TJG <mail at timgolden.me.uk> added the comment:

The error is coming from the extension module's "connect" function 
(which is the standard DB API entry point for Python database 
interfaces). Presumably from your description, some environmental 
situation leaves it with an unconsidered code path.

This is not apparently a bug in Python; rather in the extension module 
at the Python C API level. Suggest you raise an issue in the ibm_db 
issue tracker.

----------
nosy: +tjguk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32527>
_______________________________________

From report at bugs.python.org  Wed Jan 10 09:00:30 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 10 Jan 2018 14:00:30 +0000
Subject: [issue32007] nis module fails to build against glibc-2.26
In-Reply-To: <1510419983.02.0.213398074469.issue32007@psf.upfronthosting.co.za>
Message-ID: <1515592830.91.0.467229070634.issue32007@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32007>
_______________________________________

From report at bugs.python.org  Wed Jan 10 09:22:08 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Jan 2018 14:22:08 +0000
Subject: [issue32527] windows 7 python 3.6 : after some security updates,
 import ibm_db fails
In-Reply-To: <1515592399.24.0.467229070634.issue32527@psf.upfronthosting.co.za>
Message-ID: <1515594128.07.0.467229070634.issue32527@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

ibm_db is a third-party module. Please contact the authors of the module. The C code of the module has a bug. It's returning NULL without setting an exception with PyExc_*().

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32527>
_______________________________________

From report at bugs.python.org  Wed Jan 10 09:22:25 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Jan 2018 14:22:25 +0000
Subject: [issue32527] windows 7 python 3.6 : after some security updates,
 import ibm_db fails
In-Reply-To: <1515592399.24.0.467229070634.issue32527@psf.upfronthosting.co.za>
Message-ID: <1515594145.1.0.467229070634.issue32527@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32527>
_______________________________________

From report at bugs.python.org  Wed Jan 10 09:25:09 2018
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 10 Jan 2018 14:25:09 +0000
Subject: [issue29137] Fix fpectl-induced ABI breakage
In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za>
Message-ID: <1515594309.04.0.467229070634.issue29137@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

reopening. this patch introduces two new symbols unconditionally, which were not defined for non-pyfpe builds before (PyFPE_counter and PyFPE_jbuf).

----------
nosy: +doko
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29137>
_______________________________________

From report at bugs.python.org  Wed Jan 10 10:46:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Jan 2018 15:46:42 +0000
Subject: [issue7442] _localemodule.c: str2uni() with different LC_NUMERIC and
 LC_CTYPE
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1515599202.62.0.467229070634.issue7442@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I prefer to close the issue and wait until more users ask for it before considering again the patch, or find a different way to implement the feature (support LC_NUMERIC and LC_CTYPE locales using a different encoding).

Here we are: https://bugs.python.org/issue31900

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Wed Jan 10 10:57:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Jan 2018 15:57:19 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1515599839.64.0.467229070634.issue17611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please let's stick with PR 5006.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Wed Jan 10 11:31:15 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 10 Jan 2018 16:31:15 +0000
Subject: [issue32528] Change base class for futures.CancelledError
Message-ID: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

I have discoverd one very ugly pattern connected with asyncio. Many times I see code like this:


try:
    await something()
except Exception:
    log.error('Opertaion failed -- will retry later.')


Seems, everything is fine, but asyncio.CancelledError unintentionally
also suppressed in that code. So, sometimes coroutines are not cancellable.

In order to mitigate thi, we had to write:



try:
    await something()
except CancelledError:
    raise
except Exception:
    log.error('Opertaion failed. will retry later.')


So, what I propose: Basically is to change base class for asyncio.CancelledError
from Exception (yes, I know concurrent.futures and it's `Error` class) to BaseException.

Just like `SystemExit` and other SPECIAL exceptions.

Yes, I know that it would be incompatible change. But I suspect that impact will be minimal. Documentation for concurrent.futures and asyncio does not say that this exception is derived from Exception.

----------
components: asyncio
messages: 309772
nosy: asvetlov, socketpair, yselivanov
priority: normal
severity: normal
status: open
title: Change base class for futures.CancelledError
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 11:31:24 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 10 Jan 2018 16:31:24 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515601884.93.0.467229070634.issue32528@psf.upfronthosting.co.za>


Change by ???? ????????? <socketpair at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 11:33:43 2018
From: report at bugs.python.org (Christoph Zwerschke)
Date: Wed, 10 Jan 2018 16:33:43 +0000
Subject: [issue31140] Insufficient error message with incorrect formated
 string literal
In-Reply-To: <1502182558.08.0.700048111188.issue31140@psf.upfronthosting.co.za>
Message-ID: <1515602023.88.0.467229070634.issue31140@psf.upfronthosting.co.za>


Christoph Zwerschke <cito at online.de> added the comment:

I can confirm that the problem still exists in Python 3.6.4 and 3.7.0a4.

Here is another way to demonstrate it:

Create the following file test.py:

    # test
    hello = f"{world)}"

Note that there is a syntax error in the f-string in line 2 which has a closing parentheses, but no opening one.

Import this from Python 3.6.4 or 3.7.0a4:

>>> import test
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<fstring>", line 1
    (world))
           ^
SyntaxError: unexpected EOF while parsing

The problem here is that the error message does not contain the name of the erroneous file (test.py), points to a wrong line (line 1 instead of line 2), and also shows parentheses instead of braces around the word "world", which are not there in the original code. This can make it hard to locate such errors.

Note that when there are other kinds of errors in the f-string, or other kinds of "unexpected EOF" in the imported file, the errorenous file is usually reported correctly in the error message. Only certain kinds of syntax errors in f-strings seem to be problematic.

----------
nosy: +cito

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31140>
_______________________________________

From report at bugs.python.org  Wed Jan 10 11:37:14 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 10 Jan 2018 16:37:14 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515602234.29.0.467229070634.issue32528@psf.upfronthosting.co.za>


Change by ???? ????????? <socketpair at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 11:59:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Jan 2018 16:59:11 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1515603551.78.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I completed my change. It now fixes locale.localeconv(), str.format() for int, float, complex and decimal.Decimal:

vstinner at apu$ ./python lc_numeric.py 
LC_CTYPE: ('fr_FR', 'ISO8859-1')
LC_NUMERIC: ('es_MX', 'UTF-8')
decimal_point: '.'
thousands_sep: '\u2009'
grouping: [3, 3, 0]
int.__format__: '1\u2009234'
float.__format__: '1\u2009234'
complex.__format__: '1\u2009234+0j'
Decimal.__format__: '1\u2009234'

----------
Added file: https://bugs.python.org/file47377/lc_numeric.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Wed Jan 10 12:13:21 2018
From: report at bugs.python.org (Ivan Pozdeev)
Date: Wed, 10 Jan 2018 17:13:21 +0000
Subject: [issue22552] ctypes.CDLL returns singleton objects,
 resulting in usage conflicts
In-Reply-To: <1412387689.66.0.814406977046.issue22552@psf.upfronthosting.co.za>
Message-ID: <1515604401.98.0.467229070634.issue22552@psf.upfronthosting.co.za>


Change by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22552>
_______________________________________

From report at bugs.python.org  Wed Jan 10 12:59:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Jan 2018 17:59:22 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1515607162.86.0.467229070634.issue29240@psf.upfronthosting.co.za>


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


----------
pull_requests: +5003

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Wed Jan 10 13:27:31 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 10 Jan 2018 18:27:31 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515608851.97.0.467229070634.issue32528@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This is a backwards incompatible change.  IMO it's too late to change this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 13:35:07 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 10 Jan 2018 18:35:07 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515609307.61.0.467229070634.issue32528@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Will you accept PR if I fix that ?

I think we may merge that in Python 3.8

Who can also judge us? @asvetlov, what do you think about my idea ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 13:43:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 10 Jan 2018 18:43:49 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515609829.3.0.467229070634.issue32528@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

While I understand the reasons for the proposed change, I'd still be -1 for it. Solely on the basis of "we don't know how much this change will break, but it will surely break something in very subtle ways".

Another problem is that asyncio currently doesn't handle BaseExceptions that well.

I'll put Guido in the nosy list, maybe he'll have a different opinion on this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 13:58:46 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jan 2018 18:58:46 +0000
Subject: [issue32525] Empty tuples are not optimized as constant expressions
In-Reply-To: <1515534553.56.0.467229070634.issue32525@psf.upfronthosting.co.za>
Message-ID: <1515610726.81.0.467229070634.issue32525@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This looks like it was already fixed in Python 3.7:

$ ./python.exe
Python 3.7.0a3+ (heads/master:7f7de371f9, Jan  6 2018, 21:35:03)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from dis import dis
>>> def f():
...   x = ()
...   y = 2, 4
...
>>> dis(f)
  2           0 LOAD_CONST               1 (())
              2 STORE_FAST               0 (x)

  3           4 LOAD_CONST               2 ((2, 4))
              6 STORE_FAST               1 (y)
              8 LOAD_CONST               0 (None)
             10 RETURN_VALUE

----------
nosy: +rhettinger
resolution:  -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32525>
_______________________________________

From report at bugs.python.org  Wed Jan 10 14:15:33 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Jan 2018 19:15:33 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515609829.3.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLG5_8nCmjij1RPFLrtkaXQ4RUtGSGEJ74xckCKMitqVA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I agree with Yury, this feels too risky to consider. The "except Exception:
<log>" code is at fault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 14:19:42 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 10 Jan 2018 19:19:42 +0000
Subject: [issue29137] Fix fpectl-induced ABI breakage
In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za>
Message-ID: <1515611982.3.0.467229070634.issue29137@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Yes, they're intentionally retained as no-ops, so that it remains possible to load old extensions that were compiled against an fpe build and refer to those symbols. Is there a problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29137>
_______________________________________

From report at bugs.python.org  Wed Jan 10 15:05:46 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Jan 2018 20:05:46 +0000
Subject: [issue32525] Empty tuples are not optimized as constant expressions
In-Reply-To: <1515534553.56.0.467229070634.issue32525@psf.upfronthosting.co.za>
Message-ID: <1515614746.45.0.467229070634.issue32525@psf.upfronthosting.co.za>


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


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32525>
_______________________________________

From report at bugs.python.org  Wed Jan 10 16:04:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Jan 2018 21:04:28 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1515618268.02.0.467229070634.issue17611@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -4951

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Wed Jan 10 16:20:40 2018
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 10 Jan 2018 21:20:40 +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: <1515619240.33.0.467229070634.issue9325@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Thanks Nick. I've sent patches for all of them but `dis`.

`dis` does not "run" the code.
Adding the -m option is basically identical to just running it on the __main__.py if the module is runnable or on the __init__ if it is not.

If you think there is still value on that, I am happy to send a PR for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Wed Jan 10 16:46:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Jan 2018 21:46:18 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1515620778.11.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 2cba6b85797ba60d67389126f184aad5c9e02ff3 by Victor Stinner in branch 'master':
bpo-29240: readline now ignores the UTF-8 Mode (#5145)
https://github.com/python/cpython/commit/2cba6b85797ba60d67389126f184aad5c9e02ff3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Wed Jan 10 17:05:09 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 10 Jan 2018 22:05:09 +0000
Subject: [issue32526] Closing async generator while it is running does not
 raise an exception
In-Reply-To: <1515577162.33.0.467229070634.issue32526@psf.upfronthosting.co.za>
Message-ID: <1515621909.73.0.467229070634.issue32526@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

It looks like Python's tracking the "running" state of async generators wrong: we should have ag_running set to True when we enter asend/athrow/aclose and False when we exit, but instead it's being toggled back and forth on each *inner* send/throw on the individual coroutines.

Here's a minimal reproducer (using some random recent checkout of master):

>>> async def f():
...     await asyncio.sleep(1)
...     yield
... 
>>> ag = f()
>>> asend_coro = ag.asend(None)
>>> fut = asend_coro.send(None)
# Logically, ag.asend is still running, waiting for that sleep to
# finish, but we have lost track:
>>> ag.ag_running
False
# We can start another call to asend() going simultaneously
>>> fut.set_result(None)
>>> send_coro2 = ag.asend(None)
>>> send_coro2.send(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

It looks like async_generator did handle this case correctly, but didn't have a test case. I just added one: https://github.com/njsmith/async_generator/commit/339fc6309aa6c96244e79b517db0b98ba0ccfb2a

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32526>
_______________________________________

From report at bugs.python.org  Wed Jan 10 17:11:02 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 10 Jan 2018 22:11:02 +0000
Subject: [issue32529] improved shutil.py function
Message-ID: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

improved "copyfileobj" function to use less memory

----------
messages: 309784
nosy: YoSTEALTH
priority: normal
pull_requests: 5004
severity: normal
status: open
title: improved shutil.py function
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Wed Jan 10 17:22:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Jan 2018 22:22:15 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1515622935.98.0.467229070634.issue29240@psf.upfronthosting.co.za>


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


----------
pull_requests: +5005

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Wed Jan 10 18:52:52 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 10 Jan 2018 23:52:52 +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: <1515628372.11.0.467229070634.issue9325@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While I do think it makes sense to enhance `dis` in this regard, I'm also thinking it might be better to have that automatically fall back to a `python -m inspect module:qualname` style lookup in the event that `os.path.exists(infile)` is false.

So considering it out of scope for *this* issue makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Wed Jan 10 19:02:56 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 11 Jan 2018 00:02:56 +0000
Subject: [issue32004] Allow specifying code packing order in audioop adpcm
 functions
In-Reply-To: <1510357207.47.0.213398074469.issue32004@psf.upfronthosting.co.za>
Message-ID: <1515628976.05.0.467229070634.issue32004@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Adjusting target versions, as even though the status quo leads to mishandling some input data, the fix is a feature request to make the behaviour configurable, which restricts the change to 3.7+.

----------
nosy: +ncoghlan
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32004>
_______________________________________

From report at bugs.python.org  Wed Jan 10 19:33:03 2018
From: report at bugs.python.org (bbayles)
Date: Thu, 11 Jan 2018 00:33:03 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515630783.62.0.467229070634.issue32248@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
pull_requests: +5006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 10 19:58:03 2018
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Jan 2018 00:58:03 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515632283.8.0.467229070634.issue32529@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Looks like you want to use a "readinto" method to reduce data copying.

One problem is that it is not specified exactly what kind of object "copyfileobj" supports reading from. The documentation only says "file-like". According to the glossary, this means io.RawIOBase, BufferedIOBase, or TextIOBase. However TextIOBase doesn't have a "readinto" method. And it wouldn't be hard to find that someone has written their own class that doesn't have "readinto" either.

The other problem is you still need to support a negative "length" value, which is easier to do by calling "read".

----------
nosy: +martin.panter
title: improved shutil.py function -> Call readinto in shutil.copyfileobj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Wed Jan 10 20:59:27 2018
From: report at bugs.python.org (Daniel)
Date: Thu, 11 Jan 2018 01:59:27 +0000
Subject: [issue13214] Cmd: list available completions from the cmd.Cmd
 subclass and filter out EOF handler(s)
In-Reply-To: <1318965366.62.0.48247525728.issue13214@psf.upfronthosting.co.za>
Message-ID: <1515635967.73.0.467229070634.issue13214@psf.upfronthosting.co.za>


Daniel <dbkats at gmail.com> added the comment:

If you write a handler for EOF like so:

from cmd import Cmd

class FooShell(Cmd):
	def do_EOF(self, args):
		# exit on EOF
		raise SystemExit()

shell = FooShell()
shell.cmdloop()

Then when running the shell, you can see "EOF" as an undocumented command in the help screen. You can see this when typing "?".

$ python fooshell.py
(Cmd) ?

Documented commands (type help <topic>):
========================================
help

Undocumented commands:
======================
EOF

I believe the correct behaviour should be (1) don't show it in the undocumented commands, since it's not really a command; and (2) maybe create a built-in command for this, since the literal string "EOF" is also caught by this handler.

----------
nosy: +boompig
versions: +Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Wed Jan 10 23:30:44 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 11 Jan 2018 04:30:44 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515645044.23.0.467229070634.issue32248@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@bbayles: I don't think PR 5149 is related to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 10 23:30:52 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 11 Jan 2018 04:30:52 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515645052.97.0.467229070634.issue32248@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
pull_requests:  -5006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 10 23:42:02 2018
From: report at bugs.python.org (Hery)
Date: Thu, 11 Jan 2018 04:42:02 +0000
Subject: [issue32530] How ro fix the chm encoding in Non western european
 codepage(cp1252) Windows
Message-ID: <1515645722.61.0.467229070634.issue32530@psf.upfronthosting.co.za>


New submission from Hery <weiyong.mao at gmail.com>:

Start from Python 3.6.3, the offical chm document is full of corrputed character.

Example: the first page which is `What?s New In Python 3.6` `?`is `0x92` in cp1252 and will not display correctly in non western european code page.  An another example is `9.1. numbers ? Numeric abstract base classes` `?` is `0x97`.

The Microsoft HTML Help does not recognise `<meta http-equiv="Content-Type" content="text/html; charset=cp1252" />`.

Then, how to solve it?

According to this https://blogs.msdn.microsoft.com/sandcastle/2007/09/29/chm-localization-and-unicode-issues-dbcsfix-exe/

I recommand to use the following command to make the hhc encoding chm as cp1252:

SbAppLocale.exe $(LCID) "%PROGRAMFILES%\HTML Help Workshop\hhc.exe" Path\Project.HHp

I donnot know to how to submit patch and it seems quite easy to fix by offical windows developer.

----------
components: Windows
messages: 309790
nosy: Nim, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: How ro fix the chm encoding in Non western european codepage(cp1252) Windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32530>
_______________________________________

From report at bugs.python.org  Thu Jan 11 00:24:06 2018
From: report at bugs.python.org (callmekohei)
Date: Thu, 11 Jan 2018 05:24:06 +0000
Subject: [issue32531] gdb.execute can not put string value.
Message-ID: <1515648246.66.0.467229070634.issue32531@psf.upfronthosting.co.za>


New submission from callmekohei <callmekohei at gmail.com>:

Hello! I'm callmekohei! (^_^)/


------------------------
   Problems summary
------------------------

gdb.execute can not put string value.


------------------------
   Steps to Reproduce
------------------------

// create 
$ gcc -g foo.c

// launch sdb
$ sdb a.out

// set breakpoint
$ b foo.c:5

// run
$ run

// next
$ n


------------------------
   Current Behavior
------------------------

(gdb)  n
6	    n = 2;
False
True


------------------------
   Expected Behavior
------------------------

(gdb)  n
False
False


------------------------
   Code 
------------------------

// .gdbinit

set startup-with-shell off

python

class Foo(gdb.Command):

    def __init__(self):
        gdb.Command.__init__(self                     \
                , name            = 'n'               \
                , command_class   = gdb.COMMAND_USER  \
                , completer_class = gdb.COMPLETE_NONE \
                , prefix          = True)

    def invoke(self, arg, from_tty):
        output = gdb.execute(command='next',from_tty=False, to_string=True)
        print(output is None)
        print(output == '')

Foo()

end


// foo.c

#include <stdio.h>

int main(int argc, char *args[])
{
    int n = 1;
    n = 2;
    n = 3;
    n = 4;
    n = 5;
    n = 6;
    n = 7;
    n = 8;
    n = 9;
    printf("n = %d\n",n);
    return 0;
}


------------------------
   Others 
------------------------

see also:

https://github.com/mono/sdb/issues/45

----------
components: macOS
hgrepos: 377
messages: 309791
nosy: callmekohei, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: gdb.execute can not put string value.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32531>
_______________________________________

From report at bugs.python.org  Thu Jan 11 00:45:21 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Jan 2018 05:45:21 +0000
Subject: [issue32320] Add default value support to collections.namedtuple()
In-Reply-To: <1513241075.07.0.213398074469.issue32320@psf.upfronthosting.co.za>
Message-ID: <1515649521.93.0.467229070634.issue32320@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 3948207c610e931831828d33aaef258185df31db by Raymond Hettinger in branch 'master':
bpo-32320: Add default value support to collections.namedtuple() (#4859)
https://github.com/python/cpython/commit/3948207c610e931831828d33aaef258185df31db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32320>
_______________________________________

From report at bugs.python.org  Thu Jan 11 00:45:59 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Jan 2018 05:45:59 +0000
Subject: [issue32320] Add default value support to collections.namedtuple()
In-Reply-To: <1513241075.07.0.213398074469.issue32320@psf.upfronthosting.co.za>
Message-ID: <1515649559.94.0.467229070634.issue32320@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32320>
_______________________________________

From report at bugs.python.org  Thu Jan 11 01:25:56 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 11 Jan 2018 06:25:56 +0000
Subject: [issue32532] improve sys.settrace and sys.setprofile documentation
Message-ID: <1515651956.68.0.467229070634.issue32532@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

I propose to mention the behaviour that "if exception raised in tracefunc or profilefunc, the handler will be unset" in the documentation of sys.settrace and sys.setprofile. I encounter this behaviour and surprised by it since I can't get the info from the doc. Only by digging into the source code, I can find out why the profile messages suddenly disappear.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 309793
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: needs patch
status: open
title: improve sys.settrace and sys.setprofile documentation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32532>
_______________________________________

From report at bugs.python.org  Thu Jan 11 03:14:43 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 11 Jan 2018 08:14:43 +0000
Subject: [issue30782] Allow limiting the number of concurrent tasks in
 asyncio.as_completed
In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za>
Message-ID: <1515658483.42.0.467229070634.issue30782@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Third parties are not python core devs responsibility.

I don't aware about existing library with such functionality.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30782>
_______________________________________

From report at bugs.python.org  Thu Jan 11 03:35:05 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Jan 2018 08:35:05 +0000
Subject: [issue32467] dict_values isn't considered a Collection nor a Container
In-Reply-To: <1514734584.09.0.467229070634.issue32467@psf.upfronthosting.co.za>
Message-ID: <1515659705.79.0.467229070634.issue32467@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It would be okay to let ValuesView inherit from Collection.

Am marking this a 3.7 only because it isn't important to anyone's actual code and there is no known use case.  Technically, it isn't even a bug.  The __contains__ method is supported implicitly (as it is for many classes that just define __iter__), so there is no requirement that this be recognized as a Collection.  Also, the existing behavior was explicitly tested (see line 848 in Lib/test/test_collections).

I'm going forward with this because it does offer a sense of neatness (in comparison to KeysView and ItemsView) and it might avoid a pedantic StackOverflow question somewhere down the line.

----------
assignee:  -> rhettinger
components: +Library (Lib)
nosy: +rhettinger
priority: normal -> low
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32467>
_______________________________________

From report at bugs.python.org  Thu Jan 11 03:37:01 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Jan 2018 08:37:01 +0000
Subject: [issue32467] dict_values isn't considered a Collection nor a Container
In-Reply-To: <1514734584.09.0.467229070634.issue32467@psf.upfronthosting.co.za>
Message-ID: <1515659821.87.0.467229070634.issue32467@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5007
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32467>
_______________________________________

From report at bugs.python.org  Thu Jan 11 03:50:41 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Jan 2018 08:50:41 +0000
Subject: [issue31145] PriorityQueue.put() fails with TypeError if
 priority_number in tuples of (priority_number, data) are the same.
In-Reply-To: <1502201353.41.0.0622825133632.issue31145@psf.upfronthosting.co.za>
Message-ID: <1515660641.19.0.467229070634.issue31145@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5008
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31145>
_______________________________________

From report at bugs.python.org  Thu Jan 11 03:52:28 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 11 Jan 2018 08:52:28 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515660748.46.0.467229070634.issue32528@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

@gvanrossum

More real code:

async def xxxx():
    while True:
        try:
            result = await download()
            handle_result(result)
        except Exception as e:
            log.warning('Fail..%r', e)
        await asyncio.sleep()


Why sucha a code is fault ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Thu Jan 11 03:55:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Jan 2018 08:55:31 +0000
Subject: [issue13214] Cmd: list available completions from the cmd.Cmd
 subclass and filter out EOF handler(s)
In-Reply-To: <1318965366.62.0.48247525728.issue13214@psf.upfronthosting.co.za>
Message-ID: <1515660931.35.0.467229070634.issue13214@psf.upfronthosting.co.za>


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


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Thu Jan 11 04:10:45 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 11 Jan 2018 09:10:45 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1515661845.04.0.467229070634.issue17799@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Is there any reason not to respond to "c_call" events in trace function?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Thu Jan 11 04:12:45 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 11 Jan 2018 09:12:45 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1515661965.41.0.467229070634.issue17799@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Thu Jan 11 04:38:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Jan 2018 09:38:07 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1515663487.25.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset cb3ae5588bd7733e76dc09277bb7626652d9bb64 by Victor Stinner in branch 'master':
bpo-29240: Ignore UTF-8 Mode in time module (#5148)
https://github.com/python/cpython/commit/cb3ae5588bd7733e76dc09277bb7626652d9bb64


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Thu Jan 11 04:43:18 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 11 Jan 2018 09:43:18 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515663798.59.0.467229070634.issue32528@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Inheritance from Exception is very annoying, I saw issues with unexpected suppressing CancelledError many times.

Even experienced people constantly forget to add a separate `except asyncio.CancelledError` clause everywhere.

But proposed change is backward incompatible, sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Thu Jan 11 04:48:19 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 11 Jan 2018 09:48:19 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515664099.87.0.467229070634.issue32528@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Honestly I have no strong opinion.

Correct code should not be affected, if somebody want to handle task cancellation explicitly -- he already have `except CancelledError` in his code.

What are use cases for intentional catching Exception for task cancellation prevention?

Could we add a warning for this case without base exception class change? I don't see how to do it but maybe somebody has an idea?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Thu Jan 11 06:03:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 11:03:28 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515668608.17.0.467229070634.issue31993@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0a2da50e1867831251fad75377d0f10713eb6301 by Serhiy Storchaka in branch 'master':
bpo-31993: Do not create frames for large bytes and str objects (#5114)
https://github.com/python/cpython/commit/0a2da50e1867831251fad75377d0f10713eb6301


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Thu Jan 11 06:13:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 11:13:02 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515669182.17.0.467229070634.issue31993@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5009

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Thu Jan 11 06:14:27 2018
From: report at bugs.python.org (Cosimo Lupo)
Date: Thu, 11 Jan 2018 11:14:27 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
 local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1515669267.68.0.467229070634.issue17128@psf.upfronthosting.co.za>


Cosimo Lupo <clupo at google.com> added the comment:

Hello,

I see that the official Python.org OSX 10.6+ installers are still linking with OSX outdated OpenSSL (0.9.8zh 14 Jan 2016; I'm using macOS High Sierra 10.13.2).

In the installer's README, they motivates this because:

> Apple's 0.9.8 version includes an important additional feature: if a certificate cannot be verified using the manually administered certificates in /System/Library/OpenSSL, the certificates managed by the system security framework in the user and system keychains are also consulted (using Apple private APIs)

However, because of this outdated OpenSSL version, I cannot use pip to install from the TestPyPI server https://test.pypi.org.

When I try (even with --trusted-host) I get this error:

```
$ pip install --trusted-host --index-url https://test.pypi.org/simple afdko
Collecting https://test.pypi.org/simple
Exception:
Traceback (most recent call last):
...
SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:661)
```

A similar issue on pypa/pip repository was closed as

> There's no actionable item here. People with old versions of openssl that don't support sha1 SSL certificates need to upgrade or else they are insecure. If they wish to be insecure they can continue using pip 1.2

https://github.com/pypa/pip/issues/829#issuecomment-20931050

~~~

Well, I find it particularly odd that the official binary distribution for the latest Python 2.7.14 has a broken (or insecure) _ssl module, even when running the latest macOS version.

Of course, using pyenv or homebrew fixes the problem (as they require and link with the latest openssl 1.0.2), but I would like to recommend installing python from the official binaries to my less technically-skilled colleagues of mine.

Please consider embedding the latest openssl on the 10.6+ installers like you already do on 10.5 32bit ones and the Windows ones, thank you.

Cosimo Lupo

----------
nosy: +Cosimo Lupo2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17128>
_______________________________________

From report at bugs.python.org  Thu Jan 11 06:26:57 2018
From: report at bugs.python.org (Bartek Banachewicz)
Date: Thu, 11 Jan 2018 11:26:57 +0000
Subject: [issue28429] ctypes fails to import with grsecurity's TPE
In-Reply-To: <1476360738.57.0.800770600157.issue28429@psf.upfronthosting.co.za>
Message-ID: <1515670017.12.0.467229070634.issue28429@psf.upfronthosting.co.za>


Change by Bartek Banachewicz <bananu7 at o2.pl>:


----------
keywords: +patch
pull_requests: +5010
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28429>
_______________________________________

From report at bugs.python.org  Thu Jan 11 07:17:11 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 11 Jan 2018 12:17:11 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515673031.76.0.467229070634.issue32529@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

Martin, your points got me thinking... to make a proper copy of a file, it should be done using bytes! Text IO could easily lead to corrupting your file.

for example (current function):
    with open(old_path, 'r', encoding='latin-1') as fsrc:
        with open(new_path, 'w') as fdst:
            copyfileobj(fsrc, fdst)

This would lead you to have wrongly encoded file with different filesize.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 07:48:00 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 11 Jan 2018 12:48:00 +0000
Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and
 later)
In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za>
Message-ID: <1515674880.01.0.467229070634.issue27435@psf.upfronthosting.co.za>


Change by Michael Felt <michael at felt.demon.nl>:


----------
pull_requests: +5012
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27435>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:18:01 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 11 Jan 2018 13:18:01 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515676681.19.0.467229070634.issue32529@psf.upfronthosting.co.za>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


----------
keywords: +patch
pull_requests: +5013
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:26:06 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 11 Jan 2018 13:26:06 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515677166.52.0.467229070634.issue32529@psf.upfronthosting.co.za>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


----------
pull_requests:  -5004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:32:15 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 11 Jan 2018 13:32:15 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515677535.4.0.467229070634.issue32529@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

Ok, updated the patch to account for:
- improved memory usage for bytes io using readinto
- still supporting negative length
- potential encoding mismatch bug fix while using text io

did i miss anything?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:41:08 2018
From: report at bugs.python.org (Alexey Baldin)
Date: Thu, 11 Jan 2018 13:41:08 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
Message-ID: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>


New submission from Alexey Baldin <alexeyb17 at gmail.com>:

_ssl.c has thread-usafe code in implementation of read, write and other methods. E.g. 'write' method:

2099        PySSL_BEGIN_ALLOW_THREADS
2100        len = SSL_write(self->ssl, b->buf, (int)b->len);
2101        _PySSL_UPDATE_ERRNO_IF(len <= 0, self, len);
2102        PySSL_END_ALLOW_THREADS
2103        err = self->ssl_errno;

_PySSL_UPDATE_ERRNO_IF updates self->ssl_errno without lock. Similar code used in 'read' method. Later self->ssl_errno is used for decision on retrying the operation. As result, SSL_write can be incorrectly repeated because ssl_errno was updated by 'read' method to SSL_ERROR_WANT_READ from another thread.

Looks like commit e6eb48c10dc389d1d70657593de6a6cb3087d3d1 is the cause.

----------
assignee: christian.heimes
components: SSL
messages: 309805
nosy: Alexey Baldin, christian.heimes
priority: normal
severity: normal
status: open
title: SSLSocket read/write thread-unsafety
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:42:36 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 11 Jan 2018 13:42:36 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515678156.94.0.467229070634.issue32529@psf.upfronthosting.co.za>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


----------
pull_requests: +5014

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:43:22 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Jan 2018 13:43:22 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1515678202.71.0.467229070634.issue32533@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:51:15 2018
From: report at bugs.python.org (bbayles)
Date: Thu, 11 Jan 2018 13:51:15 +0000
Subject: [issue32102] Add "capture_output=True" option to subprocess.run
In-Reply-To: <1511244827.04.0.213398074469.issue32102@psf.upfronthosting.co.za>
Message-ID: <1515678675.46.0.467229070634.issue32102@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
keywords: +patch
pull_requests: +5015
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32102>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:51:15 2018
From: report at bugs.python.org (bbayles)
Date: Thu, 11 Jan 2018 13:51:15 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515678675.54.0.574204596225.issue32248@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
pull_requests: +5016

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:52:14 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Thu, 11 Jan 2018 13:52:14 +0000
Subject: [issue32534] Speed-up list.insert
Message-ID: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>


New submission from Jeethu Rao <jeethu at jeethurao.com>:

I've noticed that replacing the for loop in the ins1 function in listobject.c with a memmove when the number of pointers to move is greater than 16 seems to speed up list.insert by about 3 to 4x on a contrived benchmark.

# Before
jeethu at dev:cpython  (master)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
200 loops, best of 5: 3.07 msec per loop

#After
jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
500 loops, best of 5: 744 usec per loop

Both builds were configured with --enable-optimizations and --with-lto

----------
components: Interpreter Core
messages: 309806
nosy: jeethu
priority: normal
severity: normal
status: open
title: Speed-up list.insert
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:57:48 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Thu, 11 Jan 2018 13:57:48 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1515679068.99.0.467229070634.issue32534@psf.upfronthosting.co.za>


Change by Jeethu Rao <jeethu at jeethurao.com>:


----------
keywords: +patch
pull_requests: +5017
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Thu Jan 11 09:02:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 14:02:58 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515679378.88.0.467229070634.issue32529@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please provide benchmark results to demonstrate the benefits of this change.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 09:16:50 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Jan 2018 14:16:50 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515680210.46.0.467229070634.issue32529@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I already blocked the PR with a request for benchmarks and proper tests.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 09:17:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 14:17:29 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1515680249.51.0.467229070634.issue32534@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What are results when set the threshold to 0 or 1?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Thu Jan 11 09:40:00 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Thu, 11 Jan 2018 14:40:00 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1515681600.47.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

I tried it with a couple of different thresholds, twice each, ignoring the results of the first run. 16 seems to be the sweet spot.

THRESHOLD = 0
jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
500 loops, best of 5: 787 usec per loop

THRESHOLD = 4
jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
500 loops, best of 5: 781 usec per loop

THRESHOLD = 8
jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
500 loops, best of 5: 780 usec per loop

THRESHOLD = 16
jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
500 loops, best of 5: 758 usec per loop

THRESHOLD = 32
jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
500 loops, best of 5: 764 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Thu Jan 11 09:57:58 2018
From: report at bugs.python.org (Sebastian Bank)
Date: Thu, 11 Jan 2018 14:57:58 +0000
Subject: [issue15927] csv.reader() does not support escaped newline when
 quoting=csv.QUOTE_NONE
In-Reply-To: <1347425390.54.0.862014726204.issue15927@psf.upfronthosting.co.za>
Message-ID: <1515682678.27.0.467229070634.issue15927@psf.upfronthosting.co.za>


Sebastian Bank <sebastian.bank at uni-leipzig.de> added the comment:

I am not sure about the design vs. code bug distinction, but what makes me think this should be fixed is primarily the broken round-trip (already mentioned above): 

>>> import io, csv
>>> def roundtrip(value, **fmtparams):
        with io.BytesIO() as f:
             csv.writer(f, **fmtparams).writerow([value])
             f.seek(0)
             return next(csv.reader(f, **fmtparams))
>>> roundtrip('spam\neggs', quoting=csv.QUOTE_NONE, escapechar='\\')
['spam\n']

Furthermore, there is the inconsistency between Python 2 and 3, now that this has been fixed in 3.4.

I agree that the documentation of Dialect.escapechar is not in line with the code (in both Python 2 and Python 3): How about changing it to something along the following lines (TODO: reformulate according to how exactly Dialect.lineterminator affects this)?

"to escape the delimiter, \r, \n, and the quotechar if quoting is set to QUOTE_NONE
and the quotechar for all other quoting styles if doublequote is False":

>>> def write_csv(value, **fmtparams):
        with io.BytesIO() as f:
            csv.writer(f, **fmtparams).writerow([value])
            return f.getvalue()
>>> write_csv('spam\reggs', quoting=csv.QUOTE_NONE, escapechar='\\')
'spam\\\reggs\r\n'
>>> write_csv('spam\neggs', quoting=csv.QUOTE_NONE, escapechar='\\')
'spam\\\neggs\r\n'
>>> write_csv('spam"eggs', quoting=csv.QUOTE_NONE, escapechar='\\')
'spam\\"eggs\r\n'
>>> write_csv('spam"eggs', quoting=csv.QUOTE_NONE, quotechar=None, escapechar='\\')
'spam"eggs\r\n'
>>> write_csv('spam"eggs', escapechar='\\', doublequote=False)
'spam\\"eggs\r\n'

> In any case, 'one\nelement' and 'one\\\nelement' are each 2 physical lines. 
> I don't see anything in the doc about csv.reader joining physical lines
> into 'logical' lines the way that compile() does.

How about the following?

"csvreader.line_num

    The number of lines read from the source iterator. This is not the same as the number of records returned, as records can span multiple lines."

"On reading, the escapechar removes any special meaning from the following character."

>>> write_csv('spam\neggs', quoting=csv.QUOTE_NONE)  # with delimiter, \r, \n, and quotechar
Traceback (most recent call last):
...
Error: need to escape, but no escapechar set

>>> roundtrip('spam\neggs')
['spam\neggs']

>>> write_csv('spam\neggs')
'"spam\neggs"\r\n'

----------
nosy: +xflr6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15927>
_______________________________________

From report at bugs.python.org  Thu Jan 11 09:59:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 14:59:24 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1515682764.41.0.467229070634.issue32534@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In your benchmarks the difference between thresholds is only 4%. It would be not worth to keep a special case for such small benefit.

But note that in your benchmarks you inserted in a list with the size up to 50000 elements. The value of the threshold affects only the first few insertions. Your need to test inserting in short lists. Recreate a list at every iteration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Thu Jan 11 10:04:14 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Thu, 11 Jan 2018 15:04:14 +0000
Subject: [issue32467] dict_values isn't considered a Collection nor a Container
In-Reply-To: <1514734584.09.0.467229070634.issue32467@psf.upfronthosting.co.za>
Message-ID: <1515683054.02.0.467229070634.issue32467@psf.upfronthosting.co.za>


Yahya Abou Imran <yahya-abou-imran at protonmail.com> added the comment:

Perfect for me.
I was about to submit about the same patch as yours after your acceptation; but it's better that way, it's your module!
Thanks Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32467>
_______________________________________

From report at bugs.python.org  Thu Jan 11 10:16:59 2018
From: report at bugs.python.org (Sebastian Bank)
Date: Thu, 11 Jan 2018 15:16:59 +0000
Subject: [issue31590] CSV module incorrectly treats escaped newlines as new
 records if unquoted
In-Reply-To: <1506418099.9.0.80881309729.issue31590@psf.upfronthosting.co.za>
Message-ID: <1515683819.85.0.467229070634.issue31590@psf.upfronthosting.co.za>


Sebastian Bank <sebastian.bank at uni-leipzig.de> added the comment:

https://bugs.python.org/issue15927#msg309811 gives sme code examples illustrating why I think this should be backported (and also the documentation should be changed for both Python 2 and 3).

----------
nosy: +xflr6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31590>
_______________________________________

From report at bugs.python.org  Thu Jan 11 11:27:51 2018
From: report at bugs.python.org (Sebastian Bank)
Date: Thu, 11 Jan 2018 16:27:51 +0000
Subject: [issue12178] csv writer doesn't escape escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1515688071.74.0.467229070634.issue12178@psf.upfronthosting.co.za>


Sebastian Bank <sebastian.bank at uni-leipzig.de> added the comment:

Hi, is there something we can do to get this going? As the issue breaks round-trip, it currently requires work-arounds like this: https://github.com/cldf/csvw/blob/1324550266c821ef32d1e79c124191e93aefbfa8/csvw/dsv.py#L67-L71

----------
nosy: +xflr6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12178>
_______________________________________

From report at bugs.python.org  Thu Jan 11 11:34:33 2018
From: report at bugs.python.org (Bruno Abreu Calfa)
Date: Thu, 11 Jan 2018 16:34:33 +0000
Subject: [issue32535] msvcr140.dll has been replaced with vcruntime140.dll
Message-ID: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>


New submission from Bruno Abreu Calfa <bacalfa at gmail.com>:

File msvcr140.dll does not exist after installing Microsoft Visual C++ 2015 Redistributable or Visual Studio 2015. It has been replaced with vcruntime140.dll. See discussion here: https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/yLH46ilPQeo

In addition, I was only able to build an extension (https://github.com/mattjj/pyhsmm) after copying the vcruntime140.dll from the Python installation folder (Anaconda 3 5.0.1 64-bit, Python 3.6.3) to the libs folder. I also had to change file include/pyconfig.h by removing the definitions of hypot (https://github.com/python/cpython/pull/880).

In sum, I suggest replacing

return ['msvcr140']

with

return ['vcruntime140']

----------
components: Distutils
messages: 309816
nosy: Bruno Abreu Calfa, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: msvcr140.dll has been replaced with vcruntime140.dll
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Thu Jan 11 12:34:52 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Jan 2018 17:34:52 +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: <1515692092.64.0.467229070634.issue9325@psf.upfronthosting.co.za>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
assignee: belopolsky -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Thu Jan 11 12:36:26 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 11 Jan 2018 17:36:26 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1515692186.46.0.467229070634.issue32529@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

here is the links to benchmark:
    https://repl.it/@altendky/timeit-of-proposed-shutilfileobjcopy
    https://gist.github.com/altendky/ff5ccee2baf9822dce69ae8aa66a0fdf
    https://paste.pound-python.org/show/urORPXztcbDlqXKTORAj/  # time ./file.py

the problem is the result times are so sparitic that not sure what to post as the result! I have tried with actual file as well and the results are all over the place.

If any of you out there are can do benchmark that can produce accurate results and post the result it would help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Thu Jan 11 13:20:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 18:20:19 +0000
Subject: [issue31113] Stack overflow with large program
In-Reply-To: <1501747851.67.0.0193426592051.issue31113@psf.upfronthosting.co.za>
Message-ID: <1515694819.8.0.467229070634.issue31113@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 782d6fe4434381c50e0c7ec94a1ef9c6debbc333 by Serhiy Storchaka in branch 'master':
bpo-31113: Get rid of recursion in the compiler for normal control flow. (#3015)
https://github.com/python/cpython/commit/782d6fe4434381c50e0c7ec94a1ef9c6debbc333


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31113>
_______________________________________

From report at bugs.python.org  Thu Jan 11 13:21:12 2018
From: report at bugs.python.org (Bob Ippolito)
Date: Thu, 11 Jan 2018 18:21:12 +0000
Subject: [issue29992] Expose parse_string in JSONDecoder
In-Reply-To: <1491380525.56.0.628505740968.issue29992@psf.upfronthosting.co.za>
Message-ID: <1515694872.81.0.467229070634.issue29992@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

Generally speaking, parsing some things as decimal or datetime are schema dependent. It's unlikely that you would want to parse every string that looks enough like a decimal as a decimal, or that you would want to pay the cost of checking every string in the whole document to see if it's a decimal. This use case is probably better served using something like object_pairs_hook where you have some context available.

Ultimate flexibility is not the goal of this interface. It's grown a bit too much of that over time. At this point I'm a lot more interested in proposals that remove options rather than add them.

In order to provide maximal flexibility it would be much nicer to have a streaming interface available (like SAX for XML parsing), but that is not what this is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29992>
_______________________________________

From report at bugs.python.org  Thu Jan 11 13:34:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 18:34:01 +0000
Subject: [issue29992] Expose parse_string in JSONDecoder
In-Reply-To: <1491380525.56.0.628505740968.issue29992@psf.upfronthosting.co.za>
Message-ID: <1515695641.35.0.467229070634.issue29992@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Bob.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29992>
_______________________________________

From report at bugs.python.org  Thu Jan 11 13:43:33 2018
From: report at bugs.python.org (Greg Lindahl)
Date: Thu, 11 Jan 2018 18:43:33 +0000
Subject: [issue31096] asyncio.stream.FlowControlMixin._drain_helper may lead
 to a blocking behavior
In-Reply-To: <1501573266.21.0.530489547005.issue31096@psf.upfronthosting.co.za>
Message-ID: <1515696213.25.0.467229070634.issue31096@psf.upfronthosting.co.za>


Change by Greg Lindahl <lindahl at pbm.com>:


----------
nosy: +wumpus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31096>
_______________________________________

From report at bugs.python.org  Thu Jan 11 13:53:28 2018
From: report at bugs.python.org (Alexander Mohr)
Date: Thu, 11 Jan 2018 18:53:28 +0000
Subject: [issue30698] asyncio sslproto do not shutdown ssl layer cleanly
In-Reply-To: <1497823715.09.0.154341862456.issue30698@psf.upfronthosting.co.za>
Message-ID: <1515696808.73.0.467229070634.issue30698@psf.upfronthosting.co.za>


Alexander Mohr <thehesiod at gmail.com> added the comment:

@grzgrzgrz3, does this resolve the issue in https://bugs.python.org/issue29406 ? I'm guessing you based this PR on that issue. If so I'd like it merged ASAP as otherwise our prod services will be incompatible with all future python releases given the original "fix" was reverted.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30698>
_______________________________________

From report at bugs.python.org  Thu Jan 11 13:54:40 2018
From: report at bugs.python.org (Alexander Mohr)
Date: Thu, 11 Jan 2018 18:54:40 +0000
Subject: [issue29406] asyncio SSL contexts leak sockets after calling close
 with certain Apache servers
In-Reply-To: <1485909545.04.0.650924943503.issue29406@psf.upfronthosting.co.za>
Message-ID: <1515696880.2.0.467229070634.issue29406@psf.upfronthosting.co.za>


Alexander Mohr <thehesiod at gmail.com> added the comment:

my understanding is that the PR in https://bugs.python.org/issue30698 fixes this issue no?  If so can we get it merged?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29406>
_______________________________________

From report at bugs.python.org  Thu Jan 11 14:19:55 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 11 Jan 2018 19:19:55 +0000
Subject: [issue27643] test_ctypes fails on AIX with xlc
In-Reply-To: <1469839915.17.0.167633993095.issue27643@psf.upfronthosting.co.za>
Message-ID: <e534fac6-16b4-66f3-d0c3-f8cde1f57ff6@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 30/07/2016 02:51, Martin Panter wrote:
> Martin Panter added the comment:
>
>
> ./python -m unittest -v ctypes.test.test_bitfields
>
> What I am suggesting as a fix is to change line 381 from plain ?int? to ?signed int?, and 382 to ?signed short?.

As some time has passed, I assume you mean look at this change:

struct BITS {
     signed int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
     signed short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
};

> I can make a patch later if that will help. Hopefully with these changes the C compiler will use signed integer logic, matching what I believe the ctypes library uses for c_int and c_short.

Not helping the compilation in any case - same messages as before.

* Default make:

michael at x071:[/data/prj/python/git/xlc-python3-3.7]xlc_r -DNDEBUG -O 
-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/>
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for M is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for N is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for O is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for P is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for Q is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for R is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for S is not valid. 
Type unsigned assumed.

* Adding (manually) -qbitfields=signed - almost the same.

michael at x071:[/data/prj/python/git/xlc-python3-3.7]xlc_r 
-qbitfields=signed -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 >
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for M is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for N is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for O is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for P is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for Q is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for R is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for S is not valid. 
Type signed assumed.

> Using a type other than short is not right, because the Python test is explicitly trying to test c_short behaviour. If your compiler does not support ?signed short? bitfields, maybe we just have to accept that ctypes supports it even though the compiler doesn?t, and skip the test.
Shall reply, asap, to your suggestion for a test that knows the 
difference in compilers.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27643>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27643>
_______________________________________

From report at bugs.python.org  Thu Jan 11 14:25:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 19:25:13 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515698713.14.0.467229070634.issue32346@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The relative speed up looks nice. But it is just few microseconds per class. You have to create many thousands of classes to gain a significant fraction of second. And the complexity added by this patch is not tiny.

I'm not sure how this caching works when change the parent class after creating the child class.

Without caching the benefit is 20-50% smaller. Perhaps this result can be improved. Actually we don't need to search in all dictionaries of all classes in the MRO. We can check the correspondent slot in the parent class (the offsets are constants) and look up in the class dict of the first class with non-zero slot value.

I tried to simplify this change (even at the cost of smaller speedup). But the result still looks too complex.

Since the benefit in any case will be small, and seems there are no other issues that depend on this change, I suggest to defer it to 3.8. There are more priority changes that should be made before the feature freeze in 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Thu Jan 11 14:28:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 19:28:17 +0000
Subject: [issue24340] co_stacksize estimate can be highly off
In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za>
Message-ID: <1515698897.8.0.467229070634.issue24340@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24340>
_______________________________________

From report at bugs.python.org  Thu Jan 11 14:34:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 19:34:59 +0000
Subject: [issue31113] Stack overflow with large program
In-Reply-To: <1501747851.67.0.0193426592051.issue31113@psf.upfronthosting.co.za>
Message-ID: <1515699299.9.0.467229070634.issue31113@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your review Antoine. I have merged the PR since resolving issue24340 allowed to simplify the code for the stack depth calculation.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31113>
_______________________________________

From report at bugs.python.org  Thu Jan 11 14:44:22 2018
From: report at bugs.python.org (Grzegorz Grzywacz)
Date: Thu, 11 Jan 2018 19:44:22 +0000
Subject: [issue30698] asyncio sslproto do not shutdown ssl layer cleanly
In-Reply-To: <1497823715.09.0.154341862456.issue30698@psf.upfronthosting.co.za>
Message-ID: <1515699862.59.0.467229070634.issue30698@psf.upfronthosting.co.za>


Grzegorz Grzywacz <grzgrzgrz3 at gmail.com> added the comment:

No, this PR originally fix similar but different issue. 

However it also fix issue29406 as a side effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30698>
_______________________________________

From report at bugs.python.org  Thu Jan 11 14:45:17 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 11 Jan 2018 19:45:17 +0000
Subject: [issue27643] test_ctypes fails on AIX with xlc
In-Reply-To: <1470301084.91.0.959214688936.issue27643@psf.upfronthosting.co.za>
Message-ID: <43c2c253-4b24-e6a5-03c5-07730d752567@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 04/08/2016 10:58, Martin Panter wrote:
> Martin Panter added the comment:
>
> Okay, so to be clear, I am assuming XLC supports all of the following fields, and uses unsigned bit fields by default:
>
> struct UNSIGNED_BITS {
>      unsigned int AU: 1;
>      int A: 1; /* Equivalent to unsigned int */
>      signed int AS: 1;
>      unsigned short MU: 1;
>      short M: 1; /* Equivalent to unsigned short; triggers warning */
> };
>
> and that it cannot compile the following:
>
> struct SIGNED_BITS {
>      signed short MS: 1; /* Not supported */
> };
>
> Attached is what I think a patch to resolve this would look like. However it needs a line in Modules/_ctypes/_ctypes_test.c completed to detect the compiler:
>
> #ifndef /* Something to identify XLC */
>
> Can you figure out a way to test for XLC (but not GCC, which the AIX buildbot uses),

I'll figure this out. HOWEVER, Just want to mention that both parts of 
C_Test are failing when using xlc (i.e., on "A" and "M"). Note line 40 
and 51.

(Have not done the compiler detect part yet, so it still returns 
something != 999)

 ?? +33? class C_Test(unittest.TestCase):
 ?? +34
 ?? +35????? def test_ints(self):
 ?? +36????????? for i in range(512):
 ?? +37????????????? for name in "ABCDEFGHI":
 ?? +38????????????????? b = BITS()
 ?? +39????????????????? setattr(b, name, i)
 ?? +40????????????????? self.assertEqual(getattr(b, name), 
func(byref(b), name.encode('ascii')))
 ?? +41
 ?? +42????? def test_shorts(self):
 ?? +43????????? b = BITS()
 ?? +44????????? name = "M"
 ?? +45????????? if func(byref(b), name.encode('ascii')) == 999:
 ?? +46????????????? self.skipTest("Compiler does not support signed 
short bitfields")
 ?? +47????????? for i in range(256):
 ?? +48????????????? for name in "MNOPQRS":
 ?? +49????????????????? b = BITS()
 ?? +50????????????????? setattr(b, name, i)
 ?? +51????????????????? self.assertEqual(getattr(b, name), 
func(byref(b), name.encode('ascii')))
 ?? +52

======================================================================
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
 ? File 
"/data/prj/python/git/xlc-python3-3.7/Lib/ctypes/test/test_bitfields.py", 
line 40, in test_ints
 ??? self.assertEqual(getattr(b, name), func(byref(b), 
name.encode('ascii')))
AssertionError: -1 != 1

======================================================================
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
 ? File 
"/data/prj/python/git/xlc-python3-3.7/Lib/ctypes/test/test_bitfields.py", 
line 51, in test_shorts
 ??? self.assertEqual(getattr(b, name), func(byref(b), 
name.encode('ascii')))
AssertionError: -1 != 1

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

> and then try my patch out? Hopefully you see no more compiler warnings, test_ints() should now pass,
again - not done the changes to _ctypes_test.c yet - so maybe the 
test_ints() will pass after that.
>   and test_shorts() should be skipped.
>
> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file44005/disable-signed-short.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27643>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27643>
_______________________________________

From report at bugs.python.org  Thu Jan 11 14:46:44 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Jan 2018 19:46:44 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1515698713.14.0.467229070634.issue32346@psf.upfronthosting.co.za>
Message-ID: <d39441f3-f400-fdf7-ad31-9f6036796544@free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le 11/01/2018 ? 20:25, Serhiy Storchaka a ?crit?:
> 
> I'm not sure how this caching works when change the parent class after creating the child class.

The caching is invalidated at the same place the method cache is
invalidated.

> Without caching the benefit is 20-50% smaller. Perhaps this result can be improved. Actually we don't need to search in all dictionaries of all classes in the MRO. We can check the correspondent slot in the parent class (the offsets are constants) and look up in the class dict of the first class with non-zero slot value.

I'm not sure that's always true.  The relationship between class dict
attributes and tp_ slots is not 100% bijective, there's more complicated
stuff going on for some of the descriptors.  My patch keeps the current
algorithm (ensuring no descriptor gets broken) but optimizes the lookups.

> There are more priority changes that should be made before the feature freeze in 3.7.

I am not working on any of those changes, so deferring this PR will not
have any effect on those changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Thu Jan 11 15:29:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jan 2018 20:29:46 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1515702586.43.0.467229070634.issue32226@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Can I help?

I'm implementing the feature related to pickling classes, and want to implement pickling generic types as an example. But since PEP 560 will change all here, I need to wait this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Thu Jan 11 15:31:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Jan 2018 20:31:50 +0000
Subject: [issue32535] msvcr140.dll has been replaced with vcruntime140.dll
In-Reply-To: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>
Message-ID: <1515702710.49.0.467229070634.issue32535@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Thu Jan 11 17:36:46 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 11 Jan 2018 22:36:46 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1515710206.89.0.467229070634.issue32226@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Serhiy,

I am sorry for a delay, I have recently moved to another country, this is why I have not much time. I will try to work on this weekend. Here are some points where you can be helpful:

* Make a short documentation PR for `__mro_entry__` and `__base_subclass__` methods.
* Document the `__class_getitem__` C API calling convention (with motivation, many classes are implemented in C but are generic in nature, like numpy.ndarray) in PEP 560.

(I know this might be not very interesting, but this will save time for me to focus only on typing part.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Thu Jan 11 17:45:12 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 11 Jan 2018 22:45:12 +0000
Subject: [issue32535] msvcr140.dll has been replaced with vcruntime140.dll
In-Reply-To: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>
Message-ID: <1515710712.18.0.467229070634.issue32535@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Where is that code? Presumably in distutils, and yet distutils has worked just fine for the 3.5 and 3.6 releases.

Perhaps you can clarify the bug report into something we can understand and investigate? That only thing in that thread I see that matches your suggestion is code that somebody *added* to distutils and found that it doesn't work (as expected).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Thu Jan 11 17:51:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 11 Jan 2018 22:51:42 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1515711102.98.0.467229070634.issue32533@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Almost seems like an unwinnable race here. We need to collect the error numbers before reacquiring the GIL (which could change some of them), but then if we update the object after getting the lock back we could still have raced with another thread.

Perhaps we need to make more dramatic changes to not store error codes against the object?

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Thu Jan 11 18:00:29 2018
From: report at bugs.python.org (Bruno Abreu Calfa)
Date: Thu, 11 Jan 2018 23:00:29 +0000
Subject: [issue32535] msvcr140.dll has been replaced with vcruntime140.dll
In-Reply-To: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>
Message-ID: <1515711629.42.0.467229070634.issue32535@psf.upfronthosting.co.za>


Bruno Abreu Calfa <bacalfa at gmail.com> added the comment:

Steve, I tried building the pyhsmm project (https://github.com/mattjj/pyhsmm) using:

python setup.py build -c mingw32

I got a link error saying that -lmsvcr140 could not be found. Then I realized that msvcr140.dlll doesn't exist. Instead, vcruntime140.dll seems to be the correct DLL. I was only able to build that project after making the modifications mentioned in my previous message, which requires changing a few files.

In order to try to reproduce the problem, one should try to build that project after installing Visual C++ 2015 Redistributable or Visual Studio 2015 to fall into the same MSVC version case as mine.

Does this clarify the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Thu Jan 11 19:41:37 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 12 Jan 2018 00:41:37 +0000
Subject: [issue32535] msvcr140.dll has been replaced with vcruntime140.dll
In-Reply-To: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>
Message-ID: <1515717697.12.0.467229070634.issue32535@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

A little bit. You're trying to build with mingw32? Do they support linking against the UCRT?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Thu Jan 11 19:54:42 2018
From: report at bugs.python.org (Bruno Abreu Calfa)
Date: Fri, 12 Jan 2018 00:54:42 +0000
Subject: [issue32535] msvcr140.dll has been replaced with vcruntime140.dll
In-Reply-To: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>
Message-ID: <1515718482.47.0.467229070634.issue32535@psf.upfronthosting.co.za>


Bruno Abreu Calfa <bacalfa at gmail.com> added the comment:

Correct. I installed the x86_64 version from mingw32-w64 (https://mingw-w64.org, v5.0.3).

I found this post https://mingwpy.github.io/ucrt.html, which actually references a post of yours. I honestly don't know if UCRT is supported by MinGW compiler. What are you going for? After googling a lot, I found many complaints of "missing msvcr140.dll", so I'm pretty much convinced that doesn't exist and has been replaced. But what does this have to do with the UCRT business? This is a bit beyond my knowledge on the matter. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Thu Jan 11 21:09:09 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 12 Jan 2018 02:09:09 +0000
Subject: [issue32535] msvcr140.dll has been replaced with vcruntime140.dll
In-Reply-To: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>
Message-ID: <1515722949.2.0.467229070634.issue32535@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

The CRT isn't a simple DLL anymore, and MinGW isn't a fully supported compiler either. You're going to be best to work with the people behind mingwpy to get it working, as there really isn't anything we can do on our end (though I do what I can to help them out, short of committing code).

As I understand it, work on mingwpy has basically stopped right now for a variety of reasons, and most projects have found ways to work with MSVC. 

I'm going to close this bug as external. When there is something for us to change in core, then we can consider it. (About the only thing worth doing right now is fully removing the mingw support to avoid confusion, but there's no value in that so why bother.)

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Fri Jan 12 00:53:52 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Jan 2018 05:53:52 +0000
Subject: [issue32467] dict_values isn't considered a Collection nor a Container
In-Reply-To: <1514734584.09.0.467229070634.issue32467@psf.upfronthosting.co.za>
Message-ID: <1515736432.09.0.467229070634.issue32467@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 02556fbade5e1e864dd09d5768a8dbbf5b3a0dac by Raymond Hettinger in branch 'master':
bpo-32467: Let collections.abc.ValuesView inherit from Collection (#5152)
https://github.com/python/cpython/commit/02556fbade5e1e864dd09d5768a8dbbf5b3a0dac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32467>
_______________________________________

From report at bugs.python.org  Fri Jan 12 00:54:15 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Jan 2018 05:54:15 +0000
Subject: [issue32467] dict_values isn't considered a Collection nor a Container
In-Reply-To: <1514734584.09.0.467229070634.issue32467@psf.upfronthosting.co.za>
Message-ID: <1515736455.85.0.467229070634.issue32467@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32467>
_______________________________________

From report at bugs.python.org  Fri Jan 12 00:54:57 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Jan 2018 05:54:57 +0000
Subject: [issue32449] MappingView must inherit from Collection instead of Sized
In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za>
Message-ID: <1515736497.59.0.467229070634.issue32449@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32449>
_______________________________________

From report at bugs.python.org  Fri Jan 12 01:05:30 2018
From: report at bugs.python.org (Alexey Baldin)
Date: Fri, 12 Jan 2018 06:05:30 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1515737130.35.0.467229070634.issue32533@psf.upfronthosting.co.za>


Alexey Baldin <alexeyb17 at gmail.com> added the comment:

I'd gather errno and win error into local variables (or struct) just after SSL call and then pass them to PySSL_SetError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Fri Jan 12 01:06:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Jan 2018 06:06:36 +0000
Subject: [issue31145] PriorityQueue.put() fails with TypeError if
 priority_number in tuples of (priority_number, data) are the same.
In-Reply-To: <1502201353.41.0.0622825133632.issue31145@psf.upfronthosting.co.za>
Message-ID: <1515737196.9.0.467229070634.issue31145@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 0c3be9651f4f149f4a78bb7043d26db9e75cabc0 by Raymond Hettinger in branch 'master':
bpo-31145: Use dataclasses to create a prioritization wrapper (#5153)
https://github.com/python/cpython/commit/0c3be9651f4f149f4a78bb7043d26db9e75cabc0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31145>
_______________________________________

From report at bugs.python.org  Fri Jan 12 01:07:15 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Jan 2018 06:07:15 +0000
Subject: [issue31145] PriorityQueue.put() fails with TypeError if
 priority_number in tuples of (priority_number, data) are the same.
In-Reply-To: <1502201353.41.0.0622825133632.issue31145@psf.upfronthosting.co.za>
Message-ID: <1515737235.27.0.467229070634.issue31145@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31145>
_______________________________________

From report at bugs.python.org  Fri Jan 12 03:54:59 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Jan 2018 08:54:59 +0000
Subject: [issue18369] X509 cert class for ssl module
In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za>
Message-ID: <1515747299.74.0.467229070634.issue18369@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5018

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18369>
_______________________________________

From report at bugs.python.org  Fri Jan 12 04:18:51 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 12 Jan 2018 09:18:51 +0000
Subject: [issue32473] Readibility of ABCMeta._dump_registry()
In-Reply-To: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>
Message-ID: <1515748731.23.0.467229070634.issue32473@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset ae12f5d4c98f2095c2aadd58981453e955044697 by INADA Naoki (yahya-abou-imran) in branch 'master':
bpo-32473: Improve ABCMeta._dump_registry() readability (GH-5091)
https://github.com/python/cpython/commit/ae12f5d4c98f2095c2aadd58981453e955044697


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Fri Jan 12 04:22:22 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Jan 2018 09:22:22 +0000
Subject: [issue32473] Readibility of ABCMeta._dump_registry()
In-Reply-To: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>
Message-ID: <1515748942.55.0.467229070634.issue32473@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5019

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Fri Jan 12 04:25:21 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Jan 2018 09:25:21 +0000
Subject: [issue16487] Allow ssl certificates to be specified from memory
 rather than files.
In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za>
Message-ID: <1515749121.81.0.467229070634.issue16487@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Senthil,

I'm not a fan of PR 2449 because it provides yet another way to load certificates and keys from memory. It's a clever idea to use MemoryBIO here. But the approach is *not* compatible with PEP 543. The PEP requires an API that can turn a memory blob into a series of certificate objects. PR 2449 doesn't enable memory -> certificate. The new API is OpenSSL specific and restricted to PKCS#8 key in PEM/DER encoding. PEP 543 is extensible for PKCS#11, engine and HSM support. PR 2449 is not.

There are other issues with PR 2449. For example it's missing several GIL releases calls. The password callback doesn't look correct in some places.

https://github.com/python/cpython/pull/5162 provides a PEP 543-compatible implementation (plus additions from pending PR):

>>> import ssl

>>> chain = ssl.Certificate.chain_from_file("Lib/test/ssl_cert.pem")
>>> cas = ssl.Certificate.bundle_from_file("Lib/test/pycacert.pem")
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ssl.SSLError: [PEM: BAD_PASSWORD_READ] bad password read (_ssl.c:58)
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem", password="somepass")

>>> chain
(<_ssl.Certificate '/C=XY/L=Castle Anthrax/O=Python Software Foundation/CN=localhost'>,)
>>> cas
[<_ssl.Certificate '/C=XY/O=Python Software Foundation CA/CN=our-ca-server'>]

>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
>>> ctx.load_cert_chain(chain, pkey)
>>> ctx.load_verify_locations(cadata=cas)

# get_ca_certs() doesn't return ssl.Certificates yet
>>> ctx.get_ca_certs()
[{'subject': ((('countryName', 'XY'),), (('organizationName', 'Python Software Foundation CA'),), (('commonName', 'our-ca-server'),)), 'issuer': ((('countryName', 'XY'),), (('organizationName', 'Python Software Foundation CA'),), (('commonName', 'our-ca-server'),)), 'version': 3, 'serialNumber': 'B09264B1F2DA21D0', 'notBefore': 'Jan  4 19:47:07 2013 GMT', 'notAfter': 'Jan  2 19:47:07 2023 GMT'}]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16487>
_______________________________________

From report at bugs.python.org  Fri Jan 12 04:27:21 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Jan 2018 09:27:21 +0000
Subject: [issue18369] X509 cert class for ssl module
In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za>
Message-ID: <1515749241.38.0.467229070634.issue18369@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

API example:

>>> import ssl

>>> chain = ssl.Certificate.chain_from_file("Lib/test/ssl_cert.pem")
>>> cas = ssl.Certificate.bundle_from_file("Lib/test/pycacert.pem")
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ssl.SSLError: [PEM: BAD_PASSWORD_READ] bad password read (_ssl.c:58)
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem", password="somepass")

>>> chain
(<_ssl.Certificate '/C=XY/L=Castle Anthrax/O=Python Software Foundation/CN=localhost'>,)
>>> cas
[<_ssl.Certificate '/C=XY/O=Python Software Foundation CA/CN=our-ca-server'>]

>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
>>> ctx.load_cert_chain(chain, pkey)
>>> ctx.load_verify_locations(cadata=cas)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18369>
_______________________________________

From report at bugs.python.org  Fri Jan 12 04:34:30 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 12 Jan 2018 09:34:30 +0000
Subject: [issue27643] test_ctypes fails on AIX with xlc
In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za>
Message-ID: <1515749670.8.0.467229070634.issue27643@psf.upfronthosting.co.za>


Change by Michael Felt <michael at felt.demon.nl>:


----------
pull_requests: +5020

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27643>
_______________________________________

From report at bugs.python.org  Fri Jan 12 04:36:22 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 12 Jan 2018 09:36:22 +0000
Subject: [issue27643] test_ctypes fails on AIX with xlc
In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za>
Message-ID: <1515749782.54.0.467229070634.issue27643@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

@panter - your patch seems to be working well. Thanks.

PR 5164 submitted for review

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27643>
_______________________________________

From report at bugs.python.org  Fri Jan 12 04:41:16 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Jan 2018 09:41:16 +0000
Subject: [issue18369] X509 cert class for ssl module
In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za>
Message-ID: <1515750076.02.0.467229070634.issue18369@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

More examples:

>>> import ssl, socket, pprint
>>> ctx = ssl.create_default_context()
>>> sock = ctx.wrap_socket(socket.socket(), server_hostname="www.python.org")
>>> sock.connect(("www.python.org", 443))
>>> pprint.pprint(sock._sslobj._sslobj.verified_chain())
(<_ssl.Certificate '/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=3359300/street=16 Allen Rd/postalCode=03894-4801/C=US/ST=New Hampshire/L=Wolfeboro/O=Python Software Foundation/CN=www.python.org'>,
 <_ssl.Certificate '/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA'>,
 <_ssl.Certificate '/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA'>)

>>> eecert = sock._sslobj._sslobj.verified_chain()[0]
>>> eecert.check_hostname('www.python.org')
'www.python.org'
>>> eecert.check_hostname('www.python.com')
False

>>> cert = ssl.Certificate.from_file('wildcards-combined.rsa.pem')
>>> pprint.pprint(cert.get_info())
{'OCSP': ('http://testca.pythontest.net/ca/ocsp/pysubca',),
 'caIssuers': ('http://testca.pythontest.net/ca/pysubca.cer',),
 'crlDistributionPoints': ('http://testca.pythontest.net/ca/pysubca.crl',),
 'issuer': ((('countryName', 'XZ'),),
            (('stateOrProvinceName', 'Holy Grail'),),
            (('organizationName', 'Castle Anthrax'),),
            (('organizationalUnitName', 'Python Software Foundation'),),
            (('commonName', 'Python Tests Intermediate CA'),)),
 'notAfter': 'Jan  1 12:00:00 2027 GMT',
 'notBefore': 'Jan  1 12:00:00 2017 GMT',
 'serialNumber': '0A',
 'subject': ((('countryName', 'XZ'),),
             (('stateOrProvinceName', 'Holy Grail'),),
             (('organizationName', 'Castle Anthrax'),),
             (('organizationalUnitName', 'Python Software Foundation'),),
             (('commonName', 'Wildcards in SAN'),)),
 'subjectAltName': (('DNS', '*.wildcard.pythontest.net'),
                    ('DNS', 'www*.wildcard-www.pythontest.net'),
                    ('DNS', 'x*.wildcard-x.pythontest.net')),
 'version': 3}
>>> cert.check_hostname('www.wildcard.pythontest.net')
'*.wildcard.pythontest.net'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18369>
_______________________________________

From report at bugs.python.org  Fri Jan 12 05:06:27 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 12 Jan 2018 10:06:27 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515751587.81.0.467229070634.issue32346@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

As my understand, this patch creates cache for all classe,
not only for parent classes.
Caches may has much tuples, and they are GC tracked because
they contains function descriptors.  And they actually creates
reference cycles.

Am I correct?

If so, I want estimate of GC overhead and memory overhead of cache
for large project.  Is it really negligible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Fri Jan 12 05:17:18 2018
From: report at bugs.python.org (Sebastian Bank)
Date: Fri, 12 Jan 2018 10:17:18 +0000
Subject: [issue15927] csv.reader() does not support escaped newline when
 quoting=csv.QUOTE_NONE
In-Reply-To: <1347425390.54.0.862014726204.issue15927@psf.upfronthosting.co.za>
Message-ID: <1515752238.43.0.467229070634.issue15927@psf.upfronthosting.co.za>


Sebastian Bank <sebastian.bank at uni-leipzig.de> added the comment:

To be complete, the docs of Dialect.escapechar should probably also say that it is used to escape itself.
However, note that csw.writer currently only does this with csv.QUOTE_NONE (breaking round-trip otherwise: #12178).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15927>
_______________________________________

From report at bugs.python.org  Fri Jan 12 05:47:43 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 12 Jan 2018 10:47:43 +0000
Subject: [issue32473] Readibility of ABCMeta._dump_registry()
In-Reply-To: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>
Message-ID: <1515754063.0.0.467229070634.issue32473@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset a91662affeb0aae2515cdc5e8f82269337105bf4 by INADA Naoki (Miss Islington (bot)) in branch '3.6':
bpo-32473: Improve ABCMeta._dump_registry() readability (GH-5091)
https://github.com/python/cpython/commit/a91662affeb0aae2515cdc5e8f82269337105bf4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Fri Jan 12 05:48:15 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 12 Jan 2018 10:48:15 +0000
Subject: [issue32473] Readibility of ABCMeta._dump_registry()
In-Reply-To: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>
Message-ID: <1515754095.61.0.467229070634.issue32473@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Fri Jan 12 06:23:25 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Jan 2018 11:23:25 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515756205.45.0.467229070634.issue32346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a simple script creating 10000 classes (a large number, but perhaps not out of sight for a large application importing a lot of libraries (*)).

(*) see the experiment I did in https://mail.python.org/pipermail/python-dev/2017-December/151260.html

Before:
$ ./python-orig -I benchgcclasses.py 
GC time: 6.8 ms
RSS:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
antoine  11248  0.0  0.3  41296 24576 pts/1    S+   12:18   0:00 ./python-orig -I benchgcclasses.py

After:
$ ./python -I benchgcclasses.py 
GC time: 6.9 ms
RSS:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
antoine  11097  0.0  0.3  41300 24740 pts/1    S+   12:18   0:00 ./python -I benchgcclasses.py


RSS is a bit unstable from run to run, but roughly the patch seems to add 100 to 200KB in this case.

As for full GC time, it is quite stable and there's a 0.1ms increase with the patch.

Note this is really a worst-case benchmark: lots of classes, no methods, no user data beside the classes.

----------
Added file: https://bugs.python.org/file47378/benchgcclasses.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Fri Jan 12 06:28:29 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Jan 2018 11:28:29 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515756509.66.0.467229070634.issue32346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Serhiy:

> The relative speed up looks nice. But it is just few microseconds per class. You have to create many thousands of classes to gain a significant fraction of second.

This work started with your message in https://mail.python.org/pipermail/python-dev/2017-December/151277.html pointing out that we shouldn't add tp_ slots because it makes type creation and Python initialization slower (*), so I'm a bit surprised that you're now claiming speeding up type creation (by up to 3x!) is not important...

(*) To quote:

'''
2. Increased class initialization time. For every class for every slot 
we need to look up corresponding methods in dictionaries of the class 
itself and all its parents (caching doesn't work fine at this stage). 
Significant part of class initialization time is spent on initializing 
slots. This will increase the startup time and the time of creating 
local classes. The relative overhead is more significant in Cython.
'''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Fri Jan 12 06:43:42 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 12 Jan 2018 11:43:42 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515757422.53.0.467229070634.issue32346@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> Note this is really a worst-case benchmark: lots of classes, no methods, no user data beside the classes.

Since benchgcclasses.py doesn't creates dunder methods,
cache doesn't have GC-tracked tuples, and ref cycles.

benchgcclasses2.py adds three dunder methods:

$ ./python benchgcclasses.py
GC time: 13.0 ms
gc: collecting generation 2...
gc: objects in each generation: 1 0 94942
gc: objects in permanent generation: 0
gc: done, 0.0131s elapsed
RSS:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
inada-n  29604  0.0  0.1  47052 30692 pts/2    S+   20:42   0:00 ./python benchgcclasses.py

$ ./python-patched benchgcclasses.py
GC time: 17.2 ms
gc: collecting generation 2...
gc: objects in each generation: 1 0 135220
gc: objects in permanent generation: 0
gc: done, 0.0173s elapsed
RSS:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
inada-n  29626  0.0  0.2  49880 33464 pts/2    S+   20:43   0:00 ./python-patched benchgcclasses.py

----------
Added file: https://bugs.python.org/file47379/benchgcclasses2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Fri Jan 12 06:47:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Jan 2018 11:47:33 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515757653.95.0.467229070634.issue32346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since benchgcclasses.py doesn't creates dunder methods,
cache doesn't have GC-tracked tuples, and ref cycles.

Hmm, you're right, thank you.  I can also reproduce your numbers here (using benchgcclasses2.py).  There's definitely an impact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Fri Jan 12 07:16:49 2018
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 12 Jan 2018 12:16:49 +0000
Subject: [issue32536] ast and tokenize disagree about line number
Message-ID: <1515759409.32.0.467229070634.issue32536@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

This occurs (on linux at least) when the the end of line sequence `\r\r\n` occurs in a comment that is indented relative to the following lines.

The attached file demonstrates the problem.

----------
components: Library (Lib)
files: tokenize_fail_test.py
messages: 309852
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: ast and tokenize disagree about line number
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file47380/tokenize_fail_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32536>
_______________________________________

From report at bugs.python.org  Fri Jan 12 07:55:47 2018
From: report at bugs.python.org (Pox TheGreat)
Date: Fri, 12 Jan 2018 12:55:47 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1515761747.7.0.467229070634.issue31804@psf.upfronthosting.co.za>


Pox TheGreat <poxthegreat at gmail.com> added the comment:

I have already uploaded a patch file but it is not in the required format. Also I realize that most of the confusion was because I forgot to provide the OS version. Perhaps it would be good to have a separate field for that.

I will upload a patch as it is described in the developer guide.

----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Fri Jan 12 08:37:04 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 12 Jan 2018 13:37:04 +0000
Subject: [issue30537] Using PyNumber_AsSsize_t in itertools.islice
In-Reply-To: <1496316369.93.0.672552876761.issue30537@psf.upfronthosting.co.za>
Message-ID: <1515764224.56.0.467229070634.issue30537@psf.upfronthosting.co.za>


Jeroen Demeyer <jdemeyer at cage.ugent.be> added the comment:

Just to note that this bug affects SageMath too: https://trac.sagemath.org/ticket/24528

Thanks for fixing!

----------
nosy: +jdemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30537>
_______________________________________

From report at bugs.python.org  Fri Jan 12 09:09:49 2018
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Sebasti=C3=A3o_de_Oliveira_Bueno?=)
Date: Fri, 12 Jan 2018 14:09:49 +0000
Subject: [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1515766188.99.0.467229070634.issue19431@psf.upfronthosting.co.za>


Jo?o Sebasti?o de Oliveira Bueno <gwidion at gmail.com> added the comment:

This discussion is fresh, so maybe it is worth asking here prior to python-ideas:

In Python we can change any global variable, object attribute or mapping-value with function calls. Locals and nonlocals are the only exceptions and from time to time that gets in the way of clever oneliners, and it is just plain asymmetric. 

What do you say of adding a wrapper to this as an oficial Python function in the stdlib? Maybe inspect.setlocal() that could set f_locals and call this?? That would  provide a workaround to the asymmetry that locals currently experiment. 

It would not impose any extra security risks, since this can be called via ctypes already, and also it is not any more subject to abuse than setattr or globals()[...] =  can already be abused.

----------
nosy: +Jo?o.Sebasti?o.de.Oliveira.Bueno

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19431>
_______________________________________

From report at bugs.python.org  Fri Jan 12 09:26:34 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Jan 2018 14:26:34 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515767194.58.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf by Christian Heimes in branch 'master':
bpo-32521: nis libtirpc (#5137)
https://github.com/python/cpython/commit/f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 12 09:26:41 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Jan 2018 14:26:41 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515767201.98.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5021
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 12 09:27:42 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Jan 2018 14:27:42 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515767262.16.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5022

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 12 09:37:57 2018
From: report at bugs.python.org (Tilman Beck)
Date: Fri, 12 Jan 2018 14:37:57 +0000
Subject: [issue32537] multiprocessing.pool.Pool.starmap_async - wrong
 parameter name
Message-ID: <1515767877.08.0.467229070634.issue32537@psf.upfronthosting.co.za>


New submission from Tilman Beck <tilman-beck at gmx.de>:

The optional parameter for the error callback function is named "error_callback" not "error_back"

----------
assignee: docs at python
components: Documentation
files: bug.png
messages: 309857
nosy: devnull, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.pool.Pool.starmap_async - wrong parameter name
versions: Python 3.5
Added file: https://bugs.python.org/file47381/bug.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32537>
_______________________________________

From report at bugs.python.org  Fri Jan 12 10:05:56 2018
From: report at bugs.python.org (Johannes)
Date: Fri, 12 Jan 2018 15:05:56 +0000
Subject: [issue32538] Multiprocessing Manager on 3D list - no change of the
 list possible
Message-ID: <1515769556.66.0.467229070634.issue32538@psf.upfronthosting.co.za>


New submission from Johannes <johannes.jaegers at gmx.de>:

I have the following code, which works without multiprocessing:

data=[[['','','','','','','','','','','','']]]
data[0][0][0] = 5
data[0][0][1] = "5" # data in the array is mixed with float and str
print(data)

#=> [[[5, '5', '', '', '', '', '', '', '', '', '', '']]]

Now I want to use Multiprocessing and every process should be able to change the 3D list. This doesn't work and no error message is shown.

from multiprocessing import Process, Manager
manager=Manager()
data=manager.list([[['','','','','','','','','','','','']]])
data[0][0][0] = 5
data[0][0][1] = "5"
print(data)    

#=> [[['', '', '', '', '', '', '', '', '', '', '', '']]]

I found the following text:

list(sequence)
Create a shared list object and return a proxy for it.
Changed in version 3.6: Shared objects are capable of being nested. For     
example, a shared container object such as a shared list can contain 
other shared objects which will all be managed and synchronized by the 
SyncManager.(https://docs.python.org/3/library/multiprocessing.html)

Unfortunately it also doesn't work with 3.6.3, same problem as before! But as it should work, I guess it's a bug?

I use Ubuntu 16.04...

----------
components: Interpreter Core
messages: 309858
nosy: John_81
priority: normal
severity: normal
status: open
title: Multiprocessing Manager on 3D list - no change of the list possible
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32538>
_______________________________________

From report at bugs.python.org  Fri Jan 12 10:09:24 2018
From: report at bugs.python.org (Erik Bray)
Date: Fri, 12 Jan 2018 15:09:24 +0000
Subject: [issue30537] Using PyNumber_AsSsize_t in itertools.islice
In-Reply-To: <1496316369.93.0.672552876761.issue30537@psf.upfronthosting.co.za>
Message-ID: <1515769764.48.0.467229070634.issue30537@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

> Users might be better off by not seeing an unhelpful error message when passing in a numpy.int32, or they might be worse-off by having lost a cue that they were writing inefficient code (which invisibly creates temporary integer objects on every call when presumably the whole reason for using numpy was a concern for efficiency).

While it's true there are many Numpy users who don't understand what they're doing, any time they go into the Python interpreter they're losing the benefits of Numpy anyways (which are fast vectorized operations on arrays).

----------
nosy: +erik.bray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30537>
_______________________________________

From report at bugs.python.org  Fri Jan 12 10:29:39 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Jan 2018 15:29:39 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515770979.75.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset d55d6825d7bd0fc120c95d579065623ce6392a2f by Christian Heimes (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-32521: nis libtirpc (GH-5137) (#5165)
https://github.com/python/cpython/commit/d55d6825d7bd0fc120c95d579065623ce6392a2f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 12 10:35:28 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Jan 2018 15:35:28 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515771328.03.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset ab95b3074ee43098edf3f23b07fb18ef57ee614d by Christian Heimes (Miss Islington (bot)) in branch '2.7':
bpo-32521: nis libtirpc (GH-5137) (#5166)
https://github.com/python/cpython/commit/ab95b3074ee43098edf3f23b07fb18ef57ee614d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 12 11:35:46 2018
From: report at bugs.python.org (Joongi Kim)
Date: Fri, 12 Jan 2018 16:35:46 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515774946.36.0.467229070634.issue32528@psf.upfronthosting.co.za>


Change by Joongi Kim <me at daybreaker.info>:


----------
nosy: +achimnol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Fri Jan 12 11:56:45 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 12 Jan 2018 16:56:45 +0000
Subject: [issue32539] os.listdir(...) on deep path on windows in python2.7
 fails with errno 123
Message-ID: <1515776205.66.0.467229070634.issue32539@psf.upfronthosting.co.za>


New submission from Anthony Sottile <asottile at umich.edu>:

On windows, a deep path can be accessed by prefixing the path with \\?\

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx?f=255&MSPPError=-2147217396#maxpath

The call to `listdir()` fails because it uses a posix separator.

A quick patch to fix this is to use `SEP` here: https://github.com/python/cpython/blob/ab95b3074ee43098edf3f23b07fb18ef57ee614d/Modules/posixmodule.c#L2388 (I can submit a patch for this)

Here's a stacktrace

>>> os.listdir(r'\\?\C:\Temp')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\C:\\Temp/*.*'


This works fine in python3, as the code has been refactored to use `SEP` already.

>>> os.listdir(r'\\?\C:\Temp')
[]

----------
components: Library (Lib), Windows
messages: 309862
nosy: Anthony Sottile, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.listdir(...) on deep path on windows in python2.7 fails with errno 123
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32539>
_______________________________________

From report at bugs.python.org  Fri Jan 12 12:03:38 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Fri, 12 Jan 2018 17:03:38 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1515776618.01.0.467229070634.issue32521@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Unfortunately the yp_prot.h and ypclnt.h [0] headers have also moved to a different package.

Currently they reside at /usr/include/nsl/rpcsvc/*.h

[0] https://github.com/python/cpython/blob/f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf/Modules/nismodule.c#L18
[1] https://fedoraproject.org/wiki/Changes/NISIPv6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 12 12:14:47 2018
From: report at bugs.python.org (Chris Rose)
Date: Fri, 12 Jan 2018 17:14:47 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1515777287.87.0.467229070634.issue28914@psf.upfronthosting.co.za>


Chris Rose <offby1 at offby1.net> added the comment:

Is this patch mergeable? I'm trialing the 3.7.0a4 build on some systems here and am unable to build due to this issue, on libc 2.12:

? /lib/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.6 20110731 XXXXXXXXXXXX.
Compiled on a Linux 3.2.5 system on 2017-10-20.
Available extensions:
	The C stubs add-on version 2.1.2.
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
	RT using linux kernel aio

----------
nosy: +offby1

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Fri Jan 12 12:16:20 2018
From: report at bugs.python.org (Chris Rose)
Date: Fri, 12 Jan 2018 17:16:20 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1515777380.85.0.467229070634.issue28914@psf.upfronthosting.co.za>


Chris Rose <offby1 at offby1.net> added the comment:

Ach; ignore the libc version below; that's a PEBKAC error on my part. The libc version on the system that's failing is older (and hard to get; just trust me, it's older) and doesn't have the relevant epoll value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Fri Jan 12 12:27:34 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 12 Jan 2018 17:27:34 +0000
Subject: [issue32539] os.listdir(...) on deep path on windows in python2.7
 fails with errno 123
In-Reply-To: <1515776205.66.0.467229070634.issue32539@psf.upfronthosting.co.za>
Message-ID: <1515778054.65.0.467229070634.issue32539@psf.upfronthosting.co.za>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +5023
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32539>
_______________________________________

From report at bugs.python.org  Fri Jan 12 12:34:16 2018
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Jan 2018 17:34:16 +0000
Subject: [issue32539] os.listdir(...) on deep path on windows in python2.7
 fails with errno 123
In-Reply-To: <1515776205.66.0.467229070634.issue32539@psf.upfronthosting.co.za>
Message-ID: <1515778456.64.0.467229070634.issue32539@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

This should be fixed. That said, we have to use a unicode string for a long path anyway. Prior to Windows 8, the conversion from ANSI to Unicode in the system runtime library uses a static MAX_PATH buffer, so the ANSI API is inherently limited to MAX_PATH. You'll see this in the documentation of all functions that allow using \\?\ extended paths:

    In the ANSI version of this function, the name is limited to 
    MAX_PATH characters. To extend this limit to 32,767 wide 
    characters, call the Unicode version of the function and 
    prepend "\\?\" to the path.

Decoding ANSI strings uses a dynamically-sized buffer in Windows 8, but the change is undocumented and should not be relied upon.

Unfortunately, we can't reliably use a raw unicode string literal in Python 2, since \u and \U escapes are still evaluated. We can instead use forward slashes and normalize via os.path.normpath.

----------
nosy: +eryksun
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32539>
_______________________________________

From report at bugs.python.org  Fri Jan 12 12:38:24 2018
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 12 Jan 2018 17:38:24 +0000
Subject: [issue32539] os.listdir(...) on deep path on windows in python2.7
 fails with errno 123
In-Reply-To: <1515776205.66.0.467229070634.issue32539@psf.upfronthosting.co.za>
Message-ID: <1515778704.3.0.467229070634.issue32539@psf.upfronthosting.co.za>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32539>
_______________________________________

From report at bugs.python.org  Fri Jan 12 13:07:13 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 12 Jan 2018 18:07:13 +0000
Subject: [issue32540] venv docs - doesn't match behavior
Message-ID: <1515780433.02.0.467229070634.issue32540@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In the docs for the venv command, it states:

> Changed in version 3.4: In earlier versions, if the target directory already existed, an error was raised, unless the --clear or --upgrade option was provided. Now, if an existing directory is specified, its contents are removed and the directory is processed as if it had been newly created.

However, that's not the behavior I observe:

$ python -m venv env
$ env/bin/pip install -q requests
$ python -m venv env          
$ env/bin/python -c "import requests"
$

Plus, I believe the _current_ behavior should be documented not in a 'change' note. I suggest the change note should read:

> Changed in version 3.4: In earlier versions, if the target directory already existed, an error was raised, unless the --clear or --upgrade option was provided.

And the third paragraph, following "It also creates an (initially empty...Lib\site-packages).":

> If an existing directory is specified, it will be re-used.

----------
assignee: docs at python
components: Documentation
messages: 309867
nosy: docs at python, jason.coombs
priority: normal
severity: normal
status: open
title: venv docs - doesn't match behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32540>
_______________________________________

From report at bugs.python.org  Fri Jan 12 13:37:36 2018
From: report at bugs.python.org (John Jolly)
Date: Fri, 12 Jan 2018 18:37:36 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1515782256.03.0.467229070634.issue32476@psf.upfronthosting.co.za>


Change by John Jolly <jjolly at suse.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Fri Jan 12 13:41:57 2018
From: report at bugs.python.org (Ian Craggs)
Date: Fri, 12 Jan 2018 18:41:57 +0000
Subject: [issue32541] cgi.FieldStorage constructor assumes all lines terminate
 with \n
Message-ID: <1515782517.92.0.467229070634.issue32541@psf.upfronthosting.co.za>


New submission from Ian Craggs <icraggs at gmail.com>:

Using cgi.FieldStorage in an HTTP server in a subclass of BaseHTTPRequestHandler, parsing the request with:

form = cgi.FieldStorage(fp=self.rfile,
                        headers=self.headers,
                        environ={"REQUEST_METHOD":op.upper(),
                              "CONTENT_TYPE":self.headers['Content-Type'],})

This has been working fine with clients using the Python requests library. Now processing requests from a Java library (org.apache.cxf.jaxrs.client.WebClient), the final line in a multipart request does not include the (\r)\n, which causes the final read to hang until a socket timeout.  The read in question is in cgi.py, read_lines_to_outerboundary:

line = self.fp.readline(1<<16) # bytes

(line 824 in Python 3.6.2).  I changed this read to not assume the termination of the final line with \n:

    def read_line(self, last_boundary):
        line = self.fp.readline(len(last_boundary))
        if line != last_boundary and not line.endswith(b"\n"):
            line += self.fp.readline((1<<16) - len(last_boundary))
        return line


and the request worked.  The Java library is being used in tests against our production web server so I assume that is working correctly.  

Perhaps I am misusing the FieldStorage class, I don't know, I'm not expert on this.

----------
components: Library (Lib), macOS
messages: 309868
nosy: Ian Craggs, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: cgi.FieldStorage constructor assumes all lines terminate with \n
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32541>
_______________________________________

From report at bugs.python.org  Fri Jan 12 13:56:34 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 12 Jan 2018 18:56:34 +0000
Subject: [issue32542] memory not freed, aka memory leak continues...
Message-ID: <1515783394.33.0.467229070634.issue32542@psf.upfronthosting.co.za>


New submission from Michael Felt <michael at felt.demon.nl>:

in issue25582 - the issue is not (yet) resolved. Perhaps this one can be closed and issue25582 reopened.

Both from python2-2.7.14 and "git master" I am getting:

michael at x071:[/data/prj/python/git/gcc-python3-3.7]./python -m unittest -v ctypes.test.test_pointers          <
test_abstract (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basic (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basics (ctypes.test.test_pointers.PointersTestCase) ... ok
test_bug_1467852 (ctypes.test.test_pointers.PointersTestCase) ... ok
test_c_void_p (ctypes.test.test_pointers.PointersTestCase) ... ok
test_callbacks_with_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_change_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_charpp (ctypes.test.test_pointers.PointersTestCase)
Test that a character pointer-to-pointer is correctly passed ... ok
test_from_address (ctypes.test.test_pointers.PointersTestCase) ... ok
test_other (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pass_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_crash (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_name (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase) ... ERROR
test_pointers_bool (ctypes.test.test_pointers.PointersTestCase) ... ok

======================================================================
ERROR: test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/git/gcc-python3-3.7/Lib/ctypes/test/test_pointers.py", line 208, in test_pointer_type_str_name
    large_string = 'T' * 2 ** 25
MemoryError

----------------------------------------------------------------------
Ran 15 tests in 0.319s

FAILED (errors=1)

+++++
Looking at the test source:

  +196      def test_pointer_type_name(self):
  +197          LargeNamedType = type('T' * 2 ** 25, (Structure,), {})
  +198          self.assertTrue(POINTER(LargeNamedType))
  +199
  +200          # to not leak references, we must clean _pointer_type_cache
  +201          from ctypes import _pointer_type_cache
  +202          del _pointer_type_cache[LargeNamedType]
  +203
  +204      def test_pointer_type_str_name(self):
  +205          large_string = 'T' * 2 ** 25
  +206          P = POINTER(large_string)
  +207          self.assertTrue(P)
  +208
  +209          # to not leak references, we must clean _pointer_type_cache
  +210          from ctypes import _pointer_type_cache
  +211          del _pointer_type_cache[id(P)]

****
After changing the exponent (** 25) to "** 23" on either line 197 OR 205 
- ALL test succeed -
After changing the exponent to " ** 24" on BOTH lines 197 and 205, all tests pass.

****
My concern is that the "patch" from issue 25582 the 
"del _pointer_type_cache[]" statement is not freeing memory.

+++++
What can I add to the test to debug!
+++++
p.s. - results are the same on AIX (5.3 and 6.1) Python2-2.7.14 and Pyhton3-3.7.X (git master). Compiler does not seem to matter (both xlc and gcc).
32-bit, default memory model (256 MByte max - aka (2 ** 28) for data and malloc. I could also try changing the memory model - but will do that only if the test, by definition, is not "free()ing" the memory used, when done.

HTH
Michael

----------
components: Tests
messages: 309869
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: memory not freed, aka memory leak continues...
type: behavior
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32542>
_______________________________________

From report at bugs.python.org  Fri Jan 12 14:22:13 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Jan 2018 19:22:13 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1515784933.7.0.467229070634.issue29708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

A disagreement has popped up over what the ideal solution is on the PR currently connected to this issue. I'm having the folks involved switch it over to here.

IMO I think py_compile can respect SOURCE_DATE_EPOCH and just blindly use it for creating .pyc files. That way builds are reproducible. Yes, it will quite possibly lead to those .pyc files being regenerated the instant Python starts running, but SOURCE_DATE_EPOCH is entirely about builds, not runtimes. Plus .pyc files are just optimizations and so it is not critical they not be regenerated again later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Fri Jan 12 14:36:59 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Jan 2018 19:36:59 +0000
Subject: [issue32541] cgi.FieldStorage constructor assumes all lines terminate
 with \n
In-Reply-To: <1515782517.92.0.467229070634.issue32541@psf.upfronthosting.co.za>
Message-ID: <1515785819.42.0.467229070634.issue32541@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I'm removing the macOS tag and nosies because I think it highly unlikely that the behavior would be limited to macOS.  Without a reproducible test case, it's not easy to verify that or investigate further.  The cgi module doesn't get a lot of attention but perhaps someone with cgi experience will take a look.

----------
components:  -macOS
nosy:  -ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32541>
_______________________________________

From report at bugs.python.org  Fri Jan 12 14:37:08 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Jan 2018 19:37:08 +0000
Subject: [issue32541] cgi.FieldStorage constructor assumes all lines terminate
 with \n
In-Reply-To: <1515782517.92.0.467229070634.issue32541@psf.upfronthosting.co.za>
Message-ID: <1515785828.15.0.467229070634.issue32541@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy:  -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32541>
_______________________________________

From report at bugs.python.org  Fri Jan 12 17:28:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Jan 2018 22:28:39 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515796119.5.0.467229070634.issue31993@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5b76bdba071e7bbd9fda0b9b100d1506d95c04bd by Serhiy Storchaka in branch 'master':
bpo-31993: Do not use memoryview when pickle large strings. (#5154)
https://github.com/python/cpython/commit/5b76bdba071e7bbd9fda0b9b100d1506d95c04bd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Fri Jan 12 17:29:53 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Jan 2018 22:29:53 +0000
Subject: [issue31993] pickle.dump allocates unnecessary temporary bytes / str
In-Reply-To: <1510251110.85.0.213398074469.issue31993@psf.upfronthosting.co.za>
Message-ID: <1515796193.78.0.467229070634.issue31993@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31993>
_______________________________________

From report at bugs.python.org  Fri Jan 12 17:32:48 2018
From: report at bugs.python.org (Nathan Goldbaum)
Date: Fri, 12 Jan 2018 22:32:48 +0000
Subject: [issue32543] odd floor division behavior
Message-ID: <1515796368.52.0.467229070634.issue32543@psf.upfronthosting.co.za>


New submission from Nathan Goldbaum <nathan12343 at gmail.com>:

According to PEP 238:


"floor division will be implemented in all the Python numeric types, and will have the semantics of:

a // b == floor(a/b)

except that the result type will be the common type into which a and b are coerced before the operation."

But consider the following cases in Python 3.6.3:

>>> 0.9//0.1
8.0
>>> 0.8//0.1
8.0
>>> import math
>>> math.floor(0.9/0.1)
9
>>> math.floor(0.8/0.1)
8

Am I missing something?

----------
components: Interpreter Core
messages: 309873
nosy: Nathan.Goldbaum
priority: normal
severity: normal
status: open
title: odd floor division behavior
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32543>
_______________________________________

From report at bugs.python.org  Fri Jan 12 17:48:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Jan 2018 22:48:32 +0000
Subject: [issue32542] memory not freed, aka memory leak continues...
In-Reply-To: <1515783394.33.0.467229070634.issue32542@psf.upfronthosting.co.za>
Message-ID: <1515797312.96.0.467229070634.issue32542@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Issue25582 fixed a memory leak. If run the tests repeatedly every iteration leaked 100 MB of memory. If you get a MemoryError with a single iteration, this means that your machine just doesn't have enough memory for tests. Tests require around 500-600MB of memory on 32-bit platform.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32542>
_______________________________________

From report at bugs.python.org  Fri Jan 12 18:09:02 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Jan 2018 23:09:02 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1515798542.37.0.467229070634.issue32248@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:


New changeset bca42186b69e2e615d29d0d4fdb493c9fe71c48b by Brett Cannon in branch 'master':
bpo-32248: Introduce the concept of Loader.get_resource_reader() (GH-5108)
https://github.com/python/cpython/commit/bca42186b69e2e615d29d0d4fdb493c9fe71c48b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Fri Jan 12 18:16:54 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Jan 2018 23:16:54 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1515799014.75.0.467229070634.issue32502@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for your additional analysis.  So, assuming I understand it correctly, the problem here is that there can be hardware configurations where the only (or first?) hardware addresses available exceed 48 bits.  I'm not sure what might be different for your system when running 10.13, assuming uuid1() used to work on earlier versions of macOS; perhaps another network interface with a smaller address was supported and configured?  It seems like such configurations are pretty rare; there don't seem to be any prior bug reports on this and it would be unusual for Mac systems to only have a Firewire (non-loopback) network interface configured.  In any case, such configurations presumably are not limited to Macs so I'm removing the macOS tag.

----------
components: +Library (Lib) -macOS
nosy:  -ronaldoussoren
stage:  -> needs patch
title: uuid1() broken on macos high sierra -> uuid1() fails if only 64-bit interface addresses are available

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Fri Jan 12 18:22:25 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Jan 2018 23:22:25 +0000
Subject: [issue32537] multiprocessing.pool.Pool.starmap_async - wrong
 parameter name
In-Reply-To: <1515767877.08.0.467229070634.issue32537@psf.upfronthosting.co.za>
Message-ID: <1515799345.49.0.467229070634.issue32537@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

This was supposed to be fixed in 3.6+ by Issue 31304. In general, 3.5 only gets security fixes at this stage. I?m not sure if it is easy or worth back porting this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32537>
_______________________________________

From report at bugs.python.org  Fri Jan 12 18:41:18 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Jan 2018 23:41:18 +0000
Subject: [issue32537] multiprocessing.pool.Pool.starmap_async - wrong
 parameter name
In-Reply-To: <1515767877.08.0.467229070634.issue32537@psf.upfronthosting.co.za>
Message-ID: <1515800478.75.0.467229070634.issue32537@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

This wouldn't qualify as a security problem so, if the problem no longer exists in 3.6, then this issue should be closed

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32537>
_______________________________________

From report at bugs.python.org  Fri Jan 12 18:47:33 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 12 Jan 2018 23:47:33 +0000
Subject: [issue32543] odd floor division behavior
In-Reply-To: <1515796368.52.0.467229070634.issue32543@psf.upfronthosting.co.za>
Message-ID: <1515800853.92.0.467229070634.issue32543@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

That does look at first glance like a bug in // to me. 0.9/0.1 is correctly rounded to 9.0 exactly, so flooring it should return 9 (as it does):

# Python 3.5 on Linux
py> 0.9/0.1 == 9
True
py> math.floor(0.9/0.1)
9

So I too would expect that 0.9//0.1 should evaluate as 9, not 8.

----------
nosy: +mark.dickinson, steven.daprano, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32543>
_______________________________________

From report at bugs.python.org  Fri Jan 12 19:00:18 2018
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 13 Jan 2018 00:00:18 +0000
Subject: [issue32543] odd floor division behavior
In-Reply-To: <1515796368.52.0.467229070634.issue32543@psf.upfronthosting.co.za>
Message-ID: <1515801618.74.0.467229070634.issue32543@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Looks like floor division for floats call into the divmod function, which has the same behavior:

>>> 0.9 .__divmod__(0.1)
(8.0, 0.09999999999999998)

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32543>
_______________________________________

From report at bugs.python.org  Fri Jan 12 19:07:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Jan 2018 00:07:48 +0000
Subject: [issue32543] odd floor division behavior
In-Reply-To: <1515796368.52.0.467229070634.issue32543@psf.upfronthosting.co.za>
Message-ID: <1515802068.13.0.467229070634.issue32543@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is the result of multiple roundings.

0.9 and 0.1 can't be represented exactly as floats. They are approximated by binary fractions.

>>> from fractions import Fraction
>>> Fraction(0.9)
Fraction(8106479329266893, 9007199254740992)
>>> Fraction(0.1)
Fraction(3602879701896397, 36028797018963968)

The result of the division of these fractions can't be represented as a float too.

>>> Fraction(0.9)/Fraction(0.1)
Fraction(32425917317067572, 3602879701896397)
>>> Fraction(0.9)/Fraction(0.1) - 9
Fraction(-1, 3602879701896397)
>>> float(Fraction(0.9)/Fraction(0.1) - 9)
-2.7755575615628914e-16
>>> 9 + float(Fraction(0.9)/Fraction(0.1) - 9)
9.0

It is slightly smaller than 9, but the nearest float value is 9.0. Thus the result of the division is rounded up to 9.0.

A similar issue already was opened several months ago. I don't remember the number.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32543>
_______________________________________

From report at bugs.python.org  Fri Jan 12 19:19:34 2018
From: report at bugs.python.org (Andres Petralli)
Date: Sat, 13 Jan 2018 00:19:34 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1515802774.41.0.467229070634.issue32502@psf.upfronthosting.co.za>


Andres Petralli <anpetral at microsoft.com> added the comment:

This could be purely incidental to have shown up in 10.13, but yes, the problem comes from the fact that the first hardware ID in the list of devices happens to be an EUI-64 address with 64 bits now. This is the Firewire interface of my Mac Pro and maybe one of the few that actually uses a EUI-64 addresses, hence relatively rare. Maybe the order changed in 10.13 and this now happens to be the first entry returned from 'ifconfig' when previously maybe it was the Ethernet adapter, but given the lookup algorithm in uuid reads in line by line until it finds the first hw id, this is bound to fail on my machine. Clearly, I don't think uuid should make assumptions about order of interfaces that could have mixed EUI-48 and EUI-64 addresses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Fri Jan 12 19:23:13 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Jan 2018 00:23:13 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1515802993.16.0.467229070634.issue32502@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

(As a workaround, you *might* be able to reorder the network interfaces in the System Preferences -> Network control panel.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Fri Jan 12 19:23:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Jan 2018 00:23:31 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1515803011.56.0.467229070634.issue29240@psf.upfronthosting.co.za>


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


----------
pull_requests: +5024

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Fri Jan 12 19:29:32 2018
From: report at bugs.python.org (Andres Petralli)
Date: Sat, 13 Jan 2018 00:29:32 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1515803372.39.0.467229070634.issue32502@psf.upfronthosting.co.za>


Andres Petralli <anpetral at microsoft.com> added the comment:

Moving doesn't work, but even removing the firewire adapter (which was unused on my system), doesn't remove it from the output of ifconfig.

I did however work around the issue by just patching up uuid in a suboptimal manner (truncated the 64bit int to 48bit).

A proper fix would probably need to discard EUI-64 addresses and look for EUI-48 specifically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Fri Jan 12 19:56:35 2018
From: report at bugs.python.org (Andres Petralli)
Date: Sat, 13 Jan 2018 00:56:35 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1515804995.02.0.467229070634.issue32502@psf.upfronthosting.co.za>


Andres Petralli <anpetral at microsoft.com> added the comment:

Re: rarity. There is at least one more person that ran into the same issue as seen in this report: https://github.com/Azure/azure-cli/issues/5184

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Fri Jan 12 22:11:23 2018
From: report at bugs.python.org (bbayles)
Date: Sat, 13 Jan 2018 03:11:23 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1515813083.73.0.467229070634.issue32146@psf.upfronthosting.co.za>


bbayles <bbayles at gmail.com> added the comment:

I ran into this issue, and found references to it on StackOverflow [1] and GitHub [2] as well. I found that the problem applies to both the 'spawn' and 'forkserver' start methods on Linux.

I made an attempt to implement dancol's fix above. (1) and (3) are straightforward, but if there's an elegant way to do the "tickle" in (2) I wasn't able to figure it out?

My branch [3] has something that seems to work with the 'spawn' method and cx_Freeze. Perhaps someone could look at that and tell me if I'm on a reasonable track? If so, I can attempt to extend the method to cover 'forkserver' as well.

[1] https://stackoverflow.com/q/47325297/353839

[2] https://github.com/anthony-tuininga/cx_Freeze/issues/264

[3] https://github.com/python/cpython/compare/master...bbayles:bpo-32146-freeze_support

----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Fri Jan 12 22:18:00 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 13 Jan 2018 03:18:00 +0000
Subject: [issue32543] odd floor division behavior
In-Reply-To: <1515796368.52.0.467229070634.issue32543@psf.upfronthosting.co.za>
Message-ID: <1515813480.0.0.467229070634.issue32543@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

This report appears to be the same:

https://bugs.python.org/issue27463

One other thing to note:  the Python docs are sometimes unclear about whether expressions are intended to be interpreted as Python code or as mathematical expressions.  In:

"""
floor division will be implemented in all the Python numeric types, and will have the semantics of:

a // b == floor(a/b)
"""

note that it did _not_ say `math.floor(a/b)`.  `floor(a/b)` here is intended to be read as a mathematical (infinitely precise) specification.  As can be inferred from the output Serhiy posted, after the Python

a = 0.9
b = 0.1

the infinitely precise value of `a/b` is a tiny bit less than 9, so the infinitely precise value of `floor(a/b)` is exactly 8.  Which is what the Python `a // b` returns.

Personally, I wish Python 3 had changed the meaning of `//` (and `divmod()` and `%` - the three are deeply related) for floats, but too late for that now :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32543>
_______________________________________

From report at bugs.python.org  Sat Jan 13 05:34:00 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Sat, 13 Jan 2018 10:34:00 +0000
Subject: [issue31310] semaphore tracker isn't protected against crashes
In-Reply-To: <1504108352.86.0.17423028145.issue31310@psf.upfronthosting.co.za>
Message-ID: <1515839640.18.0.467229070634.issue31310@psf.upfronthosting.co.za>


Change by Thomas Moreau <thomas.moreau.2010 at gmail.com>:


----------
pull_requests: +5025

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31310>
_______________________________________

From report at bugs.python.org  Sat Jan 13 05:39:41 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Sat, 13 Jan 2018 10:39:41 +0000
Subject: [issue31310] semaphore tracker isn't protected against crashes
In-Reply-To: <1504108352.86.0.17423028145.issue31310@psf.upfronthosting.co.za>
Message-ID: <1515839981.47.0.467229070634.issue31310@psf.upfronthosting.co.za>


Thomas Moreau <thomas.moreau.2010 at gmail.com> added the comment:

With this fix, the semaphore_tracker is not shared with the children anymore and each process launches its own tracker.

I opened a PR to try to fix it. Let me know if I should open a new ticket.

----------
nosy: +tomMoral

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31310>
_______________________________________

From report at bugs.python.org  Sat Jan 13 10:36:16 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jan 2018 15:36:16 +0000
Subject: [issue31310] semaphore tracker isn't protected against crashes
In-Reply-To: <1504108352.86.0.17423028145.issue31310@psf.upfronthosting.co.za>
Message-ID: <1515857776.34.0.467229070634.issue31310@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With this fix, the semaphore_tracker is not shared with the children anymore and each process launches its own tracker.

That's only if the semaphore tracker process crashes, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31310>
_______________________________________

From report at bugs.python.org  Sat Jan 13 10:51:15 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Sat, 13 Jan 2018 15:51:15 +0000
Subject: [issue31310] semaphore tracker isn't protected against crashes
In-Reply-To: <1504108352.86.0.17423028145.issue31310@psf.upfronthosting.co.za>
Message-ID: <1515858675.98.0.467229070634.issue31310@psf.upfronthosting.co.za>


Thomas Moreau <thomas.moreau.2010 at gmail.com> added the comment:

For new processes created with spawn or forkserver, only the semaphore_tracker._fd is send and shared to the child. Thus, as the _pid argument is None in the new process, it launches a new tracker if it needs to create a new Semaphore, regardless of crashes in the previous semaphore tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31310>
_______________________________________

From report at bugs.python.org  Sat Jan 13 12:10:33 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 13 Jan 2018 17:10:33 +0000
Subject: [issue29209] Remove old-deprecated ElementTree features
In-Reply-To: <1483898185.03.0.0187159979308.issue29209@psf.upfronthosting.co.za>
Message-ID: <1515863433.96.0.467229070634.issue29209@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Patch looks right to me.

I'd personally be ok with applying it to 3.7, but I'll leave the decision to you. Most of the removed "features" are non-controversial, except:

- "getchildren()" is probably still in use, also because it's more efficient than "list(elem)" in lxml (and has never been deprecated there), so code that supports both libraries might have preferred it

- cElementTree is probably still imported by quite a bit of code

So, this will have an impact on user code, despite any previous deprecation warnings. But it's easy to resolve in a backwards compatible way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29209>
_______________________________________

From report at bugs.python.org  Sat Jan 13 12:38:50 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jan 2018 17:38:50 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1515865130.14.0.467229070634.issue32346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think that Inada is right: there's too much impact on memory consumption and garbage collection to call this an optimization.

Serhiy suggested removing the cache.  But, once you remove the cache, you're going to iterate on all values of all parent classes' dicts to find which values are __dunder__ methods.  This risks being much more expensive for classes with tens or hundreds of namespace entries, making the optimization even less interesting.

So in the end I think I'm going to reject this issue.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Sat Jan 13 12:41:34 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jan 2018 17:41:34 +0000
Subject: [issue31310] semaphore tracker isn't protected against crashes
In-Reply-To: <1504108352.86.0.17423028145.issue31310@psf.upfronthosting.co.za>
Message-ID: <1515865294.55.0.467229070634.issue31310@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thus, as the _pid argument is None in the new process, it launches a new tracker if it needs to create a new Semaphore

I see.  Is it an optimization problem, or does it risk leaking semaphores?  The problem is if a semaphore shared with the child isn't garbage collected correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31310>
_______________________________________

From report at bugs.python.org  Sat Jan 13 13:03:34 2018
From: report at bugs.python.org (Joongi Kim)
Date: Sat, 13 Jan 2018 18:03:34 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1515866614.16.0.467229070634.issue32528@psf.upfronthosting.co.za>


Joongi Kim <me at daybreaker.info> added the comment:

I strongly agree to have discretion of CancelledError and other general exceptions, though I don't have concrete ideas on good unobtrusive ways to achieve this.

If I write my codes carefully I could control most of cancellation explicitly, but it is still hard to control it in 3rd-party libraries that I depend on. Often they just raise random errors, or CancelledError is swallowed.

Also it would be nice to have some documentation and examples on how to write "cancellation-friendly" coroutine codes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Sat Jan 13 13:06:23 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Sat, 13 Jan 2018 18:06:23 +0000
Subject: [issue31310] semaphore tracker isn't protected against crashes
In-Reply-To: <1504108352.86.0.17423028145.issue31310@psf.upfronthosting.co.za>
Message-ID: <1515866783.76.0.467229070634.issue31310@psf.upfronthosting.co.za>


Thomas Moreau <thomas.moreau.2010 at gmail.com> added the comment:

> Is it an optimization problem, or does it risk leaking semaphores?

I do not think it risks leaking semaphores as the clean-up is performed by the process which created the Semaphore. So I would say it is more an optimization issue.

It is true that I do not see many use case where the Semaphore might be created by the child process but it was optimized in previous version. If you don't think it is useful, we could avoid sharing the semaphore_tracker pipe to the child process to reduce complexity in the spawning process. Do you think it is worth fixing or it should be simplified?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31310>
_______________________________________

From report at bugs.python.org  Sat Jan 13 13:08:38 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 13 Jan 2018 18:08:38 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515866918.16.0.467229070634.issue32516@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sat Jan 13 13:29:29 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 13 Jan 2018 18:29:29 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
Message-ID: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

ABCMeta.__new__ calls `getattr(value, "__isabstractmethod__", False)` many times.
https://github.com/python/cpython/blob/0f31c74fcfdec8f9e6157de2c366f2273de81677/Lib/abc.py#L135-L142

Since metaclass is used by subclasses, it checks all members of all subclasses (including concrete class).

But getattr() and hasattr() is inefficient when attribution is not found,
because it raises AttributeError and clear it internally.

I tried to bypass AttributeError when tp_getattro == PyObject_GenericGetAttr.
Here is quick micro benchmark:

$ ./python-patched -m perf timeit --compare-to=`pwd`/python-master -s 'def foo(): pass' 'hasattr(foo, "__isabstractmethod__")'python-master: ..................... 385 ns +- 2 ns
python-patched: ..................... 87.6 ns +- 1.6 ns

Mean +- std dev: [python-master] 385 ns +- 2 ns -> [python-patched] 87.6 ns +- 1.6 ns: 4.40x faster (-77%)

(I added Ivan to nosy list because he may implement C version of ABC.)

----------
messages: 309896
nosy: inada.naoki, levkivskyi
priority: normal
severity: normal
status: open
title: Speed up hasattr(o, name) and getattr(o, name, default)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Sat Jan 13 13:31:06 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 13 Jan 2018 18:31:06 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
In-Reply-To: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>
Message-ID: <1515868266.06.0.467229070634.issue32544@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +5026
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:10:28 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jan 2018 20:10:28 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515874228.91.0.467229070634.issue32516@psf.upfronthosting.co.za>


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


----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:10:47 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jan 2018 20:10:47 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515874247.08.0.467229070634.issue32516@psf.upfronthosting.co.za>


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


----------
nosy: +Ray Donnelly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:14:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Jan 2018 20:14:43 +0000
Subject: [issue29476] Simplify set_add_entry()
In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za>
Message-ID: <1515874483.25.0.467229070634.issue29476@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

What I've decided for now is to keep the freeslot reuse logic but in a simpler form. Currently there are two optimizations for rare cases.  The first is reusing a dummy entry -- we'll keep that.  And the second is detecting multiple dummies in a lookup chain and prefering the first in the chain -- I'm going to get rid of this I haven't found any plausible case where it demonstrates value in excess of its cost.

For it to trigger, the set has to have had a growth phase, then a number of subsequent deletions, and then later additions that have multiple collisions with dummy entries, all without any intervening resizes.  Modern sets have a lower fill factor, making this situation even less likely.  Also, modern sets use a series of linear probes making collisions much cheaper.  The benefit is so small and so rare, it possible that the cost of the inner-loop test now exceeds its potential benefit.  Given that the optimization is of questionable worth, I choose to remove it, preferring the simpler inner-loop code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29476>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:15:54 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Jan 2018 20:15:54 +0000
Subject: [issue29476] Simplify set_add_entry()
In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za>
Message-ID: <1515874554.13.0.467229070634.issue29476@psf.upfronthosting.co.za>


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


----------
pull_requests: +5027
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29476>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:23:40 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Sat, 13 Jan 2018 20:23:40 +0000
Subject: [issue31368] RWF_NONBLOCK
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1515875020.24.0.467229070634.issue31368@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

preadv2(2) syscall with RWF_NONBLOCK feature is now released starting linux4.14
https://kernelnewbies.org/Linux_4.14#Asynchronous_buffered_I.2FO_support

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:34:13 2018
From: report at bugs.python.org (Matt Ripley)
Date: Sat, 13 Jan 2018 20:34:13 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
Message-ID: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>


New submission from Matt Ripley <matt.ripley at yahoo.co.uk>:

When I try to use any of the installers downloaded from the website I get the errors 2203 and 0x80070643:

[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to install MSI package.
[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to configure per-user MSI package.
[2468:1D2C][2018-01-13T20:15:51]i319: Applied execute package: core_JustForMe, result: 0x80070643, restart: None
[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to execute MSI package.

Been looking all over the reported issues but nothing has helped me with this one. Other installers work without issue?

----------
components: Installation
files: Python 3.7.0a4 (64-bit)_20180113201542_000_core_JustForMe.log
messages: 309899
nosy: mwr256
priority: normal
severity: normal
status: open
title: Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070643: Failed to install MSI package.
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47382/Python 3.7.0a4 (64-bit)_20180113201542_000_core_JustForMe.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:34:39 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Jan 2018 20:34:39 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1515875679.75.0.467229070634.issue32545@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:47:09 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 13 Jan 2018 20:47:09 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515876429.46.0.467229070634.issue32516@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

How is this an improvement over loading the DLL explicitly? Even if subpackages require the file, your top level __init__.py will run before they are loaded and it can import a pyd that's known to be next to the file or it can LoadLibrary the contents of .libs itself.

Modifying the search path is not entirely robust, as you know, but once a DLL is loaded it doesn't need to be on the path to be found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:59:26 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Jan 2018 20:59:26 +0000
Subject: [issue29476] Simplify set_add_entry()
In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za>
Message-ID: <1515877166.65.0.467229070634.issue29476@psf.upfronthosting.co.za>


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


Added file: https://bugs.python.org/file47383/inner_loop_analysis.s

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29476>
_______________________________________

From report at bugs.python.org  Sat Jan 13 16:26:23 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Jan 2018 21:26:23 +0000
Subject: [issue32546] Unusual TypeError with dataclass decorator
Message-ID: <1515878783.18.0.467229070634.issue32546@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The following code (simplified from a real example) triggers an unexpected TypeError:

    @dataclass
    class PrioritizedItem:
        priority: 'int'
        def __eq__(self, other):
            return self.priority == other.priority

This code gives the following trackback:

    Traceback (most recent call last):
      File "/Users/raymond/Documents/tmp16.py", line 16, in <module>
        @dataclass
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 598, in dataclass
        return wrap(_cls)
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 590, in wrap
        return _process_class(cls, repr, eq, order, hash, init, frozen)
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 539, in _process_class
        _set_attribute(cls, '__hash__', None)
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 444, in _set_attribute
        raise TypeError(f'Cannot overwrite attribute {name} '
    TypeError: Cannot overwrite attribute __hash__ in PrioritizedItem

----------
assignee: eric.smith
components: Library (Lib)
files: data_class_type_error.py
messages: 309901
nosy: eric.smith, rhettinger
priority: normal
severity: normal
status: open
title: Unusual TypeError with dataclass decorator
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47384/data_class_type_error.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32546>
_______________________________________

From report at bugs.python.org  Sat Jan 13 16:30:11 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Jan 2018 21:30:11 +0000
Subject: [issue32546] Unusual TypeError with dataclass decorator
In-Reply-To: <1515878783.18.0.467229070634.issue32546@psf.upfronthosting.co.za>
Message-ID: <1515879011.73.0.467229070634.issue32546@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think the error message here can be improved to explain why is being raised.  Otherwise the cause isn't self-evident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32546>
_______________________________________

From report at bugs.python.org  Sat Jan 13 17:58:55 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 13 Jan 2018 22:58:55 +0000
Subject: [issue32546] Unusual TypeError with dataclass decorator
In-Reply-To: <1515878783.18.0.467229070634.issue32546@psf.upfronthosting.co.za>
Message-ID: <1515884335.14.0.467229070634.issue32546@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks.

I'm going to be changing the errors as part of #32513, but I'll make sure to cover this case better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32546>
_______________________________________

From report at bugs.python.org  Sat Jan 13 18:15:11 2018
From: report at bugs.python.org (Eric Lafontaine)
Date: Sat, 13 Jan 2018 23:15:11 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1515885311.59.0.467229070634.issue28879@psf.upfronthosting.co.za>


Change by Eric Lafontaine <eric.lafontaine1 at gmail.com>:


----------
pull_requests: +5028

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Sat Jan 13 19:00:54 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Jan 2018 00:00:54 +0000
Subject: [issue21592] Make statistics.median run in linear time
In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za>
Message-ID: <1515888054.27.0.467229070634.issue21592@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5029
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21592>
_______________________________________

From report at bugs.python.org  Sat Jan 13 19:41:44 2018
From: report at bugs.python.org (Ben Cummings)
Date: Sun, 14 Jan 2018 00:41:44 +0000
Subject: [issue32547] csv.DictWriter emits strange errors if fieldnames is an
 iterator
Message-ID: <1515890504.43.0.467229070634.issue32547@psf.upfronthosting.co.za>


New submission from Ben Cummings <ben at benandconner.com>:

If I pass an iterator to csv.DictWriter as the fieldname field, then DictWriter consumes that iterator pretty quickly, emitting strange errors such as the following when trying to write the headers.

>>> import csv
>>> fields = iter(["a", "b", "c", "d"])
>>> f = open('test.csv', 'w')
>>> writer = csv.DictWriter(f, fieldnames=fields)
>>> writer.writeheader()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/csv.py", line 142, in writeheader
    self.writerow(header)
  File "/usr/lib/python3.4/csv.py", line 153, in writerow
    return self.writer.writerow(self._dict_to_list(rowdict))
  File "/usr/lib/python3.4/csv.py", line 149, in _dict_to_list
    + ", ".join([repr(x) for x in wrong_fields]))
ValueError: dict contains fields not in fieldnames: 'c', 'a'

This is because writeheader and _dict_to_list repeatedly iterate over self.fieldnames. It seems like this could be solved by making a list of fieldnames in the constructor.

----------
components: Library (Lib)
messages: 309904
nosy: bendotc
priority: normal
severity: normal
status: open
title: csv.DictWriter emits strange errors if fieldnames is an iterator
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32547>
_______________________________________

From report at bugs.python.org  Sat Jan 13 19:57:43 2018
From: report at bugs.python.org (Eli Schwartz)
Date: Sun, 14 Jan 2018 00:57:43 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1515891463.34.0.467229070634.issue29708@psf.upfronthosting.co.za>


Eli Schwartz <eschwartz93 at gmail.com> added the comment:

So, a couple of things.

It seems to me, that properly supporting SOURCE_DATE_EPOCH means using exactly that and nothing else. To that end, I'm not entirely sure why things like --clamp-mtime even exist, as the original timestamp of a source file doesn't seem to have a lot of utility and it is better to be entirely predictable. But I'm not going to argue that, except insomuch as it seems IMHO to fit better for python to just keep things simple and override the timestamp with the value of SOURCE_DATE_EPOCH

That being said, I see two problems with python implementing something analogous to --clamp-mtime rather than just --mtime.


1) Source files are extracted by some build process, and remain untouched. Python generates bytecode pinned to the original time, rather than SOURCE_DATE_EPOCH. Later, the build process packages those files and implements --mtime, not --clamp-mtime. Because Python and the packaging software disagree about which one to use, the bytecode fails.

2) Source files are extracted, and the build process even tosses all timestamps to the side of the road, by explicitly `touch`ing all of them to the date of SOURCE_DATE_EPOCH just in case. Then for whatever reason (distro patches, 2to3, the use of `cp`) the timestamps get updated to $currentime. But SOURCE_DATE_EPOCH is in the future, so the timestamps get downdated. Python bytecode is generated by emulating --clamp-mtime. The build process then uses --mtime to package the files. Again, because Python and the packaging software disagree about which one to use, the bytecode fails.

Of course, in both those cases, blindly respecting SOURCE_DATE_EPOCH will seemingly break everything for people who use --clamp-mtime instead. I'm not happy with reproducible-builds.org for allowing either one.

I don't think python should rely on --mtime users manually overriding the filesystem metadata of the source files outside of py_compile, as that is a hack that I think we'd like to remove if possible... that being said, Arch Linux will, on second thought, not be adversely affected even if py_compile tries to be clever and emulate --clamp-mtime to decide on its own whether to respect SOURCE_DATE_EPOCH.

Likewise, I don't really expect people to try to reproduce builds using a future date for SOURCE_DATE_EPOCH. On the other hand, the reproducible builds spec doesn't forbid it AFAICT.

But... neither of those mitigations seem "clean" to me, for the reasons stated above.

There is something that would solve all these issues, though. From reading the importlib code (I haven't actually tried smoketesting actual imports), it appears that Python 2 accepts any bytecode that is dated at or later than the timestamp of its source .py, while Python 3 requires the timestamps to perfectly match. This seems bizarre to behave differently, especially as until @bmwiedemann mentioned it on the GitHub PR I blindly assumed that Python would not care if your bytecode is somehow dated later than your sources. If the user is playing monkey games with mismatched source and byte code, while backdating the source code to *trick* the interpreter into loading it... let them? They can break their stuff if they want to!

On looking through the commit logs, it seems that Python 3 used to do the same, until https://github.com/python/cpython/commit/61b14251d3a653548f70350acb250cf23b696372 refactored the general vicinity and modified this behavior without warning. In a commit that seems to be designed to do something else entirely. This really should have been two separate commits, and modifying the import code to more strictly check the timestamp should have come with an explanatory justification. Because I cannot think of a good reason for this behavior, and the commit isn't giving me an opportunity to understand either. As it is, I am completely confused, and have no idea whether this was even supposed to be deliberate.
In hindsight it is certainly preventing nice solutions to supporting SOURCE_DATE_EPOCH.

----------
nosy: +eschwartz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Sat Jan 13 20:08:10 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 01:08:10 +0000
Subject: [issue32548] IDLE: Add links for email and docs to help_about
Message-ID: <1515892085.57.0.467229070634.issue32548@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

In the help_about dialog, change the email address and IDLE documentation into hyperlinks as a first step toward rewriting the dialog to use hyperlinks instead of buttons, as proposed in msg296648 and msg294298.

----------
assignee: terry.reedy
components: IDLE
messages: 309906
nosy: csabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Add links for email and docs to help_about
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32548>
_______________________________________

From report at bugs.python.org  Sat Jan 13 20:08:18 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jan 2018 01:08:18 +0000
Subject: [issue32547] csv.DictWriter emits strange errors if fieldnames is an
 iterator
In-Reply-To: <1515890504.43.0.467229070634.issue32547@psf.upfronthosting.co.za>
Message-ID: <1515892098.1.0.467229070634.issue32547@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This isn't a bug.  The docs specify that *fieldnames* is a sequence, "The fieldnames parameter is a sequence of keys that identify the order in which values in the dictionary passed to the writerow() method are written to the csvfile."

We could make this a feature request. but as far as I can tell there isn't a real use case, nor has one ever arisen in the decade long history of the module.  Adding the list(fieldnames) behavior could be done without a backwards compatibility issue, but it does incur an overhead that would be paid by all existing working code.

----------
nosy: +rhettinger
type:  -> enhancement
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32547>
_______________________________________

From report at bugs.python.org  Sat Jan 13 20:16:12 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 01:16:12 +0000
Subject: [issue32548] IDLE: Add links for email and docs to help_about
In-Reply-To: <1515892085.57.0.467229070634.issue32548@psf.upfronthosting.co.za>
Message-ID: <1515892572.74.0.467229070634.issue32548@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5030
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32548>
_______________________________________

From report at bugs.python.org  Sat Jan 13 20:27:25 2018
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 14 Jan 2018 01:27:25 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515893245.82.0.467229070634.issue32516@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

> on Windows, the rpath mechanism doesn't exist

It seems we can locate a dependent assembly up to two directories up from a DLL using a relative path. According to MSDN [1], this is supported in Windows 7+. 3.7 no longer supports Vista, so this can potentially be used for extension modules in 3.7. I tested that it works in Windows 10, at least.

[1]: https://msdn.microsoft.com/en-us/library/aa374182

Create a "<name>.2.config" file for the module (e.g. "myextension.pyd.2.config"), and include a "probing" path in this file. This can specify up to 9 relative directories that can be up to two levels above the module. For example, the following adds "..\.libs" to the DLL's private assembly search path:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <configuration>
      <windows>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <probing privatePath="..\.libs" />
        </assemblyBinding>
      </windows>
    </configuration>

Add dependent assemblies to the module's #2 embedded manifest. For example, here's a dependency on 64-bit "myassembly" version 1.0.000.1234:

      <dependency>
        <dependentAssembly>
          <assemblyIdentity name="myassembly"
                            version="1.0.000.1234"
                            type="win32"
                            processorArchitecture="amd64" />
        </dependentAssembly>
      </dependency>

I this case the assembly is a directory with the given assembly name that contains an "<assembly_name>.manifest" file (e.g. "myassembly.manifest"). This manifest lists the assembly DLLs that are in the directory. For example:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <assemblyIdentity name="myassembly"
                          version="1.0.000.1234"
                          type="win32"
                          processorArchitecture="amd64" />
        <file name="mylib1.dll" />
        <file name="mylib2.dll" />
    </assembly>

The loader will look for the assembly in WinSxS, the module's directory, a subdirectory named for the assembly, and then the private probing paths that were added by the module's config file.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sat Jan 13 20:33:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jan 2018 01:33:08 +0000
Subject: [issue21592] Make statistics.median run in linear time
In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za>
Message-ID: <1515893588.25.0.467229070634.issue21592@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Everyone here should heed Tim's comments.  The statistics module already has a history of suboptimal decisions made in the service of theoretical perfection (i.e. mean(seq) is over a 100x slower than fsum(seq)/len(seq)).

While variants of quick-select have a nice O(n) theoretical time, the variability is very-high and has really bad worst cases. The existing sort() is unbelievably fast, has a reasonable worst case, exploits existing order to great advantage, has nice cache performance, and has become faster still with the recently added type-specialized comparisons.  This sets a very high bar for any proposed patches.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21592>
_______________________________________

From report at bugs.python.org  Sat Jan 13 21:00:13 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 14 Jan 2018 02:00:13 +0000
Subject: [issue32546] Unusual TypeError with dataclass decorator
In-Reply-To: <1515878783.18.0.467229070634.issue32546@psf.upfronthosting.co.za>
Message-ID: <1515895213.01.0.467229070634.issue32546@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

No matter what happens with #32513, I think the right thing to do in this case is to not error if trying to set __hash__ to None, if it already is None in __dict__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32546>
_______________________________________

From report at bugs.python.org  Sat Jan 13 21:42:54 2018
From: report at bugs.python.org (xoviat)
Date: Sun, 14 Jan 2018 02:42:54 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515897774.06.0.467229070634.issue32516@psf.upfronthosting.co.za>


xoviat <xoviat at gmail.com> added the comment:

So the idea here is actually to write a replacement for auditwheel that works on windows. In order to do that, I need to recursively analyze DLL dependencies, randomize the DLL filenames, rewrite the pe header table, and then copy them into the .libs folder.

At that point, I need some mechanism to either preload all of the DLLs or add them to the DLL search path so that extensions can find them (example: the extension will need to load umfpack-gghsa-cp36.dll). If assemblies can accomplish such a task, then I can use them. However the restriction on the number of parent directories is a real problem.

I've benchmarked preloading the DLLs and it's not really ideal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sat Jan 13 21:46:18 2018
From: report at bugs.python.org (xoviat)
Date: Sun, 14 Jan 2018 02:46:18 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515897978.25.0.467229070634.issue32516@psf.upfronthosting.co.za>


xoviat <xoviat at gmail.com> added the comment:

My current plan is to patch the __init__ package files to add the '.libs' folder to the search path. However, I think it would be better for Python to do this so that there is a consistent mechanism for loading shared libraries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sat Jan 13 22:52:39 2018
From: report at bugs.python.org (Jay Crotts)
Date: Sun, 14 Jan 2018 03:52:39 +0000
Subject: [issue8243] curses writing to window's bottom right position raises:
 `_curses.error: addstr() returned ERR'
In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za>
Message-ID: <1515901959.52.0.467229070634.issue8243@psf.upfronthosting.co.za>


Change by Jay Crotts <crotts.jay at gmail.com>:


----------
keywords: +patch
pull_requests: +5031
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8243>
_______________________________________

From report at bugs.python.org  Sun Jan 14 02:51:41 2018
From: report at bugs.python.org (Johannes)
Date: Sun, 14 Jan 2018 07:51:41 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
 Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1515916301.01.0.467229070634.issue6766@psf.upfronthosting.co.za>


Johannes <johannes.jaegers at gmx.de> added the comment:

Hi all, I'm trying to use multiprocessing with a 3d list. From the documentation I expected it to work. As I found this report a bid later, I opened a bug report here: https://bugs.python.org/issue32538. Am I doing sth. wrong or is it still not working in 3.6.3?

----------
nosy: +John_81

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Sun Jan 14 04:31:14 2018
From: report at bugs.python.org (Paul Rudin)
Date: Sun, 14 Jan 2018 09:31:14 +0000
Subject: [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1515922274.97.0.467229070634.issue17972@psf.upfronthosting.co.za>


Paul Rudin <paul at rudin.co.uk> added the comment:

Although formatannotation is undocumented, its actually documented as a default value for one of the parameters of formatargspec, so it does form part of the module's public interface. However formatargspec is deprecated, so it's still OK to deprecate formatannotation.

formatannotation is also used as a helper within Parameter, which isn't deprecated, but the public interface or docs of Parameter don't mention formatannotation, so using _formatannotation instead is fine.

Since I've looked through this and, as far as I can tell, nobody is working on it, I'll make the changes and make a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Sun Jan 14 05:39:47 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 14 Jan 2018 10:39:47 +0000
Subject: [issue32549] Travis: Test with OpenSSL 1.1.0
Message-ID: <1515926387.7.0.467229070634.issue32549@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

For several planned features and security improvements, at least OpenSSL 1.0.2 is required. OpenSSL 1.1.0 is preferred to test all new features. See discussion https://mail.python.org/pipermail/python-dev/2018-January/151718.html . However Travis CI uses Ubuntu 14.04 LTS, which comes with OpenSSL 1.0.1.

To address the problem, CPython has either to compile and install a local copy of OpenSSL, move to container-based testing or use a different CI provider with more recent infrastructure.

I have created a PR that uses an improved version of my multissl test helper to compile and install the latest copy of OpenSSL 1.1.0. The build is cached by Travis. I *think* it is necessary to build OpenSSL in master so PRs can use the cache. A daily Travis cron job on master should do the trick.

----------
messages: 309916
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Travis: Test with OpenSSL 1.1.0
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32549>
_______________________________________

From report at bugs.python.org  Sun Jan 14 05:43:04 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 14 Jan 2018 10:43:04 +0000
Subject: [issue32549] Travis: Test with OpenSSL 1.1.0
In-Reply-To: <1515926387.7.0.467229070634.issue32549@psf.upfronthosting.co.za>
Message-ID: <1515926584.67.0.467229070634.issue32549@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +5033

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32549>
_______________________________________

From report at bugs.python.org  Sun Jan 14 05:57:09 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Sun, 14 Jan 2018 10:57:09 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1515927429.68.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

I managed to tune an i7700k desktop running Ubuntu 17.10 per this doc[1], and ran the pyperformance benchmarks[2].
I also tried various threshold with this benchmark and 16 still seems to be the sweet spot.
The geometric mean of the relative changes across all benchmarks indicates a 12.85% improvement.

[1]: http://pyperformance.readthedocs.io/usage.html#how-to-get-stable-benchmarks
[2]: https://gist.github.com/jeethu/4d9a8bd3eecbd067c00f085f7d2e7595

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Sun Jan 14 07:05:38 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Jan 2018 12:05:38 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
Message-ID: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The STORE_ANNOTATION bytecode is used to implement annotations.
The code 
     name : ann
is equivalent to 
    __annotations__['name'] = ann        

Consequently,
    STORE_ANNOTATION name

can be trivially replaced with 
    LOAD_NAME  __annotations__
    LOAD_CONST 'name'
    STORE_SUBSCR

----------
components: Interpreter Core
messages: 309918
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: STORE_ANNOTATION bytecode is unnecessary and can be removed.
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 07:18:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Jan 2018 12:18:20 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515932300.97.0.467229070634.issue32550@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +gvanrossum, levkivskyi, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 07:29:48 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Jan 2018 12:29:48 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515932988.87.0.467229070634.issue32550@psf.upfronthosting.co.za>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +5034
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 07:30:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Jan 2018 12:30:18 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515933018.1.0.467229070634.issue32550@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There some subtle differences.

1. Unlike to LOAD_NAME, STORE_ANNOTATION doesn't fall back to globals if '__annotations__' is not found in locals. The behavior difference is shown by the following example:

    x: int
    class A:                                                                                                                                                                                                                    
        del __annotations__                                                                                                                                                                                                                    
        y: int

2. The single STORE_ANNOTATION is faster than 3 other opcodes.

3. It doesn't add a name constant. Instead it uses a name from the names list (which already has to contain this name).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 07:32:44 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 14 Jan 2018 12:32:44 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515933164.84.0.467229070634.issue32550@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

There are several corner cases. For example consider this code:

>>> class C:
...     del __annotations__
...     x: int

Currently this correctly raises NameError, with your replacement it will instead stick {'x': int} in the module `__annotations__`. I think there may be other special cases but I don't remember them now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 07:56:32 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Jan 2018 12:56:32 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515934592.32.0.467229070634.issue32550@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

PEP 526 explicitly states
"as with all dunder attributes, any undocummented use of __annotations__ is subject to breakage without warning"

I consider deleting __annotations__ to be undocumented use.

Do you really think that an obscure difference in the behaviour of 

>>> class C:
...     del __annotations__
...     x: int

justifies an extra bytecode, but the implicit return at the end of all functions (LOAD_CONST None; RETURN_VALUE) does not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 08:18:18 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Jan 2018 13:18:18 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515935898.56.0.467229070634.issue32550@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

> 3. It doesn't add a name constant. Instead it uses a name from the names list (which already has to contain this name).

This PR moves the constant for the name from `co_names` to `co_consts`. There is no duplication.
>>> def f():
...    class C:
...       a : 1
(It does add __annotations__ to `co_names`, but that seems reasonable to me)

Current:
>>> f.__code__.co_consts[1].co_names
('__name__', '__module__', '__qualname__', 'a')
>>> f.__code__.co_consts[1].co_consts
('f.<locals>.C', 1, None)
With PR 5181:
>>> f.__code__.co_consts[1].co_names
('__name__', '__module__', '__qualname__', '__annotations__')
>>> f.__code__.co_consts[1].co_consts
('f.<locals>.C', 1, 'a', None)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 08:33:27 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 14 Jan 2018 13:33:27 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515936807.97.0.467229070634.issue32550@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

There is also another corner case to consider:

class C:
    exec('x: int')

assert C.__annotations__ == {'x': int}
assert __annotations__ == {}

I am not sure this one will be covered correctly.
But the main argument here is speed I think.

Let us see what others think about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 08:41:00 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Jan 2018 13:41:00 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515937260.85.0.467229070634.issue32550@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Works as expected:

>>> class C:
...     exec('x: int')
... 
>>> C.__annotations__
{'x': <class 'int'>}
>>> __annotations__
{}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 10:53:57 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 14 Jan 2018 15:53:57 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
Message-ID: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

The issue that I reported in https://bugs.python.org/issue29723 is now affecting 3.5.4:


```
$ pwd
/Users/ned/foo
$ tree syspathmain
syspathmain
??? __main__.py

0 directories, 1 file
$ cat syspathmain/__main__.py
import sys
print("-" * 20)
print(sys.version)
print("\n".join(sys.path))
$ for pyth in /usr/local/pythonz/pythons/CPython-*/bin/python; do $pyth syspathmain; done
/usr/local/pythonz/pythons/CPython-2.4.6/bin/python: 'syspathmain' is a directory, cannot continue
--------------------
2.6.9 (unknown, Jun 18 2016, 17:45:44)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python26.zip
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-darwin
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-mac
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-tk
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-old
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-dynload
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/site-packages
--------------------
2.7.10 (default, Jun 18 2016, 18:30:12)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/site-packages
--------------------
2.7.11 (default, Jun 18 2016, 17:51:44)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/site-packages
--------------------
2.7.12 (default, Nov 20 2016, 16:53:49)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/site-packages
--------------------
2.7.13 (default, Dec 17 2016, 16:51:07)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/site-packages
--------------------
2.7.13rc1 (default, Dec  4 2016, 15:34:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/site-packages
--------------------
2.7.14 (default, Oct  4 2017, 09:45:53)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/site-packages
--------------------
2.7.14rc1 (default, Aug 27 2017, 08:01:38)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/site-packages
--------------------
3.1.5 (default, Jun 18 2016, 17:54:07)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python31.zip
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1/plat-darwin
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1/lib-dynload
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1/site-packages
--------------------
3.2.6 (default, Jun 18 2016, 17:56:34)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python32.zip
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2/plat-darwin
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2/lib-dynload
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2/site-packages
--------------------
3.3.6 (default, Jun 18 2016, 17:58:30)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python33.zip
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3/plat-darwin
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3/lib-dynload
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3/site-packages
--------------------
3.4.3 (default, Jun 18 2016, 22:29:43)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4/site-packages
--------------------
3.4.4 (default, Jun 18 2016, 18:00:41)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4/site-packages
--------------------
3.4.5 (default, Jun 27 2016, 09:25:27)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4/site-packages
--------------------
3.4.6 (default, Jan 17 2017, 05:32:05)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4/site-packages
--------------------
3.4.6rc1 (default, Jan  3 2017, 06:13:09)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4/site-packages
--------------------
3.5.1 (default, Jun 18 2016, 17:20:31)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5/site-packages
--------------------
3.5.2 (default, Jun 27 2016, 13:24:47)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5/site-packages
--------------------
3.5.3 (default, Jan 17 2017, 05:34:29)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5/site-packages
--------------------
3.5.3rc1 (default, Jan  3 2017, 06:16:13)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5/site-packages
--------------------
3.5.4 (default, Jan  7 2018, 17:59:30)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
syspathmain
/Users/ned/foo
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5/site-packages
--------------------
3.6.0 (default, Dec 23 2016, 07:11:25)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/site-packages
--------------------
3.6.0a1 (default, Jun 18 2016, 17:17:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6/plat-darwin
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6/site-packages
--------------------
3.6.0a2 (default, Jun 19 2016, 07:45:01)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6/plat-darwin
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6/site-packages
--------------------
3.6.0a3 (default, Jul 12 2016, 08:17:28)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6/plat-darwin
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6/site-packages
--------------------
3.6.0b1 (default, Sep 12 2016, 20:38:35)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python3.6/site-packages
--------------------
3.6.0b2 (default, Oct 10 2016, 21:30:05)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python3.6/site-packages
--------------------
3.6.0b3 (default, Nov  1 2016, 05:07:34)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python3.6/site-packages
--------------------
3.6.0b4 (default, Nov 22 2016, 06:27:47)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python3.6/site-packages
--------------------
3.6.0rc1 (default, Dec  7 2016, 06:45:00)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python3.6/site-packages
--------------------
3.6.0rc2 (default, Dec 17 2016, 07:50:27)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python3.6/site-packages
--------------------
3.6.1 (default, Mar 22 2017, 05:30:11)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python3.6/site-packages
--------------------
3.6.1rc1 (default, Mar  5 2017, 08:02:03)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/Users/ned/foo
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python3.6/site-packages
--------------------
3.6.2 (default, Jul 17 2017, 07:05:09)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python3.6/site-packages
--------------------
3.6.2rc1 (default, Jun 18 2017, 16:38:24)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python3.6/site-packages
--------------------
3.6.2rc2 (default, Jul  8 2017, 07:07:22)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python3.6/site-packages
--------------------
3.6.3 (default, Oct  4 2017, 06:03:25)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python3.6/site-packages
--------------------
3.6.4 (default, Dec 19 2017, 08:11:42)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python3.6/site-packages
--------------------
3.6.4rc1 (default, Dec  6 2017, 06:09:07)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.38)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python3.6/site-packages
--------------------
3.7.0a1 (default, Sep 20 2017, 06:16:54)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python3.7/site-packages
--------------------
3.7.0a2 (default, Oct 17 2017, 15:40:05)
[Clang 9.0.0 (clang-900.0.38)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python3.7/site-packages
--------------------
3.7.0a3 (default, Jan 13 2018, 20:06:18)
[Clang 9.0.0 (clang-900.0.39.2)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python3.7/site-packages
--------------------
3.7.0a4 (default, Jan 10 2018, 19:19:56)
[Clang 9.0.0 (clang-900.0.39.2)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python3.7/site-packages
$
```

----------
keywords: 3.5regression
messages: 309925
nosy: nedbat
priority: normal
severity: normal
status: open
title: 3.5.4 has a regression that was fixed in 3.6.1rc1
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Sun Jan 14 10:55:13 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 14 Jan 2018 15:55:13 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1515945313.01.0.467229070634.issue32551@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

(For clarity)

The problem is that 3.5.4 adds the current directory to sys.path when running a subdirectory's __main__.py.  No other version of Python does this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Sun Jan 14 10:58:47 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Jan 2018 15:58:47 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1515945527.3.0.467229070634.issue32551@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
dependencies: +3.6.1rc1 adds the current directory to sys.path when running a subdirectory's __main__.py; previous versions did not
nosy: +larry, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Sun Jan 14 11:36:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Jan 2018 16:36:18 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1515947778.95.0.467229070634.issue32226@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sorry, I know very small about this module to writing the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Sun Jan 14 12:21:48 2018
From: report at bugs.python.org (Joongi Kim)
Date: Sun, 14 Jan 2018 17:21:48 +0000
Subject: [issue32526] Closing async generator while it is running does not
 raise an exception
In-Reply-To: <1515577162.33.0.467229070634.issue32526@psf.upfronthosting.co.za>
Message-ID: <1515950508.68.0.467229070634.issue32526@psf.upfronthosting.co.za>


Change by Joongi Kim <daybreaker12 at gmail.com>:


----------
keywords: +patch
pull_requests: +5035
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32526>
_______________________________________

From report at bugs.python.org  Sun Jan 14 13:15:19 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jan 2018 18:15:19 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1515953719.38.0.467229070634.issue32534@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The result likely varies quite a bit from compiler-to-compiler and processor-to-processor and os-to-os.   It is may also be affected by data size and caching.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Sun Jan 14 13:19:00 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jan 2018 18:19:00 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1515953940.15.0.467229070634.issue32550@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would like to see this patch go forward.  Making __annotations__ special and subtly different just adds to language complexity.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 13:19:03 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 14 Jan 2018 18:19:03 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1515891463.34.0.467229070634.issue29708@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W63H8Bm4x2m_m9ZmCR54Dr=UapzvnkQehZP1-Fh9Qec7g@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

As Eli's comments are coming off as negative to/at me, I feel like I have
to defend myself here. If you look at the commit there was actually two
places where the timestamp was checked; one did an equality comparison and
one did a >= comparison. It's quite possible the semantics accidentally
changed as part of the refactoring due to the check being done in different
places and a different one was copied, although no one has even noticed
until now.

If there is a desire to change the semantics of how timestamps are checked
then that should be done in a separate issue as at this point we have lived
with the current semantics for several releases -- all releases of Python 3
still receiving security updates -- so it's passed being a bug and is now
the semantics in Python 3.

On Sat, Jan 13, 2018, 16:57 Eli Schwartz, <report at bugs.python.org> wrote:

>
> Eli Schwartz <eschwartz93 at gmail.com> added the comment:
>
> So, a couple of things.
>
> It seems to me, that properly supporting SOURCE_DATE_EPOCH means using
> exactly that and nothing else. To that end, I'm not entirely sure why
> things like --clamp-mtime even exist, as the original timestamp of a source
> file doesn't seem to have a lot of utility and it is better to be entirely
> predictable. But I'm not going to argue that, except insomuch as it seems
> IMHO to fit better for python to just keep things simple and override the
> timestamp with the value of SOURCE_DATE_EPOCH
>
> That being said, I see two problems with python implementing something
> analogous to --clamp-mtime rather than just --mtime.
>
>
> 1) Source files are extracted by some build process, and remain untouched.
> Python generates bytecode pinned to the original time, rather than
> SOURCE_DATE_EPOCH. Later, the build process packages those files and
> implements --mtime, not --clamp-mtime. Because Python and the packaging
> software disagree about which one to use, the bytecode fails.
>
> 2) Source files are extracted, and the build process even tosses all
> timestamps to the side of the road, by explicitly `touch`ing all of them to
> the date of SOURCE_DATE_EPOCH just in case. Then for whatever reason
> (distro patches, 2to3, the use of `cp`) the timestamps get updated to
> $currentime. But SOURCE_DATE_EPOCH is in the future, so the timestamps get
> downdated. Python bytecode is generated by emulating --clamp-mtime. The
> build process then uses --mtime to package the files. Again, because Python
> and the packaging software disagree about which one to use, the bytecode
> fails.
>
> Of course, in both those cases, blindly respecting SOURCE_DATE_EPOCH will
> seemingly break everything for people who use --clamp-mtime instead. I'm
> not happy with reproducible-builds.org for allowing either one.
>
> I don't think python should rely on --mtime users manually overriding the
> filesystem metadata of the source files outside of py_compile, as that is a
> hack that I think we'd like to remove if possible... that being said, Arch
> Linux will, on second thought, not be adversely affected even if py_compile
> tries to be clever and emulate --clamp-mtime to decide on its own whether
> to respect SOURCE_DATE_EPOCH.
>
> Likewise, I don't really expect people to try to reproduce builds using a
> future date for SOURCE_DATE_EPOCH. On the other hand, the reproducible
> builds spec doesn't forbid it AFAICT.
>
> But... neither of those mitigations seem "clean" to me, for the reasons
> stated above.
>
> There is something that would solve all these issues, though. From reading
> the importlib code (I haven't actually tried smoketesting actual imports),
> it appears that Python 2 accepts any bytecode that is dated at or later
> than the timestamp of its source .py, while Python 3 requires the
> timestamps to perfectly match. This seems bizarre to behave differently,
> especially as until @bmwiedemann mentioned it on the GitHub PR I blindly
> assumed that Python would not care if your bytecode is somehow dated later
> than your sources. If the user is playing monkey games with mismatched
> source and byte code, while backdating the source code to *trick* the
> interpreter into loading it... let them? They can break their stuff if they
> want to!
>
> On looking through the commit logs, it seems that Python 3 used to do the
> same, until
> https://github.com/python/cpython/commit/61b14251d3a653548f70350acb250cf23b696372
> refactored the general vicinity and modified this behavior without warning.
> In a commit that seems to be designed to do something else entirely. This
> really should have been two separate commits, and modifying the import code
> to more strictly check the timestamp should have come with an explanatory
> justification. Because I cannot think of a good reason for this behavior,
> and the commit isn't giving me an opportunity to understand either. As it
> is, I am completely confused, and have no idea whether this was even
> supposed to be deliberate.
> In hindsight it is certainly preventing nice solutions to supporting
> SOURCE_DATE_EPOCH.
>
> ----------
> nosy: +eschwartz
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue29708>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Sun Jan 14 13:20:15 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jan 2018 18:20:15 +0000
Subject: [issue29476] Simplify set_add_entry()
In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za>
Message-ID: <1515954015.53.0.467229070634.issue29476@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 3329992e31bd0494a7d7312853f7ffd054737e27 by Raymond Hettinger in branch 'master':
bpo-29476: Simplify set_add_entry() (#5175)
https://github.com/python/cpython/commit/3329992e31bd0494a7d7312853f7ffd054737e27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29476>
_______________________________________

From report at bugs.python.org  Sun Jan 14 13:20:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jan 2018 18:20:36 +0000
Subject: [issue29476] Simplify set_add_entry()
In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za>
Message-ID: <1515954036.42.0.467229070634.issue29476@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29476>
_______________________________________

From report at bugs.python.org  Sun Jan 14 15:48:29 2018
From: report at bugs.python.org (Michael Felt)
Date: Sun, 14 Jan 2018 20:48:29 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1515962909.26.0.467229070634.issue28009@psf.upfronthosting.co.za>


Change by Michael Felt <michael at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +5037
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Sun Jan 14 15:49:35 2018
From: report at bugs.python.org (Michael Felt)
Date: Sun, 14 Jan 2018 20:49:35 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1515962975.0.0.467229070634.issue28009@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

PR added, please review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Sun Jan 14 15:58:09 2018
From: report at bugs.python.org (Michael Felt)
Date: Sun, 14 Jan 2018 20:58:09 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1515963488.99.0.467229070634.issue28009@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

FYI: - On AIX, no uuid_create support:

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.261s

OK (skipped=37)

On AIX 6.1 (with ctypes, without _uuid)

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.274s

OK (skipped=32)

On AIX 6.1 (with ctypes, with _uuid)

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.379s

OK (skipped=16)

+++

nohup ./python -m unittest -v test.test_uuid | grep skipped
test_arp_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'AIX arp does not provide MAC addr'
test_ifconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'AIX ifconfig does not provide MAC addr'
test_ip_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'requires win32wnet'
test_windll_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'requires Windows'
test_arp_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 'AIX arp does not provide MAC addr'
test_ifconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 'AIX ifconfig does not provide MAC addr'
test_ip_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 'requires win32wnet'
test_windll_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 'requires Windows'
test_uuid1_safe (test.test_uuid.TestUUIDWithExtModule) ... skipped 'requires uuid_generate_time_safe(3)'
test_uuid1_safe (test.test_uuid.TestUUIDWithoutExtModule) ... skipped 'requires uuid_generate_time_safe(3)'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Sun Jan 14 16:01:20 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Jan 2018 21:01:20 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1515963680.52.0.467229070634.issue28009@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is nohup required in the example you just posted or is that a red herring?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Sun Jan 14 16:53:49 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 21:53:49 +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: <1515966829.8.0.467229070634.issue26330@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5038
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Sun Jan 14 16:54:47 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 21:54: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: <1515966887.33.0.467229070634.issue26330@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
versions: +Python 3.7 -Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Sun Jan 14 16:55:03 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 21:55: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: <1515966903.27.0.467229070634.issue26330@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I've submitted a PR for the documentation change.

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Sun Jan 14 17:07:38 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 22:07:38 +0000
Subject: [issue15115] Duplicated Content-Transfer-Encoding header when
 applying email.encoders
In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>
Message-ID: <1515967658.65.0.467229070634.issue15115@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Barry/David,

Is this still a change you wanted to include in the documentation?


Thanks!

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15115>
_______________________________________

From report at bugs.python.org  Sun Jan 14 17:36:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 14 Jan 2018 22:36:42 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1515969402.11.0.467229070634.issue32516@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

The more details you reveal, the less I want it to be an officially supported pattern :)

Perhaps you actually want an import hook? Brett can confirm, but I believe you can overwrite __loader__ in a package and change how submodules are loaded.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sun Jan 14 18:07:47 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 23:07:47 +0000
Subject: [issue15221] os.path.is*() may return False if path can't be accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1515971267.65.0.467229070634.issue15221@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5039
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15221>
_______________________________________

From report at bugs.python.org  Sun Jan 14 18:11:24 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 23:11:24 +0000
Subject: [issue15221] os.path.is*() may return False if path can't be accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1515971484.47.0.467229070634.issue15221@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I created a PR for this by making the word 'existing' a link to 'os.path.exists' since Nick mentioned that that word already implied the definition.

----------
nosy: +csabella
versions: +Python 3.7 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15221>
_______________________________________

From report at bugs.python.org  Sun Jan 14 19:35:36 2018
From: report at bugs.python.org (elypter)
Date: Mon, 15 Jan 2018 00:35:36 +0000
Subject: [issue32552] Improve text for file arguments in
 argparse.ArgumentDefaultsHelpFormatter class
Message-ID: <1515976536.21.0.467229070634.issue32552@psf.upfronthosting.co.za>


New submission from elypter <elypter at yahoo.de>:

If you use formatter_class=argparse.ArgumentDefaultsHelpFormatter in the constructor then the defaults that you include in arguments get automatically added to the help text. this looks great for int and Strings but not for files.

example:
  -suffixes [SUFFIXES]
                        suffixes file which contains keywords that are often
                        the last part of a class or style name of a sticky bar
                        (default: <open file 'sources/suffixes.txt', mode 'r'
                        at 0xb71385f8>)

it should rather look like

  -suffixes [SUFFIXES]
                        suffixes file which contains keywords that are often
                        the last part of a class or style name of a sticky bar
                        (default:'sources/suffixes.txt')


the same holds probably true for more exotic datatypes. so an alternative or an addition could be to add an option to arguments to not add the default to the help text

----------
components: Library (Lib)
messages: 309940
nosy: elypter
priority: normal
severity: normal
status: open
title: Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32552>
_______________________________________

From report at bugs.python.org  Sun Jan 14 20:27:27 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 01:27:27 +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: <1515979647.28.0.467229070634.issue26330@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

This is the high-level shutil module, so why not try to use the resolved parent directory? For example:

    def disk_usage(path):
        try:
            total, free = nt._getdiskusage(path)
        except NotADirectoryError:
            path = os.path.dirname(nt._getfinalpathname(path))
            total, free = nt._getdiskusage(path)
        used = total - free
        return _ntuple_diskusage(total, used, free)

Also, as noted in msg260022, nt._getdiskusage was overlooked when implementing PEP 529. The same applies to nt._getfinalpathname and nt._getvolumepathname. nt._getfullpathname works with bytes because it takes an argument-clinic `path_t` instead of `unicode` or `Py_UNICODE`. I think the other 3 should be rewritten to use path_t, but it's out of scope for this issue.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Sun Jan 14 20:56:41 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 15 Jan 2018 01:56:41 +0000
Subject: [issue32542] memory not freed, aka memory leak continues...
In-Reply-To: <1515797312.96.0.467229070634.issue32542@psf.upfronthosting.co.za>
Message-ID: <95AD419D-703E-4E64-85ED-08CF61D8621F@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

Thanks for the clarification. 

Being curious, is there a way to see what the size of the cache is? I want to believe, but i do not have the impression memory is being reallocated to later users. My gut feeling is that the code change permits repeated calls to a function in a way that it reuses memory it received before (rather than a memory leak of repeatedly allocating a brand new buffer). What I expected, more accurately hoped for, is that cache was either freed and/or made available for reuse. 

Since I am on my phone atm I am less successful at finding documentation. I would be very grateful for a link to the relevant information and I?ll look further, time permitting. Thx again,

Michael 

Sent from my iPhone

> On 12 Jan 2018, at 23:48, Serhiy Storchaka <report at bugs.python.org> wrote:
> 
> 
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
> 
> Issue25582 fixed a memory leak. If run the tests repeatedly every iteration leaked 100 MB of memory. If you get a MemoryError with a single iteration, this means that your machine just doesn't have enough memory for tests. Tests require around 500-600MB of memory on 32-bit platform.
> 
> ----------
> nosy: +serhiy.storchaka
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32542>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32542>
_______________________________________

From report at bugs.python.org  Sun Jan 14 21:08:16 2018
From: report at bugs.python.org (Paul Watson)
Date: Mon, 15 Jan 2018 02:08:16 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
Message-ID: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>


New submission from Paul Watson <paul.hermeneutic at gmail.com>:

The 3.6.4 documentation on venv specifies using 'python3', but no python3 executable is in the 3.6.4 kit.

https://docs.python.org/3/library/venv.html?highlight=venv#module-venv

----------
assignee: docs at python
components: Documentation
messages: 309943
nosy: Paul Watson, docs at python
priority: normal
severity: normal
status: open
title: venv says to use python3 which does not exist in 3.6.4
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Sun Jan 14 23:03:03 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Jan 2018 04:03:03 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1515988983.07.0.467229070634.issue32551@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unfortunately, it looks like bpo-29319 was backported to the 3.5 branch, but not the follow-up fix from bpo-29723: https://github.com/python/cpython/commits/3.5/Modules/main.c

(The metadata on bpo-29319 indicated that the original change was targeted at 3.6+ only, and I didn't notice the message that mentioned the 3.5 branch, so I never even looked at 3.5 when working on bpo-29723 - I just assumed it wasn't affected)

Adding unexpected directories to sys.path can definitely be a security problem, so I think the fix should be backported for 3.5.5, but I'm also wondering whether it might be a significant enough regression to warrant an extra "Oops, sorry, we broke it" binary release. (We don't have any good usage numbers on how often folks use directory execution vs other forms of execution, so we don't know how widespread any impact is likely to be)

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Sun Jan 14 23:35:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 04:35:36 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1515990936.26.0.467229070634.issue26163@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Bringing this tracker item back to life.  I've had more time to look at the this and the underlying problem was the high bits were not being shuffled back to impact lower bits.  By fixing this, all of the tests produce a greater number of distinct values than before.

----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Sun Jan 14 23:57:53 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 15 Jan 2018 04:57:53 +0000
Subject: [issue15221] os.path.is*() may return False if path can't be accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1515992273.91.0.467229070634.issue15221@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset b3dd18d4035803b50c65a434955966d1b3b1f363 by Mariatta (Cheryl Sabella) in branch 'master':
bpo-15221: Update os.path.is*() documentation (GH-5185)
https://github.com/python/cpython/commit/b3dd18d4035803b50c65a434955966d1b3b1f363


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15221>
_______________________________________

From report at bugs.python.org  Sun Jan 14 23:58:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Jan 2018 04:58:07 +0000
Subject: [issue15221] os.path.is*() may return False if path can't be accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1515992287.97.0.467229070634.issue15221@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5040

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15221>
_______________________________________

From report at bugs.python.org  Mon Jan 15 00:05:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 05:05:43 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1515992743.52.0.467229070634.issue26163@psf.upfronthosting.co.za>


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


----------
pull_requests: +5041
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Mon Jan 15 00:08:39 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 15 Jan 2018 05:08:39 +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: <1515992919.2.0.467229070634.issue26330@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset ee3b83547c6b0cac1da2cb44aaaea533a1d1bbc8 by Mariatta (Cheryl Sabella) in branch 'master':
bpo-26330: Update shutil.disk_usage() documentation (GH-5184)
https://github.com/python/cpython/commit/ee3b83547c6b0cac1da2cb44aaaea533a1d1bbc8


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Mon Jan 15 00:08:47 2018
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Jan 2018 05:08: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: <1515992927.96.0.467229070634.issue26330@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5042

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Mon Jan 15 00:14:48 2018
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 15 Jan 2018 05:14:48 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1515993288.64.0.467229070634.issue32551@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

As a reminder: I'm currently scheduled to tag Python 3.5.5rc1 on January 21st, 2018, aka about six days from now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Mon Jan 15 00:26:41 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 15 Jan 2018 05:26:41 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1515994001.36.0.467229070634.issue32553@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

People who has more than one Python versions installed will have python3.

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 00:44:51 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 15 Jan 2018 05:44:51 +0000
Subject: [issue15221] os.path.is*() may return False if path can't be accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1515995091.34.0.467229070634.issue15221@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset bb80645d06c16461b0b58d8983cd7fa6962ba3c6 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-15221: Update os.path.is*() documentation (GH-5185) (GH-5186)
https://github.com/python/cpython/commit/bb80645d06c16461b0b58d8983cd7fa6962ba3c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15221>
_______________________________________

From report at bugs.python.org  Mon Jan 15 00:46:30 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 15 Jan 2018 05:46:30 +0000
Subject: [issue15221] os.path.is*() may return False if path can't be accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1515995190.1.0.467229070634.issue15221@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15221>
_______________________________________

From report at bugs.python.org  Mon Jan 15 01:57:43 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 15 Jan 2018 06:57:43 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1515963680.52.0.467229070634.issue28009@psf.upfronthosting.co.za>
Message-ID: <011d9728-8e4b-da07-16b7-cb1bf1d7b6a5@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 14/01/2018 22:01, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Is nohup required in the example you just posted or is that a red herring?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue28009>
> _______________________________________
>
nohup is required (i.e., my lazy way!) to stream both stdout and stderr 
through the pipe. Perhaps, for this output nohup could have been 
omitted. But it became a habit while I was testing. Maybe a birthday 
herring :p

Working on the Windows issue (my mistake). Will be groping in the dark 
as I have no windows system to test on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Mon Jan 15 03:12:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Jan 2018 08:12:30 +0000
Subject: [issue32424] Synchronize copy methods between Python and C
 implementations of xml.etree.ElementTree.Element
In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za>
Message-ID: <1516003950.96.0.467229070634.issue32424@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> As discussed above, starting with msg309074, __deepcopy__() is being added to the Python implementation because it already exists in the C implementation.

Python implementation shouldn't copy all implementation details of the C implementation. This is cumbersome and often impossible. Both implementation should have the same behavior, and they do have.

> And additional tests have in fact uncovered further discrepancies between the Python and C implementations with regard to copying behavior.

What are these discrepancies?

In any case it is better to extend existing tests by adding missed checks than duplicate tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32424>
_______________________________________

From report at bugs.python.org  Mon Jan 15 03:28:03 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 08:28:03 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516004883.83.0.467229070634.issue26163@psf.upfronthosting.co.za>


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


----------
pull_requests:  -5041

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Mon Jan 15 03:46:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Jan 2018 08:46:04 +0000
Subject: [issue32542] memory not freed, aka memory leak continues...
In-Reply-To: <1515783394.33.0.467229070634.issue32542@psf.upfronthosting.co.za>
Message-ID: <1516005964.52.0.467229070634.issue32542@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Being curious, is there a way to see what the size of the cache is?

len(_pointer_type_cache)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32542>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:06:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 09:06:21 +0000
Subject: [issue32542] memory not freed, aka memory leak continues...
In-Reply-To: <1515783394.33.0.467229070634.issue32542@psf.upfronthosting.co.za>
Message-ID: <1516007181.19.0.467229070634.issue32542@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

ctypes test cases tearDown() may always clear _pointer_type_cache. Would it help?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32542>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:08:22 2018
From: report at bugs.python.org (Johnny Dude)
Date: Mon, 15 Jan 2018 09:08:22 +0000
Subject: [issue32554] random seed is not consistent when using tuples with a
 str element
Message-ID: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>


New submission from Johnny Dude <johnny.dude at gmail.com>:

When using a tuple that include a string the results are not consistent when invoking a new interpreter or process.

For example executing the following on a linux machine will yield different results:
python3.6 -c 'import random; random.seed(("a", 1)); print(random.random())"

Please note that the doc string of random.seed states: "Initialize internal state from hashable object."

Python documentation does not. (https://docs.python.org/3.6/library/random.html#random.seed)

This is very confusing, I hope you can fix the behavior, not the doc string.

----------
components: Extension Modules
messages: 309956
nosy: JohnnyD
priority: normal
severity: normal
status: open
title: random seed is not consistent when using tuples with a str element
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:13:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 09:13:25 +0000
Subject: [issue32554] random seed is not consistent when using tuples with a
 str element
In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>
Message-ID: <1516007605.67.0.467229070634.issue32554@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

random.seed(str) uses:

        if version == 2 and isinstance(a, (str, bytes, bytearray)):
            if isinstance(a, str):
                a = a.encode()
            a += _sha512(a).digest()
            a = int.from_bytes(a, 'big')

Whereas for other types, random.seed(obj) uses hash(obj), and hash is randomized by default in Python 3.

Yeah, the random.seed() documentation should describe the implementation and explain that hash(obj) is used and that the hash function is randomized by default:
https://docs.python.org/dev/library/random.html#random.seed

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, mark.dickinson, rhettinger, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:13:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 09:13:51 +0000
Subject: [issue32554] random.seed(tuple) uses the randomized hash function and
 so is not reproductible
In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>
Message-ID: <1516007631.04.0.467229070634.issue32554@psf.upfronthosting.co.za>


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


----------
title: random seed is not consistent when using tuples with a str element -> random.seed(tuple) uses the randomized hash function and so is not reproductible

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:38:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 09:38:41 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516009121.05.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Attached test_all_locales.py is a test suite for locale functions: os.strerror(), locale.localeconv(), time.strftime(). I tested it on Linux Fedora 27, FreeBSD 11.0 and macOS 10.13.2.

The test should always pass on Python 2.7. On Python 3.6 and the master branch with PR 5170, 2 tests on numeric localeconv() fail because Python uses the wrong encoding: see bpo-31900. master with PR 5170 now has less encoding bugs than Python 3.6.

----------
Added file: https://bugs.python.org/file47385/test_all_locales.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:45:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 09:45:56 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516009556.67.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 7ed7aead9503102d2ed316175f198104e0cd674c by Victor Stinner in branch 'master':
bpo-29240: Fix locale encodings in UTF-8 Mode (#5170)
https://github.com/python/cpython/commit/7ed7aead9503102d2ed316175f198104e0cd674c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:54:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 09:54:44 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516010084.94.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Update: I pushed a large change to fix locale encodings in bpo-29240: commit 7ed7aead9503102d2ed316175f198104e0cd674c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 05:09:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Jan 2018 10:09:05 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516010945.34.0.467229070634.issue26163@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

As far as I understand, the problem is that the value obtained by XORing hashes of elements has nonuniform distribution. Further transformations, either linear or nonlinear, as well as adding length, don't change the fact that the result of XORing contains less information than the number of bit in the hash word. The mathematically strong way of computing the hash of a frozenset is:

    hash(tuple(sorted(hash(x) for x in frozenset)))

Store all hash values into an array, sort them for getting rid of ordering, and make a hash of all concatenated hashes.

But this algorithm requires linear memory and have superlinear complexity. For practical purposes we need just makes the difference of the distribution from the uniform distribution small enough. Maybe the following algorithm could help:

    buckets = [0] * N
    for x in frozenset:
        h = hash(x)
        i = shuffle_bits1(h) % N
        buckets[i] ^= shuffle_bits2(h)
    return hash(tuple(buckets))

where shuffle_bits1() and shuffle_bits2() are functions that shuffle bits in different ways.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:08:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 11:08:21 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516014501.87.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oops lc_numeric.py contains a typo:

d = decimal.Decimal(1234)
print("Decimal.__format__: %a" % f"{i:n}")

=> it should be f"{d:n}"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:17:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 11:17:23 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516015043.3.0.467229070634.issue29240@psf.upfronthosting.co.za>


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


----------
pull_requests: +5043

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:20:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 11:20:42 +0000
Subject: [issue32555] Encoding issues with the locale encoding
Message-ID: <1516015242.77.0.467229070634.issue32555@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Python 3.6 doesn't use the right encoding in os.strerror(), time.stftime(), locale.localeconv(), time.tzname, etc. on macOS, FreeBSD and other platforms.

See my fix locale encodings in bpo-29240: commit 7ed7aead9503102d2ed316175f198104e0cd674c, and test_all_locales.py attached to bpo-29240.

See also the bpo-31900 for locale.localeconv() encoding issue when LC_NUMERIC encoding is different than the LC_CTYPE encoding.

----------
components: Unicode
messages: 309963
nosy: ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Encoding issues with the locale encoding
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32555>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:21:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 11:21:24 +0000
Subject: [issue32555] Encoding issues with the locale encoding
In-Reply-To: <1516015242.77.0.467229070634.issue32555@psf.upfronthosting.co.za>
Message-ID: <1516015284.57.0.467229070634.issue32555@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I'm not sure that locale.bindtextdomain() uses the right encoding neither. I propose the following fix:

diff --git a/Modules/_localemodule.c b/Modules/_localemodule.c
index 324b694b83..1de17d3620 100644
--- a/Modules/_localemodule.c
+++ b/Modules/_localemodule.c
@@ -555,7 +555,7 @@ PyIntl_bindtextdomain(PyObject* self,PyObject*args)
         PyErr_SetFromErrno(PyExc_OSError);
         return NULL;
     }
-    result = PyUnicode_DecodeLocale(current_dirname, NULL);
+    result = PyUnicode_DecodeFSDefault(current_dirname);
     Py_XDECREF(dirname_bytes);
     return result;
 }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32555>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:25:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 11:25:43 +0000
Subject: [issue32555] Encoding issues with the locale encoding
In-Reply-To: <1516015242.77.0.467229070634.issue32555@psf.upfronthosting.co.za>
Message-ID: <1516015543.79.0.467229070634.issue32555@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Another issue: _Py_DecodeUTF8Ex() creates surrogate pairs with 16-bit wchar_t (on Windows), whereas input bytes should be escaped. I'm quite sure that it's a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32555>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:50:18 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Jan 2018 11:50:18 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516017018.41.0.467229070634.issue31900@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Just FYI: LC_ALL has precedence over all other more specific LC_* settings:

http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html
http://man7.org/linux/man-pages/man7/locale.7.html

Please confirm the bug without having LC_ALL or LANG set. Thanks.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:54:33 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 15 Jan 2018 11:54:33 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1516017273.71.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5044

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:56:21 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 15 Jan 2018 11:56:21 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1516017381.94.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It's not just the headers. The shared library is now /usr/lib64/nsl/libnsl.so.2 instead of /usr/lib64/libnsl.so.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Mon Jan 15 07:02:37 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Jan 2018 12:02:37 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516017757.2.0.467229070634.issue32516@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

>From experience with doing something similar in egenix-pyopenssl, I recommend putting the DLLs into the same directory as the PYD file on Windows. If you want to be extra safe, you can explicitly load the DLL, but normally this is not needed.

On Linux and other OSes, it's best to dlopen() to explicitly load the lib, since rpath and OS search paths are not always reliable.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Mon Jan 15 07:04:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 12:04:08 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516017848.53.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Please confirm the bug without having LC_ALL or LANG set.

lc_numeric.py uses:

  locale.setlocale(locale.LC_ALL, "fr_FR")

Are you talking about that? What is the problem with this configuration?

I'm sure that there is a bug :-) You aren't able to reproduce it? What is your operating system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 07:37:28 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Jan 2018 12:37:28 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516019848.92.0.467229070634.issue31900@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I just wanted to note that the description and title may cause a wrong interpretation of what should happen:

If you first set LC_ALL and then one of the other categories such as LC_NUMERIC, locale C functions will still use the LC_ALL setting for everything. LC_NUMERIC does not override the LC_ALL setting.

I tested this on OpenSUSE and get the same wrong results. Apparently, locale.localeconv() does not respect the above order. That's a bug.

I'm not sure whether the OP's quoted behavior is a bug, though, since if the locale encoding is not UTF-8, you cannot really expect using UTF-8 numeric separators to output correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 07:52:30 2018
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 15 Jan 2018 12:52:30 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1516019848.92.0.467229070634.issue31900@psf.upfronthosting.co.za>
Message-ID: <20180115125219.GA20236@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

On Mon, Jan 15, 2018 at 12:37:28PM +0000, Marc-Andre Lemburg wrote:
> If you first set LC_ALL and then one of the other categories such as LC_NUMERIC, locale C functions will still use the LC_ALL setting for everything. LC_NUMERIC does not override the LC_ALL setting.

I have the exact same questions as Marc-Andre.  This is one of the reasons why I
blocked the _decimal change.  I don't fully understand the role of the new glibc,
since #7442 has existed for ages -- and it is a open question whether it is a bug
or not.

Both views are reasonable IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 07:56:33 2018
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Mon, 15 Jan 2018 12:56:33 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516020993.5.0.467229070634.issue29708@psf.upfronthosting.co.za>


Bernhard M. Wiedemann <pythonbugs at lsmod.de> added the comment:

I think, there is no single nice and clean solution with time-based .pyc files, but to get a whole distribution to build reproducibly, there are two other ways:

1) if the SOURCE_DATE_EPOCH environment variable is set,
make hash-based .pyc files the default.

2) instead of storing .py mtime in the .pyc header, use the .pyc's filesystem mtime value - also making it more available to users.
Not sure if this would have side-effects or cause regressions.

on the side-issue: IMHO checking exact mtimes is the right thing to do, because sometimes users will copy back old .py files and expect mismatching .pyc files to not be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Mon Jan 15 07:57:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 12:57:20 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516021040.7.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Marc-Andre Lemburg: "If you first set LC_ALL and then one of the other categories such as LC_NUMERIC, locale C functions will still use the LC_ALL setting for everything. LC_NUMERIC does not override the LC_ALL setting."

The root of this issue is https://bugzilla.redhat.com/show_bug.cgi?id=1484497#c0:

Petr Viktorin reproducer scripts uses Python locale.setlocale(), not environment variables:
https://gist.github.com/encukou/70b3d3f9ef3e29ac1dbc23a5f7bd6431
---
locale.setlocale(locale.LC_ALL, 'C.UTF-8')
locale.setlocale(locale.LC_NUMERIC, 'fr_FR.ISO8859-1')
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:05:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 13:05:27 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516021527.03.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Example of Fedora 27 and Python 3.6:

vstinner at apu$ env -i LC_NUMERIC=uk_UA.koi8u python3 -c 'import locale; print(locale.setlocale(locale.LC_ALL, "")); print(locale.getpreferredencoding(), ascii(locale.localeconv()["thousands_sep"]))'
LC_CTYPE=C.UTF-8;LC_NUMERIC=uk_UA.koi8u;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.6/locale.py", line 110, in localeconv
    d = _localeconv()
UnicodeDecodeError: 'locale' codec can't decode byte 0x9a in position 0: Invalid or incomplete multibyte or wide character

"env -i" starts Python in an empty environment. It seems like LC_CTYPE defaults to C.UTF-8 in this case.

* LC_CTYPE = C.UTF-8, encoding = UTF-8
* LC_NUMERIC = uk_UA.koi8u, encoding = KOI8-U


With my PR, it works:

vstinner at apu$ env -i LC_NUMERIC=uk_UA.koi8u ./python -c 'import locale; print(locale.setlocale(locale.LC_ALL, "")); print(locale.getpreferredencoding(), ascii(locale.localeconv()["thousands_sep"]))'
LC_CTYPE=C.UTF-8;LC_NUMERIC=uk_UA.koi8u;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C
UTF-8 '\xa0'

=> thousands_sep byte string b'\x9A' is decoded as the Uniode string '\xa0'.


vstinner at apu$ env -i LC_NUMERIC=uk_UA.koi8u ./python -c 'import locale; locale.setlocale(locale.LC_ALL, ""); print(ascii(f"{1234:n}"))'
'1\xa0234'

=> the number is properly formatted


vstinner at apu$ env -i LC_NUMERIC=uk_UA.koi8u ./python -c 'import locale; locale.setlocale(locale.LC_ALL, ""); print(f"{1234:n}")'
1?234

It's possible to display the result using print().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:13:44 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Jan 2018 13:13:44 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516022024.46.0.467229070634.issue31900@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ok, it seems that the C setlocale() itself does not follow the conventions set forth for environment variables:

http://pubs.opengroup.org/onlinepubs/7908799/xsh/setlocale.html

(see the example at the bottom)

So the behavior shown by Python's setlocale() is fine.

However, that still doesn't magically make this work:

locale.setlocale(locale.LC_ALL, 'C.UTF-8')
locale.setlocale(locale.LC_NUMERIC, 'fr_FR.ISO8859-1')

If LC_NUMERIC uses a different encoding than LC_ALL, there's really no surprise in having numeric formatting fail. localeconv() will output the set encoding for the numeric string conversion and Python will decode this using the locale encoding set by LC_ALL. If those two are different, you run into problems.

I would not consider this a bug in Python, but rather in the locale settings passed to setlocale().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:13:56 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 15 Jan 2018 13:13:56 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516022036.98.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Another case to consider is that if a class defines __eq__, Python will automatically set hash=False before the decorator gets involved. NOte to self: be sure to add a test case for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:14:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 13:14:07 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516022047.24.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The technical issue here is that the libc has no "stateless" function to process bytes and text with one specific locale. All functions rely on the *current* locales. To decode byte strings, we use mbstowcs(), and this function relies on the current LC_CTYPE locale, whereas decimal_point and thousands_sep should be decoded from the current LC_NUMERIC locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:18:27 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Jan 2018 13:18:27 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516022307.96.0.467229070634.issue31900@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Indeed. The major problem with all libc locale functions is that they are not thread safe. The GIL does help a bit protecting against corrupted data, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:19:37 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 15 Jan 2018 13:19:37 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516022377.02.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

See #32546 for the hash=None problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:20:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 13:20:26 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516022426.25.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I would not consider this a bug in Python, but rather in the locale settings passed to setlocale().

Past 10 years, I repeated to every single user I met that "Python 3 is right, your system setup is wrong". But that's a waste of time. People continue to associate Python3 and Unicode to annoying bugs, because they don't understand how locales work.

Instead of having to repeat to each user that "hum, maybe your config is wrong", I prefer to support this non convential setup and work as expected ("it just works"). With my latest implementation, setlocale() is only done when LC_CTYPE and LC_NUMERIC are different, which is the corner case which "shouldn't occur in practice".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:21:52 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Jan 2018 13:21:52 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516022512.94.0.467229070634.issue31900@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Sounds like a good compromise :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:59:15 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 15 Jan 2018 13:59:15 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1516024755.89.0.467229070634.issue11191@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

After even more years - I see the same test failing, just a bit different.

And, others....

in short:

./python Lib/test/test_distutils.py
...
Ran 245 tests in 10.337s

FAILED (errors=7, skipped=31)

I have managed to get this to:

FAILED (errors=1, skipped=37)

And this is still:

ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)

So, moving forward now.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Mon Jan 15 08:59:31 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 15 Jan 2018 13:59:31 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1516024771.9.0.467229070634.issue11191@psf.upfronthosting.co.za>


Change by Michael Felt <michael at felt.demon.nl>:


----------
versions: +Python 3.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:09:20 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 15 Jan 2018 14:09:20 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1516025360.57.0.467229070634.issue11191@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:16:39 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Jan 2018 14:16:39 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516025799.28.0.467229070634.issue32534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm quite surprised so many benchmarks would be speeded up so significantly by a list.insert() optimization (why a 27% speedup on computing digits of pi, or a 33% speedup on a N-body simulation?).  Are you sure the two executables are similarly compiled?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:32:19 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 15 Jan 2018 14:32:19 +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: <1516026739.05.0.467229070634.issue26330@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset fb8569e36f2629654d5bc9c7ba05978edce408f4 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-26330: Update shutil.disk_usage() documentation (GH-5184) (GH-5188)
https://github.com/python/cpython/commit/fb8569e36f2629654d5bc9c7ba05978edce408f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:33:33 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 15 Jan 2018 14:33:33 +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: <1516026813.23.0.467229070634.issue26330@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26330>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:44:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 14:44:00 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516027440.51.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I tested localeconv() with PR 4174 on FreeBSD:
--
locale.setlocale(locale.LC_ALL, "C")
locale.setlocale(locale.LC_NUMERIC, "ar_SA.UTF-8")
--

It works as expected, result:
--
decimal_point: '\u066b'
thousands_sep: '\u066c'
--

Compare it to Python 3.6 which returns mojibake, it seems like bytes are decoded from Latin1:
--
decimal_point: '\xd9\xab'
thousands_sep: '\xd9\xac'
--

Raw byte strings, Python 2.7:

* decimal_point: b'\xd9\xab'
* thousands_sep: b'\xd9\xac'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:46:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 14:46:06 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516027566.46.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Test on Linux (Fedora 27, glibc 2.26):

locale.setlocale(locale.LC_ALL, "fr_FR")
locale.setlocale(locale.LC_NUMERIC, "es_MX.utf8")

It works as expected, result:

decimal_point: '.'
thousands_sep: '\u2009'

Python 3.6 returns mojibake:

decimal_point: '.'
thousands_sep: '\xe2\x80\x89'

Python 2.7 raw strings, thousands_sep = b'\xE2\x80\x89'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:56:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 14:56:16 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516028176.8.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

On macOS 10.13.2, I failed to find any non-ASCII decimal_point or thousands_sep in localeconv(). I wrote a script to find all non-ASCII data in all locales:
https://github.com/vstinner/misc/blob/master/python/all_locales.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 09:58:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 14:58:04 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516028284.12.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset cb064fc2321ce8673fe365e9ef60445a27657f54 by Victor Stinner in branch 'master':
bpo-31900: Fix localeconv() encoding for LC_NUMERIC (#4174)
https://github.com/python/cpython/commit/cb064fc2321ce8673fe365e9ef60445a27657f54


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:22:10 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 15:22:10 +0000
Subject: [issue32556] support bytes paths in nt _getdiskusage,
 _getvolumepathname, and _getfinalpathname
Message-ID: <1516029730.24.0.467229070634.issue32556@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

In issue 26330 it was noted that nt._getdiskusage doesn't accept bytes paths. The same applies to nt._getvolumepathname and nt._getfinalpathname. Callers of these functions shouldn't have to manually implement PEP 529 UTF-8 support to handle input and output bytes paths. 

On the other hand, nt._getfullpathname works with a bytes path since it takes a `path_t` argument instead of `unicode` or `Py_UNICODE`. The above 3 functions could be rewritten to use `path_t` for the input path, and then encode the output path via PyUnicode_EncodeFSDefault if path->narrow is set.

----------
components: Library (Lib), Unicode, Windows
messages: 309990
nosy: eryksun, ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: support bytes paths in nt _getdiskusage, _getvolumepathname, and _getfinalpathname
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32556>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:23:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Jan 2018 15:23:32 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
In-Reply-To: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>
Message-ID: <1516029812.96.0.467229070634.issue32544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I considered the idea of implementing _PyObject_GetAttrWithoutError() for issue31572, but dropped it because the code simplification was too small. But if this has performance benefits I'm +1 to implementing it. I'll update my still open PRs to use this API.

----------
components: +Interpreter Core
nosy: +serhiy.storchaka
type:  -> performance
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:26:52 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 15:26:52 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path
Message-ID: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

Issue 26330 was resolved by documenting that shutil.disk_usage requires a directory. However, the shutil module is in a position to harmonize cross-platform behavior in ways that aren't normally possible or recommended in the low-level os module. To that end, the Windows implementation could retry calling nt._getdiskusage on the resolved parent directory in case of NotADirectoryError. For example:

    def disk_usage(path):
        try:
            total, free = nt._getdiskusage(path)
        except NotADirectoryError:
            path = os.path.dirname(nt._getfinalpathname(path))
            total, free = nt._getdiskusage(path)
        used = total - free
        return _ntuple_diskusage(total, used, free)

Alternatively, this could be addressed in the implementation of nt._getdiskusage itself.

----------
components: Library (Lib), Windows
messages: 309992
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: allow shutil.disk_usage to take a file path
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:40:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 15:40:01 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516030801.29.0.467229070634.issue31900@psf.upfronthosting.co.za>


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


----------
pull_requests: +5045

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:41:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 15:41:31 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516030891.81.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

lc_numeric.py contains a typo, used fixed lc_numeric2.py instead to test my PR 5191 which fixes decimal.Decimal.

----------
Added file: https://bugs.python.org/file47386/lc_numeric2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:51:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 15:51:32 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516031492.11.0.467229070634.issue31900@psf.upfronthosting.co.za>


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


----------
pull_requests: +5046

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:08:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 16:08:30 +0000
Subject: [issue32555] Encoding issues with the locale encoding
In-Reply-To: <1516015242.77.0.467229070634.issue32555@psf.upfronthosting.co.za>
Message-ID: <1516032510.37.0.467229070634.issue32555@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Example of bug on FreeBSD 11:

haypo at freebsd$ LC_ALL=C ./python -c 'import locale, os; locale.setlocale(locale.LC_ALL, "fr_FR.ISO8859-1"); print(ascii(os.strerror(2)))'

'Fichier ou r\udce9pertoire inexistant'

Expected result:

haypo at freebsd$ LC_ALL=fr_FR.ISO8859-1 ./python -c 'import locale, os; locale.setlocale(locale.LC_ALL, ""); print(ascii(os.strerror(2)))'

'Fichier ou r\xe9pertoire inexistant'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32555>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:40:20 2018
From: report at bugs.python.org (Tristan Colombo)
Date: Mon, 15 Jan 2018 16:40:20 +0000
Subject: [issue32558] Socketserver documentation : error in server example
Message-ID: <1516034420.52.0.467229070634.issue32558@psf.upfronthosting.co.za>


New submission from Tristan Colombo <tristan.colombo at gmail.com>:

In the documentation, at page :
- https://docs.python.org/3.6/library/socketserver.html
- Section 21.21.4.1

In the server side code :
if __name__ == "__main__":
    HOST, PORT = "localhost", 9999

    # Create the server, binding to localhost on port 9999
    with socketserver.TCPServer((HOST, PORT), MyTCPHandler) as server:
    ...

We got an error line 24 :     
with socketserver.TCPServer((HOST, PORT), MyTCPHandler) as server:
AttributeError: __exit__

socketserver.TCPServer object has no __exit__() method and can not be used in 'with' statement.

Proposed correction :
server = socketserver.TCPServer((HOST, PORT), MyTCPHandler)
with server:
    ...

----------
assignee: docs at python
components: Documentation
messages: 309995
nosy: docs at python, tcolombo
priority: normal
severity: normal
status: open
title: Socketserver documentation : error in server example
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32558>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:43:42 2018
From: report at bugs.python.org (Tristan Colombo)
Date: Mon, 15 Jan 2018 16:43:42 +0000
Subject: [issue32558] Socketserver documentation : error in server example
In-Reply-To: <1516034420.52.0.467229070634.issue32558@psf.upfronthosting.co.za>
Message-ID: <1516034622.89.0.467229070634.issue32558@psf.upfronthosting.co.za>


Tristan Colombo <tristan.colombo at gmail.com> added the comment:

Correction of my previous correction :
server = socketserver.TCPServer((HOST, PORT), MyTCPHandler)

'with' statement can not be used...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32558>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:45:32 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Jan 2018 16:45:32 +0000
Subject: [issue32558] Socketserver documentation : error in server example
In-Reply-To: <1516034420.52.0.467229070634.issue32558@psf.upfronthosting.co.za>
Message-ID: <1516034732.68.0.467229070634.issue32558@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

In what environment are you trying this?  The example works for me (on a current macOS) system.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32558>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:51:12 2018
From: report at bugs.python.org (Tristan Colombo)
Date: Mon, 15 Jan 2018 16:51:12 +0000
Subject: [issue32558] Socketserver documentation : error in server example
In-Reply-To: <1516034420.52.0.467229070634.issue32558@psf.upfronthosting.co.za>
Message-ID: <1516035072.9.0.467229070634.issue32558@psf.upfronthosting.co.za>


Tristan Colombo <tristan.colombo at gmail.com> added the comment:

Running on Debian Etch
Ok, my python3 was broken and links to python3.5.3
All my apologizes

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32558>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:52:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 16:52:15 +0000
Subject: [issue32555] Encoding issues with the locale encoding
In-Reply-To: <1516015242.77.0.467229070634.issue32555@psf.upfronthosting.co.za>
Message-ID: <1516035135.18.0.467229070634.issue32555@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5047
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32555>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:53:23 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 15 Jan 2018 16:53:23 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1516035203.27.0.467229070634.issue11191@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

a) Is this normal?

root at x065:[/data/prj/python/git/python3-3.7]./python -m unittest test.test_distutils

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

In short - at the start I had:

./python Lib/test/test_distutils.py 
...
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

That is now down to:
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)

There were two issues for search_cpp:
a) xlc -E needs -C to include comments in the output - this should be fixed
b) xlc -E does not accept -o as an argument - output must be to stdout, and sadly I am not clever enough to fix that. Help appreciated.

As is: the error was:

ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/unixccompiler.py", line 107, in preprocess
    self.spawn(pp_args)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/spawn.py", line 159, in _spawn_posix
    % (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'xlc_r' failed with exit status 40

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/tests/test_config_cmd.py", line 49, in test_search_cpp
    match = cmd.search_cpp(pattern='xxx', body='/* xxx */')
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/command/config.py", line 201, in search_cpp
    src, out = self._preprocess(body, headers, include_dirs, lang)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/command/config.py", line 124, in _preprocess
    self.compiler.preprocess(src, out, include_dirs=include_dirs)
  File "/data/prj/python/git/xlc-python3-3.7/Lib/distutils/unixccompiler.py", line 109, in preprocess
    raise CompileError(msg)
distutils.errors.CompileError: command 'xlc_r' failed with exit status 40

and it is now:
======================================================================
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.7/Lib/distutils/tests/test_config_cmd.py", line 49, in test_search_cpp
    match = cmd.search_cpp(pattern='xxx', body='/* xxx */')
  File "/data/prj/python/git/python3-3.7/Lib/distutils/command/config.py", line 206, in search_cpp
    file = open(out)
FileNotFoundError: [Errno 2] No such file or directory: '_configtest.i'

*********
The code I do not know how to fix is:

File: Lib/distutils/command/config.py
    def _preprocess(self, body, headers, include_dirs, lang):
        src = self._gen_temp_sourcefile(body, headers, lang)
        out = "_configtest.i"
        self.temp_files.extend([src, out])
        self.compiler.preprocess(src, out, include_dirs=include_dirs)
        return (src, out)

See https://github.com/aixtools/cpython/tree/bpo-11191 for my changes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Mon Jan 15 12:04:47 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Jan 2018 17:04:47 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516035887.25.0.467229070634.issue32553@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Unfortunately, it may depend on what environment and/or from which distributor you obtain Python 3.6 as to whether there is a "python3" link installed.  On Unix-like systems, the default Python installation built from source ("make install") does install both "python3.6" and "python3" links in the configured "bin" directory.  But that may not be true everywhere.  On what environment are you running Python 3.6 and from where was it installed?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 12:08:43 2018
From: report at bugs.python.org (Paul Watson)
Date: Mon, 15 Jan 2018 17:08:43 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516036123.33.0.467229070634.issue32553@psf.upfronthosting.co.za>


Paul Watson <paul.hermeneutic at gmail.com> added the comment:

I am running 3.6.4 from a download on pythong.org yesterday.

Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32

There is a python3.dll, but no python3 executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 12:09:20 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Jan 2018 17:09:20 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516036160.34.0.467229070634.issue32553@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 12:09:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Jan 2018 17:09:51 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516036191.73.0.467229070634.issue32553@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks! Pinging the Windows team.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 12:26:42 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Jan 2018 17:26:42 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1516037202.85.0.467229070634.issue31368@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

It seems to me there are two issues here:

1. What are the pros and cons of adding support for this new mode, e.g. are there any potential gotchas?

2. Assuming the result of 1 is we should go ahead, then omeone needs to generate a pull request including configure checks as necessary, doc changes and tests.

It's getting late in the game for inclusion in 3.7 with only 2 weeks left until feature freeze.

----------
components: +Library (Lib)
nosy: +ned.deily
stage:  -> needs patch
title: RWF_NONBLOCK -> Support asynchronous, non-blocking buffered reads (RWF_NONBLOCK)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Mon Jan 15 12:41:44 2018
From: report at bugs.python.org (Paul Moore)
Date: Mon, 15 Jan 2018 17:41:44 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516038104.44.0.467229070634.issue32553@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Actually, for Windows, the docs don't recommend "python3", they say:

"""
On Windows, invoke the venv command as follows:

c:\>c:\Python35\python -m venv c:\path\to\myenv
"""

This should probably be altered to say "py -m venv" (or maybe "py -3 -m venv", but I don't think that's really necessary), as using the launcher is less tied to having your PATH set, or using an explicit path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:01:51 2018
From: report at bugs.python.org (Varun Agrawal)
Date: Mon, 15 Jan 2018 18:01:51 +0000
Subject: [issue32559] logging - public function to get level from name
Message-ID: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>


New submission from Varun Agrawal <varagrawal at gmail.com>:

Currently, the logging module has a function `getLevelName` and directly accessing the `_nameToLevel` dict is poor practice bordering on non-pythonic.

It would be nice to have a simple method like `getNameLevel` in the module to retrieve the logger level given the name. This can then be used in things such as argument parsers so someone can pass in the logging level name and the logging level can be appropriately set.

----------
components: Library (Lib)
messages: 310005
nosy: varunagrawal
priority: normal
severity: normal
status: open
title: logging - public function to get level from name
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:19:48 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 18:19:48 +0000
Subject: [issue32554] random.seed(tuple) uses the randomized hash function and
 so is not reproductible
In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>
Message-ID: <1516040388.82.0.467229070634.issue32554@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:34:21 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Jan 2018 18:34:21 +0000
Subject: [issue32346] Speed up slot lookup for class creation
In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za>
Message-ID: <1516041261.43.0.467229070634.issue32346@psf.upfronthosting.co.za>


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


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32346>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:41:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 18:41:43 +0000
Subject: [issue32554] random.seed(tuple) uses the randomized hash function and
 so is not reproductible
In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>
Message-ID: <1516041703.0.0.467229070634.issue32554@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm getting a nice improvement in dispersion statistics by shuffling in higher bits right at the end:

     /* Disperse patterns arising in nested frozensets */
  +  hash ^= (hash >> 11) ^ (~hash >> 25);
     hash = hash * 69069U + 907133923UL;

Results for range() check:

                     range       range
                    baseline      new
  1st percentile     35.06%      40.63%
  1st decile         48.03%      51.34%
  mean               61.47%      63.24%      
  median             63.24%      65.58% 

Test code for the letter_range() test:

                     letter      letter
                    baseline      new
  1st percentile     39.59%      40.14%
  1st decile         50.90%      51.07%
  mean               63.02%      63.04%      
  median             65.21%      65.23% 


    def letter_range(n):
        return string.ascii_letters[:n]

    def powerset(s):
        for i in range(len(s)+1):
            yield from map(frozenset, itertools.combinations(s, i))

    # range() check
    for i in range(10000):
        for n in range(5, 19):
            t = 2 ** n
            mask = t - 1
            u = len({h & mask for h in map(hash, powerset(range(i, i+n)))})
            print(u/t*100)

    # letter_range() check needs to be restarted (reseeded on every run)
    for n in range(5, 19):
        t = 2 ** n
        mask = t - 1
        u = len({h & mask for h in map(hash, powerset(letter_range(n)))})
        print(u/t)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:42:46 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 18:42:46 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516041766.27.0.467229070634.issue26163@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Messages (3)
msg309956 - (view)	Author: Johnny Dude (JohnnyD)	Date: 2018-01-15 01:08
When using a tuple that include a string the results are not consistent when invoking a new interpreter or process.

For example executing the following on a linux machine will yield different results:
python3.6 -c 'import random; random.seed(("a", 1)); print(random.random())"

Please note that the doc string of random.seed states: "Initialize internal state from hashable object."

Python documentation does not. (https://docs.python.org/3.6/library/random.html#random.seed)

This is very confusing, I hope you can fix the behavior, not the doc string.
msg309957 - (view)	Author: STINNER Victor (vstinner) * (Python committer)	Date: 2018-01-15 01:13
random.seed(str) uses:

        if version == 2 and isinstance(a, (str, bytes, bytearray)):
            if isinstance(a, str):
                a = a.encode()
            a += _sha512(a).digest()
            a = int.from_bytes(a, 'big')

Whereas for other types, random.seed(obj) uses hash(obj), and hash is randomized by default in Python 3.

Yeah, the random.seed() documentation should describe the implementation and explain that hash(obj) is used and that the hash function is randomized by default:
https://docs.python.org/dev/library/random.html#random.seed
msg310006 - (view)	Author: Raymond Hettinger (rhettinger) * (Python committer)	Date: 2018-01-15 10:41
I'm getting a nice improvement in dispersion statistics by shuffling in higher bits right at the end:

     /* Disperse patterns arising in nested frozensets */
  +  hash ^= (hash >> 11) ^ (~hash >> 25);
     hash = hash * 69069U + 907133923UL;

Results for range() check:

                     range       range
                    baseline      new
  1st percentile     35.06%      40.63%
  1st decile         48.03%      51.34%
  mean               61.47%      63.24%      
  median             63.24%      65.58% 

Test code for the letter_range() test:

                     letter      letter
                    baseline      new
  1st percentile     39.59%      40.14%
  1st decile         50.90%      51.07%
  mean               63.02%      63.04%      
  median             65.21%      65.23% 


    def letter_range(n):
        return string.ascii_letters[:n]

    def powerset(s):
        for i in range(len(s)+1):
            yield from map(frozenset, itertools.combinations(s, i))

    # range() check
    for i in range(10000):
        for n in range(5, 19):
            t = 2 ** n
            mask = t - 1
            u = len({h & mask for h in map(hash, powerset(range(i, i+n)))})
            print(u/t*100)

    # letter_range() check needs to be restarted (reseeded on every run)
    for n in range(5, 19):
        t = 2 ** n
        mask = t - 1
        u = len({h & mask for h in map(hash, powerset(letter_range(n)))})
        print(u/t)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:43:56 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 18:43:56 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516041836.84.0.467229070634.issue26163@psf.upfronthosting.co.za>


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


----------
Removed message: https://bugs.python.org/msg310007

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:44:53 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 18:44:53 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516041893.07.0.467229070634.issue26163@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm getting a nice improvement in dispersion statistics by shuffling in higher bits right at the end:

     /* Disperse patterns arising in nested frozensets */
  +  hash ^= (hash >> 11) ^ (~hash >> 25);
     hash = hash * 69069U + 907133923UL;

Results for range() check:

                     range       range
                    baseline      new
  1st percentile     35.06%      40.63%
  1st decile         48.03%      51.34%
  mean               61.47%      63.24%      
  median             63.24%      65.58% 

Test code for the letter_range() test:

                     letter      letter
                    baseline      new
  1st percentile     39.59%      40.14%
  1st decile         50.90%      51.07%
  mean               63.02%      63.04%      
  median             65.21%      65.23% 


    def letter_range(n):
        return string.ascii_letters[:n]

    def powerset(s):
        for i in range(len(s)+1):
            yield from map(frozenset, itertools.combinations(s, i))

    # range() check
    for i in range(10000):
        for n in range(5, 19):
            t = 2 ** n
            mask = t - 1
            u = len({h & mask for h in map(hash, powerset(range(i, i+n)))})
            print(u/t*100)

    # letter_range() check needs to be restarted (reseeded on every run)
    for n in range(5, 19):
        t = 2 ** n
        mask = t - 1
        u = len({h & mask for h in map(hash, powerset(letter_range(n)))})
        print(u/t)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:45:16 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 18:45:16 +0000
Subject: [issue32554] random.seed(tuple) uses the randomized hash function and
 so is not reproductible
In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>
Message-ID: <1516041916.93.0.467229070634.issue32554@psf.upfronthosting.co.za>


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


----------
Removed message: https://bugs.python.org/msg310006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:46:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 18:46:17 +0000
Subject: [issue32554] random.seed(tuple) uses the randomized hash function and
 so is not reproductible
In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>
Message-ID: <1516041977.25.0.467229070634.issue32554@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> This is very confusing, I hope you can fix the behavior, not the doc string.

I'll fix the docstring to make it more specific.

We really don't want to use hash(obj) because it produces too few bits of entropy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 14:21:58 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jan 2018 19:21:58 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516044118.33.0.467229070634.issue26163@psf.upfronthosting.co.za>


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


----------
pull_requests: +5048

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Mon Jan 15 14:31:35 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 15 Jan 2018 19:31:35 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516044695.9.0.467229070634.issue29708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Bernhard's idea of SOURCE_DATE_EPOCH being an implicit envvar to forcibly switch on hash-based .pyc files in py_compile is intriguing. I assume this would force the check_source bit to be set? Or since SOURCE_DATE_EPOCH should only be used in build scenarios would you want UNCHECKED_HASH?

As the core dev who seems the most engaged and willing to commit this, I'm willing to make the final decision on this and commit the final PR. I see the options of getting this into 3.7 as the following:

1. SOURCE_DATE_EPOCH acts as an environment variable flag to forcibly generate hash-based .pyc files with the check_source bit set in py_compile and compileall
2. SOURCE_DATE_EPOCH is used to specifically set the timestamp in .pyc files in py_compile and compileall

That's it. No clamping, no changing how timestamp-based .pyc files are invalidated, no touching source files, etc.

If this is going to make it into Python 3.7 then a decision must be made by Friday, Jan 19, so have your opinions on those two options in before then (and in the case of the hash-based solution, would you expect CHECKED_HASH or UNCHECKED_HASH?). At that point I will make a decision and Bernhard can either update his PR or I can create a new one forked from his(I leave that up to Bernhard based on the decision I'll make on/by Friday).

----------
assignee:  -> brett.cannon
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Mon Jan 15 14:34:45 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 15 Jan 2018 19:34:45 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516044885.74.0.467229070634.issue32516@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

To answer Steve's question, what you would want is a finder which recognized the directory of the package so as to return a special loader just for that package (basically __path__ is sent through the normal import mechanism and so you would want something on sys.path_hooks which knew how to get an appropriate finder which would return the loader you want).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Mon Jan 15 14:41:19 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Jan 2018 19:41:19 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1516044695.9.0.467229070634.issue29708@psf.upfronthosting.co.za>
Message-ID: <2D0AB752-CCD9-4AC1-8F48-E2DC3EB81DB8@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 15, 2018, at 11:31, Brett Cannon <report at bugs.python.org> wrote:
> 
> 1. SOURCE_DATE_EPOCH acts as an environment variable flag to forcibly generate hash-based .pyc files with the check_source bit set in py_compile and compileall
> 2. SOURCE_DATE_EPOCH is used to specifically set the timestamp in .pyc files in py_compile and compileall

I?d suggest that if SDE is set to an integer, that is used as the timestamp.  If it?s set to a special symbol (e.g. ?hash?) then the hash is used.  I?m not volunteering to write the code though. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Mon Jan 15 14:43:31 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 15 Jan 2018 19:43:31 +0000
Subject: [issue15115] Duplicated Content-Transfer-Encoding header when
 applying email.encoders
In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>
Message-ID: <1516045411.06.0.467229070634.issue15115@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe so.  For python3 I think it should only apply to the legacy API docs (you would use set_content (directly or indirectly) in python3, not set_payload).  I've updated the versions.

----------
versions: +Python 3.6, Python 3.7 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15115>
_______________________________________

From report at bugs.python.org  Mon Jan 15 14:44:39 2018
From: report at bugs.python.org (bbayles)
Date: Mon, 15 Jan 2018 19:44:39 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1516045479.26.0.467229070634.issue32146@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
keywords: +patch
pull_requests: +5049
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Mon Jan 15 15:05:40 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Jan 2018 20:05:40 +0000
Subject: [issue14976] queue.Queue() is not reentrant,
 so signals and GC can cause deadlocks
In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>
Message-ID: <1516046740.42.0.467229070634.issue14976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi all,

The PR has been ready for quite some time now.  Raymond posted some review comments back in September, which I addressed by making the requested changes.

If someone wants to add their comments, now is the time. Otherwise I plan to merge the PR sometimes soon, so that it gets in before 3.7 beta.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14976>
_______________________________________

From report at bugs.python.org  Mon Jan 15 15:58:38 2018
From: report at bugs.python.org (Paul Watson)
Date: Mon, 15 Jan 2018 20:58:38 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516049918.73.0.467229070634.issue32553@psf.upfronthosting.co.za>


Paul Watson <paul.hermeneutic at gmail.com> added the comment:

Ok, I do find later on where it says to do something different on Windows. However, the first "Note" box in "28.3. venv" specifies using "python3". It does not say that this is for non-Windows systems. This should be changed.

Also, the path specified, "c:\Python35\python", would not be the default location for a Windows install. "C:\Program Files\Python36\python" or "C:\Program Files (x86)\Python36\python" should be specified.

I detest that it is this complex and verbose, but it is. Glossing over it does not help the user.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 16:25:15 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 21:25:15 +0000
Subject: [issue32560] inherit the py launcher's STARTUPINFO
Message-ID: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

I've occasionally seen requests to find the path of the LNK shortcut that was used to run a script -- for whatever reason. This can be reliably supported in most cases by calling WinAPI GetStartupInfo. If the flag STARTF_TITLEISLINKNAME is set, then the lpTitle field is the path to the LNK file. (This is how the console host process knows to use the shortcut file for its properties instead of the registry.)

However, if .py scripts are associated with the py launcher, the STARTUPINFO that has the required information is in the launcher process instead of the python.exe process. Since to some extent the launcher is acting as a proxy for python.exe, I think it should initialize Python's STARTUPINFO from a copy of its own values as returned by GetStartupInfo. This solves the dwFlags and lpTitle problem.

Additionally, the C runtime spawn family of functions supports inheriting file descriptors by passing them in the lpReserved2 field of STARTUPINFO. Currently this doesn't work when spawning Python via the launcher, since it calls CreateProcess instead of a spawn function. By inheriting the launcher's STARTUPINFO, this feature is restored as well. 

For example, in `run_child` in PC/launcher.c, I replaced `si.cb = sizeof(si)` with GetStartupInfoW(&si). Then I tested passing inherited file descriptors through the launcher as follows:

grandparent:

    >>> import os
    >>> os.pipe()
    (3, 4)
    >>> os.set_inheritable(4, True)
    >>> os.spawnl(os.P_WAIT, 'amd64/py_d.exe', 'py_d')

grandchild (py_d.exe => python.exe):

    Python 3.7.0a4 (v3.7.0a4:07c9d85, Jan  9 2018, 07:07:02)
    [MSC v.1900 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os
    >>> os.write(4, b'spam')
    4
    >>> ^Z

grandparent:

    0
    >>> os.read(3, 4)
    b'spam'

----------
components: Windows
keywords: easy (C)
messages: 310016
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: inherit the py launcher's STARTUPINFO
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32560>
_______________________________________

From report at bugs.python.org  Mon Jan 15 16:39:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Jan 2018 21:39:07 +0000
Subject: [issue32539] os.listdir(...) on deep path on windows in python2.7
 fails with errno 123
In-Reply-To: <1515776205.66.0.467229070634.issue32539@psf.upfronthosting.co.za>
Message-ID: <1516052347.12.0.467229070634.issue32539@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 27f32e938ff51fd5d90a29abbbabc6b81d156f33 by Serhiy Storchaka (Anthony Sottile) in branch '2.7':
bpo-32539: Fix OSError for os.listdir() for extended-length paths on Windows (#5169)
https://github.com/python/cpython/commit/27f32e938ff51fd5d90a29abbbabc6b81d156f33


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32539>
_______________________________________

From report at bugs.python.org  Mon Jan 15 16:40:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Jan 2018 21:40:26 +0000
Subject: [issue32539] os.listdir(...) on deep path on windows in python2.7
 fails with errno 123
In-Reply-To: <1515776205.66.0.467229070634.issue32539@psf.upfronthosting.co.za>
Message-ID: <1516052426.69.0.467229070634.issue32539@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Anthony for your patch!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32539>
_______________________________________

From report at bugs.python.org  Mon Jan 15 16:49:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Jan 2018 21:49:39 +0000
Subject: [issue32554] random.seed(tuple) uses the randomized hash function and
 so is not reproductible
In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>
Message-ID: <1516052979.02.0.467229070634.issue32554@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maybe deprecate using a hash?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 17:23:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 22:23:50 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1516055030.93.0.467229070634.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 5f959c4f9eca404b8bc4bc6348fed27c4b907b89 by Victor Stinner in branch '3.6':
[3.6] bpo-31900: Fix localeconv() encoding for LC_NUMERIC (#4174) (#5192)
https://github.com/python/cpython/commit/5f959c4f9eca404b8bc4bc6348fed27c4b907b89


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Jan 15 17:43:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 22:43:28 +0000
Subject: [issue32555] Encoding issues with the locale encoding
In-Reply-To: <1516015242.77.0.467229070634.issue32555@psf.upfronthosting.co.za>
Message-ID: <1516056207.99.0.467229070634.issue32555@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset b92c159efada05b3a5ff9d0dbce3fcb2334631f6 by Victor Stinner in branch '3.6':
[3.6] bpo-32555: Fix locale encodings (#5193)
https://github.com/python/cpython/commit/b92c159efada05b3a5ff9d0dbce3fcb2334631f6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32555>
_______________________________________

From report at bugs.python.org  Mon Jan 15 18:17:52 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Mon, 15 Jan 2018 23:17:52 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516058272.85.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

I rebased my branch off of master and rebuilt it, and also rebuilt the baseline from master. Both versions were configured with --with-lto and --enable-optimizations. The benchmark numbers are rather different this time[1]. pidigits is slower, but nbody is still inexplicably faster. Should I run the benchmark without a PGO build (i.e without --enable-optimizations)?

Also, I've attached the output from the pyperformance run to the aforementioned gist.

[1]: https://gist.github.com/jeethu/dc0811d415dd6d1a1621761e43842f88

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Mon Jan 15 18:19:44 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Jan 2018 23:19:44 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516058384.38.0.467229070634.issue32534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps the patch is interfering weirdly with PGO?

> Should I run the benchmark without a PGO build (i.e without --enable-optimizations)?

That would help clear things up, IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Mon Jan 15 18:20:02 2018
From: report at bugs.python.org (Paul Moore)
Date: Mon, 15 Jan 2018 23:20:02 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516058402.61.0.467229070634.issue32553@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

That's why I suggest using the launcher rather than absolute paths - there are far too many variations to enumerate with absolue paths (you didn't mention per-user Python 3.6 installations, for example).

If you have a suggested wording that you feel would explain things better, feel free to propose it. What's there at the moment seems relatively OK to me (aside from a minor tweak to use the launcher) so I'm not sure I could modify it in a way that would address your concerns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 18:27:18 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Jan 2018 23:27:18 +0000
Subject: [issue14976] queue.Queue() is not reentrant,
 so signals and GC can cause deadlocks
In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>
Message-ID: <1516058838.58.0.467229070634.issue14976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 94e1696d04c65e19ea52e5c8664079c9d9aa0e54 by Antoine Pitrou in branch 'master':
bpo-14976: Reentrant simple queue (#3346)
https://github.com/python/cpython/commit/94e1696d04c65e19ea52e5c8664079c9d9aa0e54


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14976>
_______________________________________

From report at bugs.python.org  Mon Jan 15 18:27:51 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Jan 2018 23:27:51 +0000
Subject: [issue14976] queue.Queue() is not reentrant,
 so signals and GC can cause deadlocks
In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>
Message-ID: <1516058871.0.0.467229070634.issue14976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, there has been enough reviews in the last four months :-) This is now merged.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14976>
_______________________________________

From report at bugs.python.org  Mon Jan 15 18:48:03 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 15 Jan 2018 23:48:03 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516060083.31.0.467229070634.issue32551@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Nick makes this sound like it really should land in 3.5.5, so marking as a release blocker for now.

----------
nosy: +brett.cannon
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Mon Jan 15 18:55:43 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 23:55:43 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516060543.62.0.467229070634.issue32553@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

`PATHEXT` is irrelevant here, so that should be removed. As to the py launcher, it's optional and not always installed for all users, though that's the default. I'd prefer `python` that's found in PATH as the first example. Then add another example with `py -X.Y` to show how to create virtual environments for other versions.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 19:08:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 00:08:03 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516061283.78.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> New changeset 7ed7aead9503102d2ed316175f198104e0cd674c by Victor Stinner in branch 'master':
> bpo-29240: Fix locale encodings in UTF-8 Mode (#5170)

Oh, this change broke test_nonascii() of test_readline() on FreeBSD.

Previsously, readline used ASCII/surrogateescape encoding for the POSIX locale. Now, mbstowcs() / wcstombs() is called directly, with the surrogateescape error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Mon Jan 15 19:40:26 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 00:40:26 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1516063226.4.0.467229070634.issue31368@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In any case, I think this would take the form of new low-level calls in the posix module, i.e. add thin wrappers around the new system / libc calls.

----------
nosy: +njs, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Mon Jan 15 20:44:13 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 16 Jan 2018 01:44:13 +0000
Subject: [issue32560] inherit the py launcher's STARTUPINFO
In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za>
Message-ID: <1516067053.46.0.467229070634.issue32560@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

This sounds like a good idea to me - feel free to contribute your PR.

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32560>
_______________________________________

From report at bugs.python.org  Mon Jan 15 21:07:22 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 02:07:22 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
Message-ID: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

Background: Doing I/O to files on disk has a hugely bimodal latency. If the I/O happens to be in or going to cache (either user-space cache, like in io.BufferedIOBase, or the OS's page cache), then the operation returns instantly (~1 ?s) without blocking. OTOH if the I/O isn't cached (for reads) or cacheable (for writes), then the operation may block for 10 ms or more.

This creates a problem for async programs that want to do disk I/O. You have to use a thread pool for reads/writes, because sometimes they block for a long time, and you want to let your event loop keep doing other useful work while it's waiting. But dispatching to a thread pool adds a lot of overhead (~100 ?s), so you'd really rather not do it for operations that can be serviced directly through cache. For uncached operations a thread gives a 100x speedup, but for cached operations it's a 100x slowdown, and -- this is the kicker -- there's no way to predict which ahead of time.

But, io.BufferedIOBase at least knows when it can satisfy a request directly from its buffer without issuing any syscalls. And in Linux 4.14, it's even possible to issue a non-blocking read to the kernel that will only succeed if the data is immediately available in page cache (bpo-31368).

So, it would be very nice if there were some way to ask a Python file object to do a "nonblocking read/write", which either succeeds immediately or else raises an error. The intended usage pattern would be:

async def read(self, *args):
    try:
        self._fileobj.read(*args, nonblock=True)
    except BlockingIOError: # maybe?
        return await run_in_worker_thread(self._fileobj.read, *args)

It would *really* help for this to be in the Python core, because right now the convenient way to do non-blocking disk I/O is to re-use the existing Python I/O stack, with worker threads. (This is how both aiofiles and trio's async file support work. I think maybe curio's too.) But to implement this feature ourselves, we'd have to first reimplement the whole I/O stack, because the important caching information, and choice of what syscall to use, are hidden inside.

----------
components: IO
messages: 310032
nosy: benjamin.peterson, njs, stutzbach
priority: normal
severity: normal
status: open
title: Add API to io objects for non-blocking reads/writes
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Mon Jan 15 21:09:07 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 02:09:07 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1516068547.49.0.467229070634.issue31368@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Whoa, cool.

bpo-32561 is complementary to this. (They both make sense on their own, but they're even better together.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Mon Jan 15 21:23:17 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 02:23:17 +0000
Subject: [issue32562] Support fspath protocol in AF_UNIX sockaddr resolution
Message-ID: <1516069397.77.0.467229070634.issue32562@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

In 3.6, trying to connect to a AF_UNIX socket using a pathlib.Path object doesn't work:

Python 3.6.4 (default, Dec 27 2017, 13:02:49) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, pathlib
>>> s = socket.socket(family=socket.AF_UNIX)
>>> s.connect(pathlib.Path("asdf"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: a bytes-like object is required, not 'PosixPath'

It would be good to fix this to use the fspath protocol.

----------
messages: 310034
nosy: brett.cannon, njs
priority: normal
severity: normal
status: open
title: Support fspath protocol in AF_UNIX sockaddr resolution
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32562>
_______________________________________

From report at bugs.python.org  Tue Jan 16 00:02:59 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Jan 2018 05:02:59 +0000
Subject: [issue32475] Add ability to query number of buffered bytes available
 on buffered I/O
In-Reply-To: <1514795505.19.0.467229070634.issue32475@psf.upfronthosting.co.za>
Message-ID: <1516078979.78.0.467229070634.issue32475@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

If I remember the implementation of ?peek? right, it may do what you want. But the documentation doesn?t guarantee much about its behaviour; see Issue 5811.

Anyway, I agree that a ?getbuffn? method (or property) would be nice. (Perhaps with a better name!) But please don?t add it to the abstract APIs like BufferedIOBase. It could break compatibility with third-party implementations, or make the API complicated with little benefit. Just extend the concrete APIs like BufferedReader.

Two other use cases where the ?peek? implementation won?t help, but ?getbuffn? would:

1. Issue 32561: Decide whether a non-blocking ?read? call is possible, or if a background read (e.g. of a regular ?disk? file) should be started instead.

2. Get the pending unread data before it is lost by calling ?BufferedReader.detach?.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32475>
_______________________________________

From report at bugs.python.org  Tue Jan 16 00:09:49 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Jan 2018 05:09:49 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516079389.64.0.467229070634.issue32561@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

BufferedIOBase is an abstract class and, despite the name, doesn?t necessitate a buffer or cache. Adding methods and properties might break compatibility with third-party implementations, or get ugly with optional methods and multiple versions of the API. It seems like it would be better to extend the concrete APIs: io.BufferedReader, BufferedWriter and/or FileIO.

In Issue 32475 there is a proposal to add a ?getbuffn? method returning the amount of unread pending data in a reader object. Perhaps that would be enough for reading.

I would support an similar API for BufferedWriter etc. Perhaps a property called ?available_space?. You could check that and decide whether to do a direct non-blocking ?write?, or launch a blocking ?write? in the background.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 00:10:02 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Jan 2018 05:10:02 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516079402.33.0.467229070634.issue32561@psf.upfronthosting.co.za>


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


----------
dependencies: +Add ability to query number of buffered bytes available on buffered I/O

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 00:14:41 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 05:14:41 +0000
Subject: [issue32563] -Werror=declaration-after-statement expat build failure
 on Python 3.5
Message-ID: <1516079681.55.0.467229070634.issue32563@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

A fresh Python 3.5 checkout failed to build the embedded expat XML library for me, due to the configure check that adds "-Werror=declaration-after-statement" to the compiler flags.

I'm guessing this was introduced via the expat code changes brought in for https://github.com/python/cpython/commit/f2492bb6aae061aea47e21fc7e56b7ab9bfdf543

That configure check is gone in 3.6 and 3.7, but it's still there in 3.5.

Locally, I've worked around the problem by removing the configure check, but I'm not sure that's the right answer, as I believe we still promise that 3.5 will build under C89.

----------
messages: 310037
nosy: larry, ncoghlan, vstinner
priority: low
severity: normal
stage: needs patch
status: open
title: -Werror=declaration-after-statement expat build failure on Python 3.5
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Tue Jan 16 00:50:40 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 05:50:40 +0000
Subject: [issue32563] -Werror=declaration-after-statement expat build failure
 on Python 3.5
In-Reply-To: <1516079681.55.0.467229070634.issue32563@psf.upfronthosting.co.za>
Message-ID: <1516081840.02.0.467229070634.issue32563@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Details of the compilation failure:

```
building 'pyexpat' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DHAVE_EXPAT_CONFIG_H=1 -DXML_POOR_ENTROPY=1 -DUSE_PYEXPAT_CAPI -I/home/ncoghlan/devel/py35/Modules/expat -I./Include -I. -I/usr/local/include -I/home/ncoghlan/devel/py35/Include -I/home/ncoghlan/devel/py35 -c /home/ncoghlan/devel/py35/Modules/pyexpat.c -o build/temp.linux-x86_64-3.5/home/ncoghlan/devel/py35/Modules/pyexpat.o
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DHAVE_EXPAT_CONFIG_H=1 -DXML_POOR_ENTROPY=1 -DUSE_PYEXPAT_CAPI -I/home/ncoghlan/devel/py35/Modules/expat -I./Include -I. -I/usr/local/include -I/home/ncoghlan/devel/py35/Include -I/home/ncoghlan/devel/py35 -c /home/ncoghlan/devel/py35/Modules/expat/xmlparse.c -o build/temp.linux-x86_64-3.5/home/ncoghlan/devel/py35/Modules/expat/xmlparse.o
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DHAVE_EXPAT_CONFIG_H=1 -DXML_POOR_ENTROPY=1 -DUSE_PYEXPAT_CAPI -I/home/ncoghlan/devel/py35/Modules/expat -I./Include -I. -I/usr/local/include -I/home/ncoghlan/devel/py35/Include -I/home/ncoghlan/devel/py35 -c /home/ncoghlan/devel/py35/Modules/expat/xmlrole.c -o build/temp.linux-x86_64-3.5/home/ncoghlan/devel/py35/Modules/expat/xmlrole.o
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DHAVE_EXPAT_CONFIG_H=1 -DXML_POOR_ENTROPY=1 -DUSE_PYEXPAT_CAPI -I/home/ncoghlan/devel/py35/Modules/expat -I./Include -I. -I/usr/local/include -I/home/ncoghlan/devel/py35/Include -I/home/ncoghlan/devel/py35 -c /home/ncoghlan/devel/py35/Modules/expat/xmltok.c -o build/temp.linux-x86_64-3.5/home/ncoghlan/devel/py35/Modules/expat/xmltok.o
/home/ncoghlan/devel/py35/Modules/expat/xmltok.c: In function ?utf8_toUtf8?:
/home/ncoghlan/devel/py35/Modules/expat/xmltok.c:408:3: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
   const char * const fromLimBefore = fromLim;
   ^~~~~
/home/ncoghlan/devel/py35/Modules/expat/xmltok.c:414:3: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
   const ptrdiff_t bytesToCopy = fromLim - *fromP;
   ^~~~~
cc1: some warnings being treated as errors
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Tue Jan 16 01:10:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 06:10:19 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516083019.09.0.467229070634.issue32551@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch
pull_requests: +5050
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Tue Jan 16 01:10:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 06:10:19 +0000
Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files
In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za>
Message-ID: <1516083019.18.0.574204596225.issue29319@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +5051

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29319>
_______________________________________

From report at bugs.python.org  Tue Jan 16 01:32:39 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 06:32:39 +0000
Subject: [issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516084359.86.0.467229070634.issue32551@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

PR submitted for 3.5. Since the problem was in a full release this time (rather than a pre-release the way it was for 3.6), I've reclassified it as a security bug, since it means some previously safe operations (where no user-writable directory would end up on sys.path even without the "-I" switch) are technically unsafe.

There's a fair combination of factors required for it to actually cause a problem though:

- it only comes up if you're *not* using isolated mode (so the "workaround" is "Use isolated mode when running privileged processes", which is something we recommend doing anyway)
- it only comes up for directory or zipfile execution, *not* normal script execution
- you have to be executing an admin-controlled directory or zipfile, rather than one the user has write access to (otherwise there's no new opportunity for code injection introduced)
- for actual privilege escalation to take place as a result of the code injection, you have to be running the command with elevated privileges

That said, I suspect exactly the above may happen when using PEX files (https://github.com/pantsbuild/pex), since I can't find any reference in their code to forcing the use of isolated mode in the underlying interpreter.

----------
keywords:  -patch
nosy: +christian.heimes, encukou
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Tue Jan 16 01:41:08 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 06:41:08 +0000
Subject: [issue32551] Zipfile & directory execution in 3.5.4 adds the current
 directory to sys.path
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516084868.98.0.467229070634.issue32551@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've updated the issue title to reduce the need to have read bpo-29723 first to understand it.

I've also filed https://github.com/pantsbuild/pex/issues/440 essentially asking the pex folks to check if they're affected.

----------
stage:  -> commit review
title: 3.5.4 has a regression that was fixed in 3.6.1rc1 -> Zipfile & directory execution in 3.5.4 adds the current directory to sys.path

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Tue Jan 16 02:08:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 07:08:50 +0000
Subject: [issue29723] 3.6.1rc1 adds the current directory to sys.path when
 running a subdirectory's __main__.py; previous versions did not
In-Reply-To: <1488720708.95.0.279516549191.issue29723@psf.upfronthosting.co.za>
Message-ID: <1516086530.1.0.467229070634.issue29723@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -585

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29723>
_______________________________________

From report at bugs.python.org  Tue Jan 16 02:10:04 2018
From: report at bugs.python.org (Nitish)
Date: Tue, 16 Jan 2018 07:10:04 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1516086604.98.0.467229070634.issue31368@psf.upfronthosting.co.za>


Change by Nitish <nitishch at protonmail.com>:


----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Tue Jan 16 02:16:36 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 07:16:36 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516086996.78.0.467229070634.issue32561@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> BufferedIOBase is an abstract class and, despite the name, doesn?t necessitate a buffer or cache

Right, sorry, skimmed too fast.

> In Issue 32475 there is a proposal to add a ?getbuffn? method returning the amount of unread pending data in a reader object. Perhaps that would be enough for reading.

Ideally we would be able to do buffer-only reads through all the of the different read methods (read, readline, readinto, ...), and ideally we would be able to do it given objects at different points in the IO stack ? so a buffer-only read on TextWrapper wrapped around a BufferedRandom wrapped around a FileIO, should propagate the buffer-only-ness all the way down the stack. I don't think getbuffn is enough to solve that? Or at least I don't see how in any simple way.

Also, the immediate thing that spurred me to file this issue was learning that Linux has just added a non-blocking file read syscall. It would be pretty neat if we could expose that. If we had a way to propagate this down, then it could just be FileIO's implementation of the buffer-only flag.

But yeah, actually doing that is complicated given the need to continue supporting existing implementations of these interfaces.

Here's a straw man proposal: add a unbuffered_supported flag to the abstract IO interfaces. If missing or false, you can't do unbuffered reads/writes. If present and True, then you can pass a new unbuffered=True kw-only argument to their read/write calls.

When (for example) TextWrapper.read needs to call its wrapped object's .read, it does a check like:

  if unbuffered:
      # This call is unbuffered, so we're only allowed to call
      # unbuffered methods.
      if not getattr(self.wrapped, "unbuffered_supported", False):
          # lower level doesn't support this, can't be done
          raise ...
      else:
          self.wrapped.read(..., unbuffered=True)
  else:
      # We're a regular call, so we can make a regular call
      self.wrapped.read(...)

(I'm intentionally using "unbuffered" here to distinguish from regular POSIX "non-blocking", which is an API that's conceptually very similar but totally distinct in implementation. Especially since it's also possible to use the io stack with sockets/pipes in non-blocking mode.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 02:20:26 2018
From: report at bugs.python.org (Xavier G. Domingo)
Date: Tue, 16 Jan 2018 07:20:26 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516087226.79.0.467229070634.issue32561@psf.upfronthosting.co.za>


Change by Xavier G. Domingo <xgdomingo at gmail.com>:


----------
nosy: +xgdomingo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:13:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 08:13:19 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516090399.83.0.467229070634.issue32561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ideally we would be able to do buffer-only reads through all the of the different read methods (read, readline, readinto, ...),

Hmm... We already have non-blocking support in BufferedIOReader, except it *doesn't work*.  The problem is, the semantics mandated by readline() and even buffered read() don't work very well with non-blocking IO (see issue13322).

So my opinion here is that only raw IO objects (FileIO) should have this functionality.  People can build their own functionality on top of that (such as Tornado or asyncio do with their streams).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:21:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 08:21:49 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1516090909.72.0.467229070634.issue17611@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What should be done for PR 5006? Changes of this PR have been minimized for easier review. But many interesting things can made after merging it. For example simplify 'with'-related opcodes. Or implement static blocks (this will make the 'try' statement zero-overhead, make checks in frame.f_lineno setter more reliable, and unblock some bytecode optimizations). It would be better to have more time before a feature freeze.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:34:37 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 08:34:37 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1516091677.92.0.467229070634.issue17611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently PR 5006 has a conflict. Otherwise, is it ready for review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:35:47 2018
From: report at bugs.python.org (Andrew Olefira)
Date: Tue, 16 Jan 2018 08:35:47 +0000
Subject: [issue32564] Syntax error on using variable async
Message-ID: <1516091747.29.0.467229070634.issue32564@psf.upfronthosting.co.za>


New submission from Andrew Olefira <andrew.olefira at gmail.com>:

In python 3.6 you can use name "async" for variable:
>>> class A:
...     async = True
... 
>>> 

but in python 3.7a4 you catch syntax error:
>>> class A:
...     async = True
  File "<stdin>", line 2
    async = True
          ^
SyntaxError: invalid syntax
>>>

----------
messages: 310045
nosy: Andrew Olefira
priority: normal
severity: normal
status: open
title: Syntax error on using variable async
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32564>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:37:24 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 08:37:24 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1516091844.23.0.467229070634.issue17611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Simplifying "with"-related opcodes (and perhaps "finally" ones) sounds nice.

"try" blocks are already zero-overhead for practical purposes (i.e. I don't think I've met any workload where moving a "try" around did improve performance significantly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:42:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 08:42:04 +0000
Subject: [issue32564] Syntax error on using variable async
In-Reply-To: <1516091747.29.0.467229070634.issue32564@psf.upfronthosting.co.za>
Message-ID: <1516092124.11.0.467229070634.issue32564@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See https://docs.python.org/3.7/whatsnew/3.5.html#new-keywords.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32564>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:43:52 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 08:43:52 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516092232.14.0.467229070634.issue32561@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Hmm, why did I use "unbuffered" as my term above? That's a very odd name. It's like, exactly the opposite of what we actually want. Clearly I did not think this through properly. Please pretend I said "buffer-only" instead, thanks.

> So my opinion here is that only raw IO objects (FileIO) should have this functionality.  People can build their own functionality on top of that (such as Tornado or asyncio do with their streams).

I guess I don't object to such functionality, but it would be useless to me personally. FileIO doesn't solve any problems I have with stream processing; the reason I care about this is for providing an async file I/O API. And all the async file IO APIs I know [1][2][3] have the public API of "just like regular files, but the blocking methods are async". 99% of the time, that means TextWrapper and BufferedStream. So I just don't see any way to get the advantages of this feature without either (a) adding buffer-only support to those layers, or (b) forking those layers into a 3rd-party library, and then adding buffer-only support.

OTOH, it would be ok if in an initial implementation some methods like readline() simply always failed when called in buffer-only mode, since this would be a best-effort thing. (This is also a different from the non-blocking semantics discussion in bpo-13322, which is kind of scary. I don't want to deal with partial writes and reads and carrying crucial data in exceptions! I just want to know if the operation can trivially be done without blocking, and if not then I'll retry it in blocking mode.)

[1] https://github.com/Tinche/aiofiles
[2] https://trio.readthedocs.io/en/latest/reference-io.html#asynchronous-filesystem-i-o
[3] https://curio.readthedocs.io/en/latest/reference.html#module-curio.file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:51:23 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 16 Jan 2018 08:51:23 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
In-Reply-To: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>
Message-ID: <1516092683.1.0.467229070634.issue32544@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I run pyperformance.
It seems django_template is significant faster.

# Without PGO+LTO

./python -m perf compare_to -G --min-speed=2 default.json patched.json
Slower (6):
- scimark_monte_carlo: 217 ms +- 9 ms -> 237 ms +- 10 ms: 1.09x slower (+9%)
- scimark_lu: 326 ms +- 14 ms -> 351 ms +- 20 ms: 1.08x slower (+8%)
- float: 219 ms +- 4 ms -> 226 ms +- 8 ms: 1.03x slower (+3%)
- crypto_pyaes: 208 ms +- 2 ms -> 213 ms +- 2 ms: 1.02x slower (+2%)
- pickle: 20.1 us +- 0.2 us -> 20.6 us +- 0.4 us: 1.02x slower (+2%)
- xml_etree_iterparse: 184 ms +- 3 ms -> 188 ms +- 3 ms: 1.02x slower (+2%)

Faster (10):
- django_template: 315 ms +- 4 ms -> 287 ms +- 3 ms: 1.10x faster (-9%)
- logging_format: 25.9 us +- 0.3 us -> 24.7 us +- 0.3 us: 1.05x faster (-5%)
- logging_simple: 21.6 us +- 0.2 us -> 20.6 us +- 0.4 us: 1.05x faster (-5%)
- sympy_str: 399 ms +- 3 ms -> 381 ms +- 2 ms: 1.05x faster (-5%)
- unpack_sequence: 117 ns +- 6 ns -> 112 ns +- 0 ns: 1.04x faster (-4%)
- sympy_expand: 886 ms +- 7 ms -> 851 ms +- 7 ms: 1.04x faster (-4%)
- regex_effbot: 5.00 ms +- 0.09 ms -> 4.84 ms +- 0.11 ms: 1.03x faster (-3%)
- xml_etree_process: 185 ms +- 3 ms -> 180 ms +- 4 ms: 1.02x faster (-2%)
- nqueens: 215 ms +- 3 ms -> 211 ms +- 3 ms: 1.02x faster (-2%)
- telco: 16.0 ms +- 0.6 ms -> 15.6 ms +- 0.4 ms: 1.02x faster (-2%)

Benchmark hidden because not significant (44)

# With PGO+LTO

$ ./python -m perf compare_to -G --min-speed=2 default-opt.json patched-opt.json
Slower (8):
- xml_etree_process: 179 ms +- 3 ms -> 195 ms +- 3 ms: 1.09x slower (+9%)
- xml_etree_generate: 208 ms +- 5 ms -> 224 ms +- 3 ms: 1.08x slower (+8%)
- xml_etree_iterparse: 190 ms +- 5 ms -> 203 ms +- 3 ms: 1.07x slower (+7%)
- pickle_list: 6.80 us +- 0.30 us -> 7.18 us +- 0.72 us: 1.06x slower (+6%)
- genshi_text: 72.8 ms +- 1.1 ms -> 76.3 ms +- 0.8 ms: 1.05x slower (+5%)
- mako: 32.6 ms +- 0.1 ms -> 34.1 ms +- 0.6 ms: 1.05x slower (+5%)
- unpickle_pure_python: 713 us +- 12 us -> 744 us +- 16 us: 1.04x slower (+4%)
- scimark_sor: 375 ms +- 13 ms -> 383 ms +- 11 ms: 1.02x slower (+2%)

Faster (14):
- django_template: 327 ms +- 3 ms -> 296 ms +- 2 ms: 1.10x faster (-9%)
- scimark_lu: 339 ms +- 20 ms -> 309 ms +- 13 ms: 1.10x faster (-9%)
- sympy_str: 418 ms +- 4 ms -> 387 ms +- 3 ms: 1.08x faster (-7%)
- sympy_expand: 926 ms +- 5 ms -> 860 ms +- 5 ms: 1.08x faster (-7%)
- logging_simple: 22.4 us +- 0.3 us -> 21.0 us +- 0.3 us: 1.07x faster (-6%)
- scimark_fft: 741 ms +- 61 ms -> 697 ms +- 25 ms: 1.06x faster (-6%)
- telco: 17.6 ms +- 0.4 ms -> 16.6 ms +- 0.4 ms: 1.06x faster (-5%)
- logging_format: 26.5 us +- 0.3 us -> 25.3 us +- 0.3 us: 1.05x faster (-5%)
- sqlite_synth: 7.35 us +- 0.16 us -> 7.08 us +- 0.18 us: 1.04x faster (-4%)
- scimark_sparse_mat_mult: 8.83 ms +- 0.42 ms -> 8.51 ms +- 0.37 ms: 1.04x faster (-4%)
- pathlib: 43.1 ms +- 0.6 ms -> 41.7 ms +- 0.7 ms: 1.03x faster (-3%)
- html5lib: 193 ms +- 7 ms -> 188 ms +- 7 ms: 1.03x faster (-3%)
- richards: 149 ms +- 3 ms -> 145 ms +- 2 ms: 1.02x faster (-2%)
- pickle_pure_python: 1.01 ms +- 0.01 ms -> 984 us +- 20 us: 1.02x faster (-2%)

Benchmark hidden because not significant (38)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:51:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 08:51:33 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516092693.0.0.467229070634.issue32561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> And all the async file IO APIs I know [1][2][3] have the public API of "just like regular files, but the blocking methods are async". 99% of the time, that means TextWrapper and BufferedStream. So I just don't see any way to get the advantages of this feature without either (a) adding buffer-only support to those layers, or (b) forking those layers into a 3rd-party library, and then adding buffer-only support.

Yeah... The concrete problem is that there's already a poorly thought-out "non-blocking mode" that only partly works, and suddenly the code (which includes a lot of delicate, performance-critical C code... to give you an idea, even recently a consistency bug in truncate() was discovered) will have to be massaged to support another non-blocking mode of operation.

So that's why I'm very cautious about integrating this into BufferedReader and friends.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:54:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Jan 2018 08:54:08 +0000
Subject: [issue32559] logging - public function to get level from name
In-Reply-To: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>
Message-ID: <1516092848.07.0.467229070634.issue32559@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The use case of setting the level by name was already fulfilled in Python 3.2.   The logging.setLevel() function takes either an int or a string.

----------
assignee:  -> vinay.sajip
nosy: +rhettinger, vinay.sajip
priority: normal -> low
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:58:08 2018
From: report at bugs.python.org (Bob Kline)
Date: Tue, 16 Jan 2018 08:58:08 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1516093088.21.0.467229070634.issue11849@psf.upfronthosting.co.za>


Bob Kline <bkline at rksystems.com> added the comment:

Would it be inappropriate for this fix to be applied to 2.7?

----------
nosy: +bkline

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:59:08 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 08:59:08 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1516093148.71.0.467229070634.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's not really a fix, it's an improvement, and as such doesn't belong in 2.7.  Using malloc() and free() is not a bug in itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:01:07 2018
From: report at bugs.python.org (Andrew Olefira)
Date: Tue, 16 Jan 2018 09:01:07 +0000
Subject: [issue32564] Syntax error on using variable async
In-Reply-To: <1516091747.29.0.467229070634.issue32564@psf.upfronthosting.co.za>
Message-ID: <1516093267.76.0.467229070634.issue32564@psf.upfronthosting.co.za>


Andrew Olefira <andrew.olefira at gmail.com> added the comment:

Yes, I understand, but "not recommended" != "not allowed".
For example library Pika (https://pypi.python.org/pypi/pika) use variable "async", so no one project that use lib Pika can't be launched on Python 3.7a4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32564>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:03:01 2018
From: report at bugs.python.org (Andrew Olefira)
Date: Tue, 16 Jan 2018 09:03:01 +0000
Subject: [issue32564] Syntax error on using variable async
In-Reply-To: <1516091747.29.0.467229070634.issue32564@psf.upfronthosting.co.za>
Message-ID: <1516093381.17.0.467229070634.issue32564@psf.upfronthosting.co.za>


Change by Andrew Olefira <andrew.olefira at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32564>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:08:40 2018
From: report at bugs.python.org (Bob Kline)
Date: Tue, 16 Jan 2018 09:08:40 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1516093720.83.0.467229070634.issue11849@psf.upfronthosting.co.za>


Bob Kline <bkline at rksystems.com> added the comment:

Sorry, I should have used the language of the patch author ("the resolution"). Without the resolution, Python 2.7 eventually runs out of memory and crashes for some correctly written user code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:09:41 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Tue, 16 Jan 2018 09:09:41 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516093781.37.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

Built and benchmarked both the baseline and the patch without PGO; the differences are less pronounced, but still present.

https://gist.github.com/jeethu/abd404e39c6dfcbabb4c01661b9238d1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:11:12 2018
From: report at bugs.python.org (Paul Moore)
Date: Tue, 16 Jan 2018 09:11:12 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516093872.04.0.467229070634.issue32553@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Agreed, the docs don't need to mention PATHEXT.

I don't have a machine to hand with Python 3.6 not installed, to check, but I believe the launcher is installed by default (although as you say it can be deselected - and it's definitely described as "recommended") whereas adding Python to PATH is deselected by default. So "py" is more likely to work on a typical installation than "python".

As I say, though, I have no feel here for the right level of detail. Maybe something like

"""
To execute the venv command, use

    python -m venv

Unix installations typically name the Python 3.x executable "python3", and on Windows the "py" launcher is generally available even if the Python interpreter is not on your PATH, so you may need to substitute the appropriate means of invoking Python in place of the "python" command above.
"""

But that's (to my mind) still wordy and complex - and the new users I've spoken to already find the docs too full of confusing detail.

Ideally, I'd prefer it if "Invoking Python" were described once and for all in a separate section of the docs (i.e., the "Python Setup and Usage" manual) and everywhere else in the official documentation we simply used "python", with no qualifications, on the understanding that this stands for "whatever you use on your PC to run Python". I suspect that would generate complaints from a lot of people, though, as most people hit the doc pages via direct links, not by reading the manuals in order...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:11:38 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 09:11:38 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1516093898.4.0.467229070634.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, memory fragmentation can happen with any allocation scheme, and it's possible even Python 3 isn't immune to this.  Backporting performance improvements is a strain on our resources and also constitutes a maintenance threat (what if the bug hides in the new code?).  And Python 2.7 is really nearing its end-of-life more and more everyday.  So IMHO it's a no-no.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:13:16 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 09:13:16 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516093996.86.0.467229070634.issue32534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks.  That's really surprising.  I'll give it a try myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:20:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 09:20:30 +0000
Subject: [issue32564] Syntax error on using variable async
In-Reply-To: <1516091747.29.0.467229070634.issue32564@psf.upfronthosting.co.za>
Message-ID: <1516094430.11.0.467229070634.issue32564@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It raised a DeprecationWarning since 3.5. Most projects got rid of "async" and "await" identifiers before 3.7. File a bug in the Pika library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32564>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:28:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 09:28:50 +0000
Subject: [issue32565] Document the version of adding opcodes
Message-ID: <1516094930.57.0.467229070634.issue32565@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The version of adding a new opcode is not specified for some opcodes. The proposed PR adds missed 'versionadded' directives (as usually, only when added after 3.0).

----------
assignee: docs at python
components: Documentation
messages: 310061
nosy: docs at python, ncoghlan, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Document the version of adding opcodes
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32565>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:30:28 2018
From: report at bugs.python.org (Kiran)
Date: Tue, 16 Jan 2018 09:30:28 +0000
Subject: [issue32566] Not able to open Python IDLE
Message-ID: <1516095028.12.0.467229070634.issue32566@psf.upfronthosting.co.za>


New submission from Kiran <kiranreddy.p.s at gmail.com>:

Hello,

I am new to Python and installed python3 recently and when I try to open IDLE, Iam getting the error attached.

Please let me know how to resolve it.

Thanks.

----------
components: Windows
files: Python.jpg
messages: 310062
nosy: Kiran, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Not able to open Python IDLE
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47387/Python.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32566>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:30:29 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Jan 2018 09:30:29 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516095029.06.0.467229070634.issue26163@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset b44c5169f64178d2ff2914187b315549e7ab0cb6 by Raymond Hettinger in branch 'master':
bpo-26163: Frozenset hash improvement (#5194)
https://github.com/python/cpython/commit/b44c5169f64178d2ff2914187b315549e7ab0cb6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:30:42 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Jan 2018 09:30:42 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516095042.92.0.467229070634.issue26163@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5052

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:30:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 09:30:58 +0000
Subject: [issue32534] Speed-up list.insert
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516095058.27.0.467229070634.issue32534@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"

Please don't use timeit, but perf timeit to run such *microbenchmark* (time smaller than 1 ms).

Your benchmark measures also the performance of the loop, it might be significant in such short loop (100 items). You may try to unroll the loop manually, and truncate the list:

vstinner at apu$ python3 -c 'print("l.insert(None); " * 3 + "l.clear();")'
l.insert(None); l.insert(None); l.insert(None); l.clear();

Example:

python3 -m perf timeit -s 'l=[]' $(python3 -c 'print("l.insert(0, None); " * 100 + "l.clear();")') --duplicate 100


Jeethu Rao: Are you using CPU isolation? What is your OS?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:31:49 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Jan 2018 09:31:49 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516095109.08.0.467229070634.issue26163@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:32:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 09:32:15 +0000
Subject: [issue32565] Document the version of adding opcodes
In-Reply-To: <1516094930.57.0.467229070634.issue32565@psf.upfronthosting.co.za>
Message-ID: <1516095135.39.0.467229070634.issue32565@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +5053
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32565>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:43:00 2018
From: report at bugs.python.org (Bob Kline)
Date: Tue, 16 Jan 2018 09:43:00 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1516095780.91.0.467229070634.issue11849@psf.upfronthosting.co.za>


Bob Kline <bkline at rksystems.com> added the comment:

Thanks for your responses to my comments. I'm working as hard as I can to get my customer's systems migrated into the Python 3 world, and I appreciate the efforts of the community to provide incentives (such as the resolution for this failure) for developers to upgrade. However, it's a delicate balancing act sometimes, given that we have critical places in our system for which the same code runs more than twice as slowly on Python 3.6 as on Python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:44:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 09:44:18 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516095858.21.0.467229070634.issue32534@psf.upfronthosting.co.za>


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


----------
title: Speed-up list.insert -> Speed-up list.insert: use memmove()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:47:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 09:47:05 +0000
Subject: [issue32563] -Werror=declaration-after-statement expat build failure
 on Python 3.5
In-Reply-To: <1516079681.55.0.467229070634.issue32563@psf.upfronthosting.co.za>
Message-ID: <1516096025.01.0.467229070634.issue32563@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Hum, I backported a fix to 3.4 but I forgot Python 3.5.

My fix for Python 3.4 is made of multiple bugfixes: 8b11e8de7aedacfbbcc8c780f3c4097396f1d1a3

For Python 3.5, you want at least this change I think:

https://github.com/libexpat/libexpat/commit/e0b290eb3d8f4c4b45137a7d7f4f8db812145bd2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:49:07 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 09:49:07 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516096147.09.0.467229070634.issue32561@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

That's a reasonable concern. Do you think we can deprecate the existing broken non-blocking mode?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:00:01 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 16 Jan 2018 10:00:01 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1516096801.48.0.467229070634.issue11849@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

FYI, jemalloc can reduce memory usage, especially when application
is multithreaded.

https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html
https://zapier.com/engineering/celery-python-jemalloc/

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:02:37 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 10:02:37 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516096957.46.0.467229070634.issue32561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Do you think we can deprecate the existing broken non-blocking mode?

I would suggest asking on python-dev.  I wouldn't mind it, but perhaps there are people using it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:10:56 2018
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Tue, 16 Jan 2018 10:10:56 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516097456.68.0.467229070634.issue29708@psf.upfronthosting.co.za>


Change by Bernhard M. Wiedemann <pythonbugs at lsmod.de>:


----------
keywords: +patch
pull_requests: +5054
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:27:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Jan 2018 10:27:17 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516098437.52.0.467229070634.issue26163@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset e7dbd0658304f11daf103d56662656efecad006d by Raymond Hettinger (Miss Islington (bot)) in branch '3.6':
bpo-26163: Frozenset hash improvement (GH-5194) (#5198)
https://github.com/python/cpython/commit/e7dbd0658304f11daf103d56662656efecad006d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:44:16 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Tue, 16 Jan 2018 10:44:16 +0000
Subject: =?utf-8?q?=5Bissue32567=5D_Venv=E2=80=99s_config_file_=28pyvenv=2Ecfg=29_?=
 =?utf-8?q?should_be_compatible_with_ConfigParser?=
Message-ID: <1516099456.9.0.467229070634.issue32567@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

I?m not sure if it is intended, but it seems wrong to me that pyvenv.cfg is using a format that ConfigParser does not recognise. ConfigParser requires all values be placed under a section, but pyvenv.cfg does not do that.

Maybe related:

* ConfigParser?s format requirement: https://docs.python.org/3/library/configparser.html#supported-ini-file-structure
* How venv creates the configuration file: https://github.com/python/cpython/blob/master/Lib/venv/__init__.py#L141
* Abandoned discussion on whether ConfigParser should support section-less format #22253

----------
components: Library (Lib)
messages: 310071
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Venv?s config file (pyvenv.cfg) should be compatible with ConfigParser
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32567>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:48:25 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 16 Jan 2018 10:48:25 +0000
Subject: [issue32568] Fix handling of sizehint=-1 in select.epoll()
Message-ID: <1516099705.58.0.467229070634.issue32568@psf.upfronthosting.co.za>


New submission from Tal Einat <taleinat at gmail.com>:

In 2fb9ae9dfc5a6830d902332ba93b13387e292ddb, select.epoll() was changed to reject sizehint=-1, despite that still being documented as the default value. Would it be possible to reverse this change, making -1 a special value signaling select.epoll() to use sizehint=FD_SETSIZE-1, as was before this change?

Additionally, in the same commit the docs were changed to say that the sizehint parameter is deprecated and has no effect, but later changes have restored use of sizehint in certain cases without updating the documentation. This inconsistency should be fixed.

For reference, this came up as part of #31938.

----------
messages: 310072
nosy: benjamin.peterson, serhiy.storchaka, taleinat
priority: normal
severity: normal
status: open
title: Fix handling of sizehint=-1 in select.epoll()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32568>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:49:40 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 16 Jan 2018 10:49:40 +0000
Subject: [issue32568] Fix handling of sizehint=-1 in select.epoll()
In-Reply-To: <1516099705.58.0.467229070634.issue32568@psf.upfronthosting.co.za>
Message-ID: <1516099780.6.0.467229070634.issue32568@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Also see discussion in GitHub PR 4265 for #31938.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32568>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:50:58 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 10:50:58 +0000
Subject: [issue32563] -Werror=declaration-after-statement expat build failure
 on Python 3.5
In-Reply-To: <1516079681.55.0.467229070634.issue32563@psf.upfronthosting.co.za>
Message-ID: <1516099858.27.0.467229070634.issue32563@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch
pull_requests: +5055
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:53:10 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 10:53:10 +0000
Subject: [issue32563] -Werror=declaration-after-statement expat build failure
 on Python 3.5
In-Reply-To: <1516079681.55.0.467229070634.issue32563@psf.upfronthosting.co.za>
Message-ID: <1516099990.81.0.467229070634.issue32563@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I couldn't persuade git to pull the upstream patch in directly, so I just made the same change downstream: https://github.com/python/cpython/pull/5201

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:56:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 10:56:44 +0000
Subject: [issue32568] Fix handling of sizehint=-1 in select.epoll()
In-Reply-To: <1516099705.58.0.467229070634.issue32568@psf.upfronthosting.co.za>
Message-ID: <1516100204.71.0.467229070634.issue32568@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Extension Modules
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32568>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:58:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 10:58:56 +0000
Subject: [issue32568] Fix handling of sizehint=-1 in select.epoll()
In-Reply-To: <1516099705.58.0.467229070634.issue32568@psf.upfronthosting.co.za>
Message-ID: <1516100336.35.0.467229070634.issue32568@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Also sizehint=0 was rejected before 2fb9ae9dfc5a6830d902332ba93b13387e292ddb. Now it is accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32568>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:02:56 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 11:02:56 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516100576.47.0.467229070634.issue32516@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Putting .dll's next to their .pyd's isn't a general solution, because sometimes you want to be able to use the same .dll's from .pyd's that are in different directories. For example, scipy.spatial.qhull, scipy.optimize._lbfsgb, and scipy.linalg._flinalg are three different extensions in different directories, but they all link against BLAS. And you definitely don't want to include multiple copies of BLAS; the current scipy wheels on Linux are 50 MB, and 40 MB of that is *one* copy of OpenBLAS.

I don't think import hooks are terribly relevant here either. The big problem is how to arrange for the .dlls to be loaded before the .pyds. The obvious hack would be to somehow automatically rewrite the package __init__.py to either mutate PATH or pre-load the .dlls, which is admittedly pretty nasty. But... if you want to install an import hook, then that *also* requires rewriting the package __init__.py to inject the import hook installation code, and then the import hook would just be mutating PATH or pre-loading the .dlls. So adding an import hook to the mix doesn't seem to be buying much.

I guess I can see the argument for @xoviat's original proposal: if lots of packages are going to have weird code injected into their __init__.py just to add the same paths to the DLL search path, then maybe it's simpler all around if this becomes a standard feature of the Python importer. However, even if this were implemented we'd still need to write and maintain the __init__.py injection code for the next ~5 years, so probably the thing to do is to implement the __init__.py approach first and wait to see how it shakes out before considering interpreter changes.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:12:26 2018
From: report at bugs.python.org (David Carlier)
Date: Tue, 16 Jan 2018 11:12:26 +0000
Subject: [issue32569] Blake2 module, memory clearance update
Message-ID: <1516101146.75.0.467229070634.issue32569@psf.upfronthosting.co.za>


Change by David Carlier <dcarlier at afilias.info>:


----------
components: Library (Lib)
nosy: David Carlier
priority: normal
pull_requests: 5056
severity: normal
status: open
title: Blake2 module, memory clearance update
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From mal at egenix.com  Tue Jan 16 06:13:43 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 16 Jan 2018 12:13:43 +0100
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1516100576.47.0.467229070634.issue32516@psf.upfronthosting.co.za>
References: <1516100576.47.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <8947c09f-0243-a94c-6189-0dadf2288a8d@egenix.com>

Probably better overall to go with a conda package which puts
the DLLs in a central location and manages the dependencies.

You can then load the DLL in the package before loading the PYD
and you're all set. Whether in an __init__.py or elsewhere is
really up to the package.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Tue Jan 16 06:13:49 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Jan 2018 11:13:49 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1516100576.47.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <8947c09f-0243-a94c-6189-0dadf2288a8d@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Probably better overall to go with a conda package which puts
the DLLs in a central location and manages the dependencies.

You can then load the DLL in the package before loading the PYD
and you're all set. Whether in an __init__.py or elsewhere is
really up to the package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:13:52 2018
From: report at bugs.python.org (David Carlier)
Date: Tue, 16 Jan 2018 11:13:52 +0000
Subject: [issue32569] Blake2 module, memory clearance update
Message-ID: <1516101232.18.0.467229070634.issue32569@psf.upfronthosting.co.za>


New submission from David Carlier <dcarlier at afilias.info>:

Might brings a bit of "controversy" but some oses have already unoptimizable memset like functions from their libc was thinking to just use them instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:17:17 2018
From: report at bugs.python.org (David Carlier)
Date: Tue, 16 Jan 2018 11:17:17 +0000
Subject: [issue32569] Blake2 module, memory clearance update
In-Reply-To: <1516101232.18.0.467229070634.issue32569@psf.upfronthosting.co.za>
Message-ID: <1516101437.18.0.467229070634.issue32569@psf.upfronthosting.co.za>


David Carlier <dcarlier at afilias.info> added the comment:

Since the PR had been closed.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:17:29 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Jan 2018 11:17:29 +0000
Subject: [issue32569] Blake2 module, memory clearance update
In-Reply-To: <1516101232.18.0.467229070634.issue32569@psf.upfronthosting.co.za>
Message-ID: <1516101449.59.0.467229070634.issue32569@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks for your contribution. Any optimization must land in upstream first, https://github.com/BLAKE2/libb2.

See https://bugs.python.org/issue17405 for more discussion on the topic.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:21:58 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Jan 2018 11:21:58 +0000
Subject: [issue32569] Blake2 module, memory clearance update
In-Reply-To: <1516101232.18.0.467229070634.issue32569@psf.upfronthosting.co.za>
Message-ID: <1516101718.88.0.467229070634.issue32569@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

In general your patch is a good idea. It should land in upstream, so everybody benefits from it. I also want to keep the maintenance burden as small as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:23:52 2018
From: report at bugs.python.org (David Carlier)
Date: Tue, 16 Jan 2018 11:23:52 +0000
Subject: [issue32569] Blake2 module, memory clearance update
In-Reply-To: <1516101232.18.0.467229070634.issue32569@psf.upfronthosting.co.za>
Message-ID: <1516101832.85.0.467229070634.issue32569@psf.upfronthosting.co.za>


David Carlier <dcarlier at afilias.info> added the comment:

No worries If I saw first it was an extra project I would not have try to submit in Cpython. Apologies. I ll see what I can do in blake2 side :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:51:20 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 11:51:20 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516103480.29.0.467229070634.issue32516@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Conda is cool but we're not currently planning to abandon wheels.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:52:47 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 16 Jan 2018 11:52:47 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
In-Reply-To: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>
Message-ID: <1516103567.72.0.467229070634.issue32544@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 378edee0a3b913d60653dc17dfe61d83405a8135 by INADA Naoki in branch 'master':
bpo-32544: Speed up hasattr() and getattr() (GH-5173)
https://github.com/python/cpython/commit/378edee0a3b913d60653dc17dfe61d83405a8135


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:53:07 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 16 Jan 2018 11:53:07 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
In-Reply-To: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>
Message-ID: <1516103587.15.0.467229070634.issue32544@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:58:04 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 16 Jan 2018 11:58:04 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
In-Reply-To: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>
Message-ID: <1516103884.23.0.467229070634.issue32544@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I confirmed django_template is `hasattr`-heavy benchmark.

Function                            was called by...
                                        ncalls  tottime  cumtime
{built-in method builtins.hasattr}  <-       1    0.000    0.000  /home/inada-n/local/py37/lib/python3.7/site-packages/django/apps/registry.py:20(__init__)
...
                                         16318    0.003    0.003  /home/inada-n/local/py37/lib/python3.7/site-packages/django/utils/functional.py:81(__prepare_class__)
                                         90000    0.065    0.065  /home/inada-n/local/py37/lib/python3.7/site-packages/django/utils/html.py:79(conditional_escape)
                                         93200    0.064    0.064  /home/inada-n/local/py37/lib/python3.7/site-packages/django/utils/safestring.py:129(mark_safe)
                                         90000    0.075    0.075  /home/inada-n/local/py37/lib/python3.7/site-packages/django/utils/safestring.py:149(mark_for_escaping)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Tue Jan 16 07:51:42 2018
From: report at bugs.python.org (Bob Kline)
Date: Tue, 16 Jan 2018 12:51:42 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1516107102.47.0.467229070634.issue11849@psf.upfronthosting.co.za>


Bob Kline <bkline at rksystems.com> added the comment:

> ... jemalloc can reduce memory usage ...

Thanks for the tip. I downloaded the source and successfully built the DLL, then went looking for a way to get it loaded. Unfortunately, DLL injection, which is needed to use this allocator in Python, seems to be much better supported on Linux than on Windows. Basically, Microsoft's documentation [1] for AppInit_DLL, the shim for DLL injection on Windows, says (in effect) "here's how to use this technique, but we don't recommend using it, so here's a link [2] for what we recommend you do instead. That link takes you to "Try searching for what you need. This page doesn?t exist."

[1] https://support.microsoft.com/en-us/help/197571/working-with-the-appinit-dlls-registry-value
[2] https://support.microsoft.com/en-us/help/134655

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Tue Jan 16 08:14:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 13:14:22 +0000
Subject: [issue32503] Avoid creating small frames in pickle protocol 4
In-Reply-To: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>
Message-ID: <1516108462.46.0.467229070634.issue32503@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In the current form the change is trivial, just an additional check. Actually it fixes a regression introduced in issue31993. Currently even empty frames can be produced (when fast=True).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Tue Jan 16 08:14:32 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Tue, 16 Jan 2018 13:14:32 +0000
Subject: [issue32561] Add API to io objects for non-blocking reads/writes
In-Reply-To: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>
Message-ID: <1516108472.49.0.467229070634.issue32561@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

There will be lot of confusion using "buffered" & "unbuffered" terminology, since python already has BufferedIOBase (as mentioned by Martin). It would be more appropriate to create io.CachedIOBase and add non-blocking argument to open(blocking=False) to enable this feature.

----------
nosy: +YoSTEALTH

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Tue Jan 16 08:17:37 2018
From: report at bugs.python.org (Yuri Bochkarev)
Date: Tue, 16 Jan 2018 13:17:37 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
 single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1516108657.49.0.467229070634.issue11416@psf.upfronthosting.co.za>


Change by Yuri Bochkarev <baltazar.bz at gmail.com>:


----------
nosy: +Yuri.Bochkarev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Tue Jan 16 08:37:58 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Tue, 16 Jan 2018 13:37:58 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1516109878.89.0.467229070634.issue31368@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

According to this nginx test https://www.nginx.com/blog/thread-pools-boost-performance-9x/ there is a huge boost in performance when using thread poll for File IO. It is postulated that when preadv2() & RWF_NONBLOCK feature are available it would further benefit (latency, thread sync, ...)

I am not a C coder so i can't just jump into this and code this feature (if i could i would have done it long ago). As Antoine mentioned, it needs to written at C (+ctypes) level.

I am willing to help, hit me up on #python user: stealth_

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Tue Jan 16 10:42:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 15:42:10 +0000
Subject: [issue32544] Speed up hasattr(o, name) and getattr(o, name, default)
In-Reply-To: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>
Message-ID: <1516117330.24.0.467229070634.issue32544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Cool. I always wanted to implement something similar. Nice work Naoki!

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Tue Jan 16 10:46:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 15:46:05 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516117565.62.0.467229070634.issue29240@psf.upfronthosting.co.za>


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


----------
pull_requests: +5057

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Tue Jan 16 11:34:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 16:34:26 +0000
Subject: [issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()
In-Reply-To: <1506275205.91.0.662869765666.issue31572@psf.upfronthosting.co.za>
Message-ID: <1516120466.59.0.467229070634.issue31572@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4d9aec022063dcfc4cf40ae46b1c4a968297e664 by Serhiy Storchaka in branch 'master':
bpo-31572: Get rid of PyObject_HasAttr() and _PyObject_HasAttrId() in the _io module. (#3726)
https://github.com/python/cpython/commit/4d9aec022063dcfc4cf40ae46b1c4a968297e664


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31572>
_______________________________________

From report at bugs.python.org  Tue Jan 16 11:34:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 16:34:37 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516120477.03.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset c495e799ed376af91ae2ddf6c4bcc592490fe294 by Victor Stinner in branch 'master':
Skip test_readline.test_nonascii() on C locale (#5203)
https://github.com/python/cpython/commit/c495e799ed376af91ae2ddf6c4bcc592490fe294


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Tue Jan 16 11:34:45 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Jan 2018 16:34:45 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516120485.6.0.467229070634.issue29240@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5058

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Tue Jan 16 11:38:29 2018
From: report at bugs.python.org (Varun Agrawal)
Date: Tue, 16 Jan 2018 16:38:29 +0000
Subject: [issue32559] logging - public function to get level from name
In-Reply-To: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>
Message-ID: <1516120709.07.0.467229070634.issue32559@psf.upfronthosting.co.za>


Varun Agrawal <varagrawal at gmail.com> added the comment:

The request is not to set the level but to get the level given the level name aka textual representation. For example, passing in INFO should return 20 and passing in CRITICAL should return 50.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Tue Jan 16 11:52:09 2018
From: report at bugs.python.org (Nitish)
Date: Tue, 16 Jan 2018 16:52:09 +0000
Subject: [issue32536] ast and tokenize disagree about line number
In-Reply-To: <1515759409.32.0.467229070634.issue32536@psf.upfronthosting.co.za>
Message-ID: <1516121529.49.0.467229070634.issue32536@psf.upfronthosting.co.za>


Change by Nitish <nitishch at protonmail.com>:


----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32536>
_______________________________________

From report at bugs.python.org  Tue Jan 16 12:05:47 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 17:05:47 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516122347.72.0.467229070634.issue32534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I ran the benchmarks here (Ubuntu 16.04, Core i5-2500K, PGO and LTO disabled) and I don't get any consistent speedup, which is more in line with what I was expecting:
https://gist.github.com/pitrou/29eb7592fa1eae2be390f3bfa3db0a3a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 12:09:05 2018
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Tue, 16 Jan 2018 17:09:05 +0000
Subject: [issue32570] Python crash 0xc00000fd Windows10 x64 - "fail without
 words"
Message-ID: <1516122545.09.0.467229070634.issue32570@psf.upfronthosting.co.za>


New submission from ?????? ????????? <vasilij.kolomiets at gmail.com>:

The code https://ideone.com/ctx92s works for 1 000 000. 
But on my PC it works only for 1024.
Wen i am trting give him 1 000 000 - the Python crashes without any words:
https://i.stack.imgur.com/1do06.png
and in windows we can found this crash report: https://i.stack.imgur.com/nruoa.png
---
so it works for low values and crashes on higher values. Buy its no bug...
Than - What is it?

----------
components: Windows
messages: 310095
nosy: Vasyl Kolomiets, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python crash  0xc00000fd Windows10 x64  -  "fail without words"
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32570>
_______________________________________

From report at bugs.python.org  Tue Jan 16 12:26:48 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 16 Jan 2018 17:26:48 +0000
Subject: [issue32559] logging - public function to get level from name
In-Reply-To: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>
Message-ID: <1516123608.44.0.467229070634.issue32559@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

You could use `getattr(logging, levelname)` for that purpose.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Tue Jan 16 12:27:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 17:27:36 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516123656.09.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset c2740e8a263e76427a8102a89f4b491a3089b2a1 by Victor Stinner (Miss Islington (bot)) in branch '3.6':
Skip test_readline.test_nonascii() on C locale (GH-5203) (#5204)
https://github.com/python/cpython/commit/c2740e8a263e76427a8102a89f4b491a3089b2a1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Tue Jan 16 12:59:38 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 16 Jan 2018 17:59:38 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516125578.5.0.467229070634.issue32410@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 6b5a27975a415108a5eac12ee302bf2b3233f4d4 by Andrew Svetlov in branch 'master':
bpo-32410: Implement loop.sock_sendfile() (#4976)
https://github.com/python/cpython/commit/6b5a27975a415108a5eac12ee302bf2b3233f4d4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:06:33 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Jan 2018 18:06:33 +0000
Subject: [issue32403] date,
 time and datetime alternate constructors should take fast
 construction path
In-Reply-To: <1513893074.5.0.213398074469.issue32403@psf.upfronthosting.co.za>
Message-ID: <1516125993.97.0.467229070634.issue32403@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:


New changeset 9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1 by Alexander Belopolsky (Paul Ganssle) in branch 'master':
bpo-32403: Faster date and datetime constructors (#4993)
https://github.com/python/cpython/commit/9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32403>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:06:34 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Jan 2018 18:06:34 +0000
Subject: [issue32404] fromtimestamp does not call __new__ in datetime
 subclasses
In-Reply-To: <1513893253.21.0.213398074469.issue32404@psf.upfronthosting.co.za>
Message-ID: <1516125994.15.0.714561066657.issue32404@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:


New changeset 9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1 by Alexander Belopolsky (Paul Ganssle) in branch 'master':
bpo-32403: Faster date and datetime constructors (#4993)
https://github.com/python/cpython/commit/9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32404>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:07:46 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Jan 2018 18:07:46 +0000
Subject: [issue32403] date,
 time and datetime alternate constructors should take fast
 construction path
In-Reply-To: <1513893074.5.0.213398074469.issue32403@psf.upfronthosting.co.za>
Message-ID: <1516126066.39.0.467229070634.issue32403@psf.upfronthosting.co.za>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32403>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:18:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 18:18:05 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
Message-ID: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

In issue32544 there was introduced a new private C API function _PyObject_GetAttrWithoutError() which never raises an AttributeError, but returns NULL without error set if an attribute is absent. This allowed to speed up Python builtins hasattr() and getattr() with the default argument.

But C code also could gain a benefit from this. It is common to look up an attribute and silence an AttributeError. Actually it is more common than the opposite case.

The proposed patch adds yet one function, _PyObject_GetAttrIdWithoutError(), and uses these two functions if it is possible to avoid checking an AttributeError after PyObject_GetAttr() and _PyObject_GetAttrId(). This could speed up some code, and also makes it cleaner.

----------
components: Extension Modules, Interpreter Core
messages: 310101
nosy: inada.naoki, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Speed up and clean up getting optional attributes in C code
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:21:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 18:21:45 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516126905.46.0.467229070634.issue32571@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +5059
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:46:18 2018
From: report at bugs.python.org (Hideyuki)
Date: Tue, 16 Jan 2018 18:46:18 +0000
Subject: [issue32572] Add the ftplib option, overrides the IP address.
Message-ID: <1516128378.06.0.467229070634.issue32572@psf.upfronthosting.co.za>


New submission from Hideyuki <studioes at go64.jp>:

Add the ftplib's option, overrides the IP address to be used with the PORT command.
Currently, the PORT command is sending its self IP address.
If the host is connected with NAT, it will not work.
If that command has a NAT external IP address, it is working.
So add an option to overrides the IP address sending with the PORT command.
This is useful when active FTP transfer needed on a 1:1 NAT connected host so like AWS VPC.

----------
components: Library (Lib)
messages: 310102
nosy: hideyuki
priority: normal
severity: normal
status: open
title: Add the ftplib option, overrides the IP address.
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32572>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:49:17 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 16 Jan 2018 18:49:17 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1516128557.49.0.467229070634.issue11191@psf.upfronthosting.co.za>


Change by Michael Felt <michael at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +5060
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:00:48 2018
From: report at bugs.python.org (Hideyuki)
Date: Tue, 16 Jan 2018 19:00:48 +0000
Subject: [issue32572] Add the ftplib option, overrides the IP address.
In-Reply-To: <1516128378.06.0.467229070634.issue32572@psf.upfronthosting.co.za>
Message-ID: <1516129248.54.0.467229070634.issue32572@psf.upfronthosting.co.za>


Change by Hideyuki <studioes at go64.jp>:


----------
keywords: +patch
pull_requests: +5061
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32572>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:09:54 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 16 Jan 2018 19:09:54 +0000
Subject: [issue32551] Zipfile & directory execution in 3.5.4 adds the current
 directory to sys.path
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516129794.9.0.467229070634.issue32551@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

On Windows it's the directory that contains the zip file or directory with __main__.py, not the current directory. This seems normal to me. The directory or zip file is effectively executing as a script. I can understand wanting more isolated behavior in this case, i.e. make isolated mode the default when executing a directory or zip file as a script.

    C:\>py -3.5 C:\Temp\spam
    __file__:
         C:\Temp\spam\__main__.py
    sys.path:
        C:\Temp\spam
        C:\Temp
        C:\Program Files\Python35\python35.zip
        C:\Program Files\Python35\DLLs
        C:\Program Files\Python35\lib
        C:\Program Files\Python35
        C:\Program Files\Python35\lib\site-packages

    C:\>py -3.5 C:\Temp\spam.zip
    __file__:
         C:\Temp\spam.zip\__main__.py
    sys.path:
        C:\Temp\spam.zip
        C:\Temp
        C:\Program Files\Python35\python35.zip
        C:\Program Files\Python35\DLLs
        C:\Program Files\Python35\lib
        C:\Program Files\Python35
        C:\Program Files\Python35\lib\site-packages

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:36:01 2018
From: report at bugs.python.org (Varun Agrawal)
Date: Tue, 16 Jan 2018 19:36:01 +0000
Subject: [issue32559] logging - public function to get level from name
In-Reply-To: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>
Message-ID: <1516131361.79.0.467229070634.issue32559@psf.upfronthosting.co.za>


Varun Agrawal <varagrawal at gmail.com> added the comment:

@zach.ware: True, but since we already have a getLevelName method, having a symmetric method to do the opposite made sense. Plus the method can perform error checking and other things to ensure much cleaner code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:46:28 2018
From: report at bugs.python.org (Pedro)
Date: Tue, 16 Jan 2018 19:46:28 +0000
Subject: [issue32573] sys.argv documentation should include caveat for
 embedded environments
Message-ID: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>


New submission from Pedro <pgacv2+pythonbugs at gmail.com>:

Embedded Python interpreters, such as Boost.Python, do not have sys.argv available. (sys itself works fine.) This causes the interpreter to crash with the following exception when you try to access argv:

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

I'm not sure how closely related this is to #15577 or PEP 432. A simple workaround is to manually assign a list with an empty string to argv, as suggested by https://github.com/google/oauth2client/issues/642. However, the documentation for the sys module makes no mention of this special case for argv, and the line at the top that says "It is always available" can easily be interpreted to mean that *all* of sys's attributes will always be available. I suggest adding the following to the documentation for sys.argv:

========

Since `argv` contains the list of **command line** arguments passed to the Python interpreter, `argv` is not available within embedded interpreters, and scripts that run in embedded environments will raise an `AttributeError` when they attempt to access `argv`. As a workaround, assign a list with an empty string manually:
```
import sys

if not hasattr(sys, 'argv'):
    sys.argv  = ['']
```

----------
assignee: docs at python
components: Documentation
messages: 310105
nosy: docs at python, pgacv2
priority: normal
severity: normal
status: open
title: sys.argv documentation should include caveat for embedded environments
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:52:58 2018
From: report at bugs.python.org (Jay Crotts)
Date: Tue, 16 Jan 2018 19:52:58 +0000
Subject: [issue8243] curses writing to window's bottom right position raises:
 `_curses.error: addstr() returned ERR'
In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za>
Message-ID: <1516132378.01.0.467229070634.issue8243@psf.upfronthosting.co.za>


Jay Crotts <crotts.jay at gmail.com> added the comment:

Submitted a PR for this issue, awaiting review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8243>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:53:39 2018
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Melero_Fern=C3=A1ndez?=)
Date: Tue, 16 Jan 2018 19:53:39 +0000
Subject: [issue32574] asyncio.Queue, put() leaks memory if the queue is full
Message-ID: <1516132419.05.0.467229070634.issue32574@psf.upfronthosting.co.za>


New submission from Jos? Melero Fern?ndez <jmelerofernandez at gmail.com>:

Repro: asyncio queue with limited size and the queue full, call asyncio.wait_for(some_queue.put(1), some_timeout). Every canceled put produces a new item in queue._putters that is never deleted (memory leak). 

Uploaded to the issue a file with an example.

The get method had a very similar bug which was fixed in 2016-11. The related issue:
https://bugs.python.org/issue31620

I already have the code for the PR prepared, so I want to publish the link of the MR in a few of minutes.

----------
components: asyncio
files: asyncio_put_memory_leak.py
messages: 310107
nosy: Mordis, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Queue, put() leaks memory if the queue is full
type: resource usage
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47388/asyncio_put_memory_leak.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32574>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:56:50 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Jan 2018 19:56:50 +0000
Subject: [issue32573] sys.argv documentation should include caveat for
 embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516132610.67.0.467229070634.issue32573@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A better question might be: is there something in the embedding framework that should initialize argv to the empty list?  embedding framework here could have two meanings: either the third party code, or the code that we provide for supporting embedding.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:00:05 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Jan 2018 20:00:05 +0000
Subject: [issue14976] queue.Queue() is not reentrant,
 so signals and GC can cause deadlocks
In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>
Message-ID: <1516132805.14.0.467229070634.issue14976@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Catalin has been examining code... switching concurrent.futures.thread to use SimpleQueue instead of Queue is probably a good idea as the queues in there get used from weakref callbacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14976>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:00:25 2018
From: report at bugs.python.org (xoviat)
Date: Tue, 16 Jan 2018 20:00:25 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516132825.77.0.467229070634.issue32516@psf.upfronthosting.co.za>


xoviat <xoviat at gmail.com> added the comment:

As Nathaniel noted, the "solution" of placing DLLs in the same directory as extension modules is not a solution. I also think that some people here misunderstand my proposal: I'm not necessarily proposing that these directories are added using an import hook: they could be added on startup through a scan of site-packages.

"However, even if this were implemented we'd still need to write and maintain the __init__.py injection code for the next ~5 years, so probably the thing to do is to implement the __init__.py approach first and wait to see how it shakes out before considering interpreter changes."

Yes, this approach is already implemented in NumPy and SciPy. I'm also implementing it for other packages as well. However, the principal reason that I'm opening this issue is that Ray complained that packages shouldn't be altering the DLL search path: the only other solution that I can see is to make this documented behavior, only on Windows, and only because the Windows developers (and I'm in no way anti-Windows, but I'm just frustrated with this particular issue) decided to place an arbitrary limit on probingPath.

As far as the complaints about rpath: this is a mechanism used by every single manylinux and actually most OSX wheels, and it works perfectly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:00:46 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jan 2018 20:00:46 +0000
Subject: [issue14976] queue.Queue() is not reentrant,
 so signals and GC can cause deadlocks
In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>
Message-ID: <1516132846.54.0.467229070634.issue14976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you open a new issue for it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14976>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:02:28 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 16 Jan 2018 20:02:28 +0000
Subject: [issue32549] Travis: Test with OpenSSL 1.1.0
In-Reply-To: <1515926387.7.0.467229070634.issue32549@psf.upfronthosting.co.za>
Message-ID: <1516132948.56.0.467229070634.issue32549@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset ced9cb5303ad1447f84d923e0c7f769f5e0c6297 by Christian Heimes in branch 'master':
bpo-32549: Compile OpenSSL 1.1.0 on Travis CI (#5180)
https://github.com/python/cpython/commit/ced9cb5303ad1447f84d923e0c7f769f5e0c6297


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32549>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:05:45 2018
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Melero_Fern=C3=A1ndez?=)
Date: Tue, 16 Jan 2018 20:05:45 +0000
Subject: [issue32574] asyncio.Queue, put() leaks memory if the queue is full
In-Reply-To: <1516132419.05.0.467229070634.issue32574@psf.upfronthosting.co.za>
Message-ID: <1516133145.18.0.467229070634.issue32574@psf.upfronthosting.co.za>


Change by Jos? Melero Fern?ndez <jmelerofernandez at gmail.com>:


----------
keywords: +patch
pull_requests: +5062
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32574>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:06:33 2018
From: report at bugs.python.org (David Chin)
Date: Tue, 16 Jan 2018 20:06:33 +0000
Subject: [issue26692] cgroups support in multiprocessing
In-Reply-To: <1459817171.82.0.158211239936.issue26692@psf.upfronthosting.co.za>
Message-ID: <1516133193.21.0.467229070634.issue26692@psf.upfronthosting.co.za>


David Chin <david.w.h.chin at gmail.com> added the comment:

I would like to state strong support if is.get_usable_cpu_count()

I administer a typical HPC cluster which may have multiple jobs scheduled on the same physical server. The fact that multiprocessing ignores cgroups leads to bad oversubscription.

----------
nosy: +hairygristle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26692>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:46:17 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 20:46:17 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516135577.59.0.467229070634.issue32516@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> However, the principal reason that I'm opening this issue is that Ray complained that packages shouldn't be altering the DLL search path

If that's crucial context, can you link to it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 15:53:22 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 16 Jan 2018 20:53:22 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516136002.97.0.467229070634.issue32516@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I understood the proposal just fine, and I understand the problems involved and appreciate why the ideal isn't sufficient here.

The import hook was my proposal to let you only preload DLLs when the extension module is being loaded, rather than having to load all the DLLs on the first "import scipy" just in case one of its submodules gets imported later. A hook can trigger on a specific module.

Since there appears to be some uncertainty, package __init__.py always runs before its submodules are even resolved, so it's totally fine to modify import machinery or preload DLLs here. 

rpath is totally irrelevant here. The OS model is different and we've given you the available options on Windows (application directory, process-wide search path, explicit preloading, assembly probing path).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 16:34:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 21:34:14 +0000
Subject: [issue32573] sys.argv documentation should include caveat for
 embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516138454.53.0.467229070634.issue32573@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Tue Jan 16 17:16:02 2018
From: report at bugs.python.org (Dan Snider)
Date: Tue, 16 Jan 2018 22:16:02 +0000
Subject: [issue32575] IDLE cannot locate certain SyntaxErrors raised by
 f-string expressions
Message-ID: <1516140962.04.0.467229070634.issue32575@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

For example the following f-string

f'{1):.1%}'

IDLE will scroll to the top of the file and highlight a random and irrelevant line (not sure what it's doing tbh).

running the expression with `exec` makes it look like implicit parenthesis are added to the ends of files..

>>> exec("f'{1):.1f}'")
Traceback (most recent call last):
  File "<pyshell#2860>", line 1, in <module>
    exec("f'{1):.1f}'")
  File "<fstring>", line 1
    (1))
       ^
SyntaxError: unexpected EOF while parsing

IDLE can correctly find a `(1))` in a file but appears to fail only in f-string expressions.

----------
assignee: terry.reedy
components: IDLE
messages: 310117
nosy: bup, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE cannot locate certain SyntaxErrors raised by f-string expressions
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32575>
_______________________________________

From report at bugs.python.org  Tue Jan 16 17:38:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jan 2018 22:38:25 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516142305.39.0.467229070634.issue32248@psf.upfronthosting.co.za>


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


----------
pull_requests: +5064

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Tue Jan 16 17:51:15 2018
From: report at bugs.python.org (xoviat)
Date: Tue, 16 Jan 2018 22:51:15 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516143075.49.0.467229070634.issue32516@psf.upfronthosting.co.za>


xoviat <xoviat at gmail.com> added the comment:

This is what ray said:

"Please do not do this. Importing a specific module should not modify the way that process loads subsequent DLLs."

(https://github.com/numpy/numpy/pull/10229#issuecomment-354846459)

What I'm proposing to do is write a tool, widely used like auditwheel, that will copy shared libraries into the .libs folder and then patch __init__.py in all packages in order to modify the DLL search path to add these folders.

If everyone's okay with that, we can close this issue. But if everyone's not okay with that, then we need to document that it's Python's responsibility to do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 17:58:34 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 16 Jan 2018 22:58:34 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516143514.8.0.467229070634.issue32248@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
pull_requests:  -5016

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Tue Jan 16 18:09:54 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 16 Jan 2018 23:09:54 +0000
Subject: [issue32575] IDLE cannot locate certain SyntaxErrors raised by
 f-string expressions
In-Reply-To: <1516140962.04.0.467229070634.issue32575@psf.upfronthosting.co.za>
Message-ID: <1516144194.12.0.467229070634.issue32575@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This is not an IDLE bug, per se. There's a known problem with f-strings not producing the correct line numbers. See issue #29051. Unless Terry thinks there's something IDLE-specific here, I suggest closing this as a duplicate.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32575>
_______________________________________

From report at bugs.python.org  Tue Jan 16 18:48:56 2018
From: report at bugs.python.org (Dmitry Kazakov)
Date: Tue, 16 Jan 2018 23:48:56 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1516146536.69.0.467229070634.issue31299@psf.upfronthosting.co.za>


Change by Dmitry Kazakov <waultah+py at gmail.com>:


----------
pull_requests: +5065
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Tue Jan 16 19:07:53 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 00:07:53 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516147673.31.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

Victor: I?m booting with the isolcpus and rcu_nocbs flags, and running pyperformance with the --affinity flag to pin the benchmark to the isolated CPU cores. I?ve also run `perf system tune`. And the OS is Ubuntu 17.10. Thanks for the tip on using perf timeit instead of timeit. I?ve run the benchmark that you've suggested with a minor change (to avoid the cost of LOAD_ATTR) and attached the output on a gist[1].

Antoine: Thanks for benchmarking it. After looking at the generated assembly[2], I found that ins1 is being inlined and the call to memmove was appearing before the loop (possibly because the compiler assumes that the call to memmove is more likely). I made a minor change and increased the threshold to 32. I?ve attached the generated assembly in a gist[3] (The relevant sequence is around line 8406, if you?re interested). And here?s the pyperformance comparison[4]. Could you please try benchmarking this version on your machine?

[1]: https://gist.github.com/jeethu/2d2de55afdb8ea4ad03b6a5d04d5227f
[2]: Generated with ?gcc -DNDEBUG -fwrapv -O3 -std=c99  -I. -I./Include -DPy_BUILD_CORE -S -masm=intel Objects/listobject.c?
[3]: https://gist.github.com/jeethu/596bfc1251590bc51cc230046b52fb38
[4]: https://gist.github.com/jeethu/d6e4045f7932136548a806380eddd030

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 19:28:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 00:28:43 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516148923.65.0.467229070634.issue32534@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I?ve run the benchmark that you've suggested with a minor change (to avoid the cost of LOAD_ATTR)

Be careful. Moving "l.insert" lookup of the loop might make the code slower. I never looked why. But Python 3.7 was also optimized in many places to call methods, so I'm not sure anymore :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 19:56:55 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 00:56:55 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516150615.35.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

> Be careful. Moving "l.insert" lookup of the loop might make the code slower. I never looked why. But Python 3.7 was also optimized in many places to call methods, so I'm not sure anymore :)

Thanks again! Here's a gist without the hack[1].

[1]: https://gist.github.com/jeethu/19430d802aa08e28d1cb5eb20a47a470

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:00:52 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Jan 2018 01:00:52 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516150852.3.0.467229070634.issue32516@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I am very okay with it not being Python's responsibility to do this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:04:09 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 17 Jan 2018 01:04:09 +0000
Subject: [issue32576] concurrent.futures.thread potential deadlock due to
 Queue in weakref callback
Message-ID: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

As a follow up to https://bugs.python.org/issue14976 which just introduced queue.SimpleQueue:

concurrent.futures.thread currently uses a queue.Queue() from weakref callbacks which could in theory lead to a deadlock when periodic gc triggers a cleanup invalidating some weakrefed objects at an inopportune time while Python code has the queue's lock held.

I don't have a test case proving this (deadlocks are hard).

Switching it to use a SimpleQueue should avoid the problem?

...

This and the C extension module based SimpleQueue would be good to backport to https://pypi.python.org/pypi/futures as well.

----------
messages: 310124
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: concurrent.futures.thread potential deadlock due to Queue in weakref callback
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:04:26 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 17 Jan 2018 01:04:26 +0000
Subject: [issue14976] queue.Queue() is not reentrant,
 so signals and GC can cause deadlocks
In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>
Message-ID: <1516151066.01.0.467229070634.issue14976@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

https://bugs.python.org/issue32576 filed for that

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14976>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:12:44 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 17 Jan 2018 01:12:44 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516151564.79.0.467229070634.issue32516@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Steve said:
> The import hook was my proposal to let you only preload DLLs when the extension module is being loaded, rather than having to load all the DLLs on the first "import scipy" just in case one of its submodules gets imported later. A hook can trigger on a specific module.

That's a good point: we could write an import hook that examines each .pyd before it's loaded, and then preloads just the .dlls that it's looking for. But... that's literally reimplementing what the normal DLL loader does. If we can get the normal DLL loader to work, it's probably going to be simpler. And so long as we're talking specifically about the case where it's a directory we control and that only contains .dlls with mangled names, then it seems fine to me. (And maybe Ray will have to hold his nose, but, well, you know. That's programming sometimes.)

xoviat said:
> This is what ray said:
> "Please do not do this. Importing a specific module should not modify the way that process loads subsequent DLLs."

I'm not sure what Ray's worried about exactly, but I don't see anything in his comment that makes me think moving the DLL path manipulation code into the interpreter will make him happier.

I think this can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:17:41 2018
From: report at bugs.python.org (Pedro)
Date: Wed, 17 Jan 2018 01:17:41 +0000
Subject: [issue32573] sys.argv documentation should include caveat for
 embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516151861.84.0.467229070634.issue32573@psf.upfronthosting.co.za>


Pedro <pgacv2+pythonbugs at gmail.com> added the comment:

My first inclination would be no. An argv value of [''] means "zero command-line arguments" (not even a filename), which implies the following as far as I know:
1. Python was called as an executable rather than a library, because you can't pass command-line arguments to a library
2. No arguments were passed to the executable
3. You are running from inside the REPL

All three are false in an embedded context.

A not-much-better-but-maybe-worth-considering question might also be: should scripts be able to tell whether they are being run from an embedded interpreter? If so, do they have any other way of doing so if an initialization is forced for argv?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:18:59 2018
From: report at bugs.python.org (Pedro)
Date: Wed, 17 Jan 2018 01:18:59 +0000
Subject: [issue32573] sys.argv documentation should include caveat for
 embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516151939.92.0.467229070634.issue32573@psf.upfronthosting.co.za>


Pedro <pgacv2+pythonbugs at gmail.com> added the comment:

My comment above uses "code that we provide for supporting embedding," not "third party code," as the definition of embedded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:52:30 2018
From: report at bugs.python.org (xoviat)
Date: Wed, 17 Jan 2018 01:52:30 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516153950.09.0.467229070634.issue32516@psf.upfronthosting.co.za>


xoviat <xoviat at gmail.com> added the comment:

For the record, moving the DLL path manipulation code into the interpreter would address the concern that importing a module would not manipulate the search path because the behavior would move into Python itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 21:08:03 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Jan 2018 02:08:03 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516154883.86.0.467229070634.issue32516@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

The import hook could theoretically modify the search path before and after loading the module, though that could make debugging a real pain.

I was also thinking of just having an explicit list of DLLs to load, rather than inspecting the binary. Per-module preloading is as fine grained as you can get though it still won't help if another import has loaded a different DLL by the same name. This is where you can't avoid recompilation or activation contexts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 21:33:28 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 02:33:28 +0000
Subject: [issue28521] _PyEval_RequestCodeExtraIndex should return a globally
 valid index, not a ThreadState specific one
In-Reply-To: <1477323145.97.0.665032370713.issue28521@psf.upfronthosting.co.za>
Message-ID: <1516156408.45.0.467229070634.issue28521@psf.upfronthosting.co.za>


Change by Jeethu Rao <jeethu at jeethurao.com>:


----------
nosy: +jeethu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28521>
_______________________________________

From report at bugs.python.org  Tue Jan 16 21:43:32 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 02:43:32 +0000
Subject: [issue30604] co_extra_freefuncs is stored thread locally and can lead
 to crashes
In-Reply-To: <1496957823.48.0.898285168896.issue30604@psf.upfronthosting.co.za>
Message-ID: <1516157012.31.0.467229070634.issue30604@psf.upfronthosting.co.za>


Change by Jeethu Rao <jeethu at jeethurao.com>:


----------
nosy: +jeethu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30604>
_______________________________________

From report at bugs.python.org  Tue Jan 16 22:00:48 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 17 Jan 2018 03:00:48 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516158048.32.0.467229070634.issue32516@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> it still won't help if another import has loaded a different DLL by the same name. This is where you can't avoid recompilation or activation contexts.

Ah, there's an important bit of context you're missing: there is actually a third option :-)

https://github.com/njsmith/machomachomangler#pe-features

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 22:30:31 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Jan 2018 03:30:31 +0000
Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files
In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za>
Message-ID: <1516159831.4.0.467229070634.issue29319@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Tweaking metadata to make it clear Py3.5 was also updated.

----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29319>
_______________________________________

From report at bugs.python.org  Tue Jan 16 22:38:38 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Jan 2018 03:38:38 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516160318.17.0.467229070634.issue32516@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

That looks like recompilation (or at least how recompilation would look if you'd been granted permission). Assuming you can recompile the binary, you could rename the dependency and regenerate the import library so that you can link directly against the new name.

As an official position, I don't support modifying other people's PE files or distributing the modified results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 22:42:23 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Jan 2018 03:42:23 +0000
Subject: [issue32551] Zipfile & directory execution in 3.5.4 also adds the
 parent directory to sys.path
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516160543.9.0.467229070634.issue32551@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Good catch Eryk, I misdiagnosed what was going on, since the current directory and the parent directory were the same location in Ned's particular example.

I double checked, and we resolve symlinks in path entries *before* performing the incorrect directory traversal ("..." below indicates the usual standard path entries, "/tmp" is the unexpected entry introduced by the bug), so it isn't possible to use a symlink to get a user-controlled directory onto the path:

```
$ ./python /tmp/spam
/tmp/spam
/tmp
...
$ ln -s /tmp/spam /tmp/mydir/malicious
$ ./python /tmp/mydir/malicious
/tmp/mydir/malicious
/tmp
...
```

That means that as far as I can tell, this is just a plain old bug, rather than a potential security concern (since privileged admin-controlled commands tend generally live in admin-controlled directories, as if they didn't, potential attackers would be able to replace them with arbitrary code directly)

----------
title: Zipfile & directory execution in 3.5.4 adds the current directory to sys.path -> Zipfile & directory execution in 3.5.4 also adds the parent directory to sys.path

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Tue Jan 16 22:48:14 2018
From: report at bugs.python.org (xoviat)
Date: Wed, 17 Jan 2018 03:48:14 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516160894.28.0.467229070634.issue32516@psf.upfronthosting.co.za>


xoviat <xoviat at gmail.com> added the comment:

Just to be clear, I'm not considering doing this with respect to the C/C++ runtimes, but all of the other shared libraries. And in case you weren't aware, this is exactly what auditwheel does (except that I believe it uses patchelf, whereas I will be using Nathaniel's tool).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 22:53:54 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 17 Jan 2018 03:53:54 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <1516161234.52.0.467229070634.issue32516@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> That looks like recompilation (or at least how recompilation would look if you'd been granted permission). Assuming you can recompile the binary, you could rename the dependency and regenerate the import library so that you can link directly against the new name.

Perhaps *you* can do that, but I don't think you want to volunteer to maintain Windows wheels for every package on PyPI :-). Regenerating import libraries and tweaking build systems and all that works fine if you're a Windows specialist distributing artisinal hand-crafted builds, but you can't automate that knowledge and use it at scale. You *can* write an automatic tool that slurps in a bunch of PE files and rewrites them to create a self-contained DLL-hell-free redistributable. This is the core strategy that osx and manylinux wheels have been using for years now, and why it's possible for random devs to make wheels that work, even on platforms they don't use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Tue Jan 16 23:38:51 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 17 Jan 2018 04:38:51 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516163931.94.0.467229070634.issue32534@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, we've encountered a number of situations in the past when something that improved the timings on one compiler would make timings worse on another compiler.  There was also variance between timings on 32-bit builds versus 64-bit builds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Tue Jan 16 23:42:22 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 17 Jan 2018 04:42:22 +0000
Subject: [issue32559] logging - public function to get level from name
In-Reply-To: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>
Message-ID: <1516164142.7.0.467229070634.issue32559@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> The request is not to set the level but to get the level 
> given the level name aka textual representation. 
> For example, passing in INFO should return 20 and passing
> in CRITICAL should return 50.

Why do we care about this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Wed Jan 17 00:27:28 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Jan 2018 05:27:28 +0000
Subject: [issue32573] sys.argv documentation should include caveat for
 embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516166848.42.0.467229070634.issue32573@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There are actually 3 attributes that may be absent when CPython itself isn't managing the C level entry point: sys.argv, sys.warnoptions, and sys._xoptions.

I'd be more inclined to make the implementation match the docs though, and have these all be empty lists in the not-configured case, rather than absent entirely. (Accessing sys.argv[0] would still be an error in that situation, just an IndexError instead of an AttributeError)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Wed Jan 17 01:14:29 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 17 Jan 2018 06:14:29 +0000
Subject: [issue32577] Pip creates entry point commands in the wrong place when
 invoked in a venv nested in a virtualenv
Message-ID: <1516169669.76.0.467229070634.issue32577@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

(I?m not sure whether this is a venv or virtualenv problem. Asking here first.)

To reproduce:

    $ python3.6 -m virtualenv outer
    $ ./outer/bin/python -m venv inner
    $ ls inner/bin
    activate  activate.csh  activate.fish  python  python3

In comparison:

    $ python3.6 -m venv another
    $ ls another/bin
    activate         easy_install     pip3             python3
    activate.csh     easy_install-3.6 pip3.6           python3.6
    activate.fish    pip              python

All commands that pip is supposed to populate are missing

Pip can install packages correctly, but the entry points are populated not inside the inner venv, but the outer virtualenv:

    $ ./inner/bin/python -m pip install django
    ....
    $ ls inner/bin
    activate  activate.csh  activate.fish  python  python3
    $ ls outer/bin
    ... django-admin django-admin.py

The entry points correctly point to the inner environment. They are just in the wrong directory.

----------
components: Library (Lib)
messages: 310140
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32577>
_______________________________________

From report at bugs.python.org  Wed Jan 17 01:25:43 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Jan 2018 06:25:43 +0000
Subject: [issue32575] IDLE cannot locate certain SyntaxErrors raised by
 f-string expressions
In-Reply-To: <1516140962.04.0.467229070634.issue32575@psf.upfronthosting.co.za>
Message-ID: <1516170343.49.0.467229070634.issue32575@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Syntax errors come from Python, not IDLE.  Except for the pseudofile name ('<pyshell*nnnn>' versus '<stdin>'), the message is the same as the interactive interpreter.  Anytime one thinks IDLE has a bug, one should check the standard interactive interpreter as a 'control'.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Improve error reporting involving f-strings (PEP 498)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32575>
_______________________________________

From report at bugs.python.org  Wed Jan 17 01:41:09 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Jan 2018 06:41:09 +0000
Subject: [issue32559] logging - public function to get level from name
In-Reply-To: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>
Message-ID: <1516171269.13.0.467229070634.issue32559@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I don't think a strong enough case has been made for adding this enhancement.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Wed Jan 17 03:35:43 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 17 Jan 2018 08:35:43 +0000
Subject: [issue32516] Add a shared library mechanism for win32
In-Reply-To: <1516153950.09.0.467229070634.issue32516@psf.upfronthosting.co.za>
Message-ID: <60a04c66-e4df-98d6-1d3f-470c5def4914@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 17.01.2018 02:52, xoviat wrote:
> 
> xoviat <xoviat at gmail.com> added the comment:
> 
> For the record, moving the DLL path manipulation code into the interpreter would address the concern that importing a module would not manipulate the search path because the behavior would move into Python itself.

Can't you simply place the DLLs into the PythonXX\DLLs\ directory ?

That's where Python itself keeps external DLLs (and several PYDs)
and it won't change after installation of Python.

Or create a special container package on PyPI into which you place
the DLLs and add dependencies to this in all other packages.

You can then load the DLL via win32 LoadLibrary either using the
Python win32 tools or ctypes:

https://docs.python.org/3.7/library/ctypes.html
http://timgolden.me.uk/pywin32-docs/win32api__LoadLibrary_meth.html
https://www.programcreek.com/python/example/51388/win32api.LoadLibrary

FWIW: I think this ticket has shown plenty options to possible
solutions, including many which do not manipulate the path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Wed Jan 17 04:26:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 09:26:11 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516181171.31.0.467229070634.issue32248@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 44a70e9336765404057b12345465844dc291297a by Victor Stinner in branch 'master':
Fix Git attributes of test_importlib data files (#5209)
https://github.com/python/cpython/commit/44a70e9336765404057b12345465844dc291297a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 17 04:31:50 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 17 Jan 2018 09:31:50 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1516181510.06.0.467229070634.issue11192@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

Back to master (python3-3.7)

(note: not your problem - but this link is gone: not a python problem, see closed aix issue http://www-01.ibm.com/support/docview.wss?uid=isg1IZ57712)

Getting this (obviously) on AIX 5.3, but also on AIX 6.1 (TL6), but not on AIX 7.1 TL2: (both gcc and xlc)

testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testGetaddrinfo (test.test_socket.GeneralModuleTests) ... FAIL
testHostnameRes (test.test_socket.GeneralModuleTests) ... ok

However, what I get on all three systems (but do not see on the AIX buildbot running on AIX 7.2, and I have no access to AIX 7.2) is:

AIX 6.1:
Ran 669 tests in 25.899s

FAILED (failures=1, errors=114, skipped=119)

AIX 7.1:

Ran 669 tests in 25.917s

FAILED (errors=114, skipped=119)

What all the ERRORS have in common is:

  File "/data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py", line 2373, in setUp
    self.serv_sock.settimeout(self.fail_timeout)
AttributeError: 'SendmsgTests' object has no attribute 'serv_sock'

HTH - (and still digging)

----------
versions: +Python 3.7 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Wed Jan 17 04:45:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 09:45:26 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516182326.27.0.467229070634.issue32534@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

https://gist.github.com/jeethu/19430d802aa08e28d1cb5eb20a47a470

Mean +- std dev: 10.5 us +- 1.4 us => Mean +- std dev: 9.68 us +- 0.89 us

It's 1.08x faster (-7.8%). It's small for a microbenchmark, usually an optimization should make a *microbenchmark* at least 10% faster.

For this optimization, I have no strong opinion.


Using memmove() for large copy is a good idea. The main question is the "if (n <= INS1_MEMMOVE_THRESHOLD)" test. Is it slower if we always call memmove()?


Previously, Python had a Py_MEMCPY() macro which also had such threshold. Basically, it's a workaround for compiler performance issues:

#if defined(_MSC_VER)
#define Py_MEMCPY(target, source, length) do {                          \
        size_t i_, n_ = (length);                                       \
        char *t_ = (void*) (target);                                    \
        const char *s_ = (void*) (source);                              \
        if (n_ >= 16)                                                   \
            memcpy(t_, s_, n_);                                         \
        else                                                            \
            for (i_ = 0; i_ < n_; i_++)                                 \
                t_[i_] = s_[i_];                                        \
    } while (0)
#else
#define Py_MEMCPY memcpy
#endif

Hopefully, the macro now just became:

/* Py_MEMCPY is kept for backwards compatibility,
 * see https://bugs.python.org/issue28126 */
#define Py_MEMCPY memcpy

And it's no more used.


I recall a performance issues with GCC memcmp() builtin function (replacing the libc function during the compilation): https://bugs.python.org/issue17628#msg186012

See also:
* https://bugs.python.org/issue13134
* https://bugs.python.org/issue29782

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 04:56:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 09:56:48 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516183008.48.0.467229070634.issue32493@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> New changeset b4ebaa7099c3413b42a97777581c4ca560fe7540 by Antoine Pitrou (David Carlier) in branch 'master':
> bpo-32493: Not only AIX, but FreeBSD has uuid_create support (#5089)

This change introduced a regression on AMD64 FreeBSD 10.x Shared 3.x:

http://buildbot.python.org/all/#/builders/87/builds/463

======================================================================
FAIL: test_uuid1 (test.test_uuid.TestUUIDWithExtModule)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_uuid.py", line 320, in test_uuid1
    equal(u.version, 1)
AssertionError: 14 != 1

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:16:53 2018
From: report at bugs.python.org (David CARLIER)
Date: Wed, 17 Jan 2018 10:16:53 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516184213.8.0.467229070634.issue32493@psf.upfronthosting.co.za>


David CARLIER <devnexen at gmail.com> added the comment:

Might comes from uuid1 function itself ... e.g. line 704 not setting version "field".

----------
nosy: +David CARLIER2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:23:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 10:23:03 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1516184583.96.0.467229070634.issue32226@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Since the commit 45700fb757591a672e9d25b8252971c2a2caeaf2, test_genericclass leaks references:
---
vstinner at apu$ ./python -m test -R 3:3 test_genericclass -m test.test_genericclass.CAPITest.test_c_class
Run tests sequentially
0:00:00 load avg: 1.27 [1/1] test_genericclass
beginning 6 repetitions
123456
......
test_genericclass leaked [2, 3, 2] memory blocks, sum=7
test_genericclass failed

1 test failed:
    test_genericclass

Total duration: 107 ms
Tests result: FAILURE
---

The leak comes from _testcapi.Generic[int]. Maybe from generic_alias_new() of Modules/_testcapi.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:28:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 10:28:39 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1516184919.62.0.467229070634.issue32226@psf.upfronthosting.co.za>


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


----------
pull_requests: +5066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:29:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 10:29:11 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1516184951.63.0.467229070634.issue32226@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh ok, I think that I found the bug: PR 5212.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:32:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 10:32:06 +0000
Subject: [issue32578] x86-64 Sierra 3.6: test_asyncio fails with timeout after
 15 minutes
Message-ID: <1516185126.6.0.467229070634.issue32578@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

test_asyncio started to fail at build 163:

http://buildbot.python.org/all/#/builders/20/builds/163
(...)
test_legacy_create_ssl_connection (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_ssl_unix_connection (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl_verified (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl_verify_failed (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_prompt_cancellation (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_read_pipe (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
Timeout (0:15:00)!
Thread 0x00007fffb5eee340 (most recent call first):
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/selectors.py", line 577 in select
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 1396 in _run_once
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 422 in run_forever
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 455 in run_until_complete
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py", line 1536 in test_read_pty_output
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 555 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 600 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py", line 2232 in test_read_pty_output
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 600 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/case.py", line 605 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/case.py", line 653 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/runner.py", line 176 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 1887 in _run_suite
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 1977 in run_unittest
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 172 in test_runner
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 173 in runtest_inner
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 137 in runtest
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 290 in rerun_failed_tests
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 539 in _main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 509 in main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 584 in main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/__main__.py", line 2 in <module>
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", line 85 in _run_code
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", line 193 in _run_module_as_main
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=2527.463349
test_read_pty_output (test.test_asyncio.test_events.KqueueEventLoopTests) ...

----------
messages: 310151
nosy: vstinner
priority: normal
severity: normal
status: open
title: x86-64 Sierra 3.6: test_asyncio fails with timeout after 15 minutes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32578>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:33:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 10:33:20 +0000
Subject: [issue32578] x86-64 Sierra 3.6: test_asyncio fails with timeout after
 15 minutes
In-Reply-To: <1516185126.6.0.467229070634.issue32578@psf.upfronthosting.co.za>
Message-ID: <1516185200.83.0.467229070634.issue32578@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Maybe we should just give more time to this buildbot worker, extend the timeout to 30 minutes for example?

----------
components: +Tests
nosy: +zach.ware
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32578>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:37:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 10:37:00 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516185420.1.0.467229070634.issue32248@psf.upfronthosting.co.za>


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


----------
pull_requests: +5067

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 17 06:32:31 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 17 Jan 2018 11:32:31 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516188751.34.0.467229070634.issue32571@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Can I ask why this is a private API? It's extremely useful for extension modules too. For example, numpy has been carrying around a reimplementation of PyObject_GetAttr for years, exactly to avoid the cost of creating an AttributeError exception in common cases:

https://github.com/numpy/numpy/blob/master/numpy/core/src/private/get_attr_string.h

(To emphasize the similarity, note that the code above used to be called PyArray_GetAttrString_SuppressException, until a refactoring last year: https://github.com/numpy/numpy/commit/69a423b23492ecf8471efc4e59ab8a93b03d8454. It's always been specifically used for looking up numpy-specific special methods like __array__, __array_interface__, etc., though, which is why it can get away with those shortcuts -- we know they usually aren't defined.)

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Wed Jan 17 06:34:05 2018
From: report at bugs.python.org (David CARLIER)
Date: Wed, 17 Jan 2018 11:34:05 +0000
Subject: [issue32579] UUID module fix, uuid1 python module function
Message-ID: <1516188845.07.0.467229070634.issue32579@psf.upfronthosting.co.za>


New submission from David CARLIER <devnexen at gmail.com>:

Spotted to UUID unit tests https://bugs.python.org/issue32493

----------
components: Library (Lib)
messages: 310154
nosy: David CARLIER2
priority: normal
pull_requests: 5068
severity: normal
status: open
title: UUID module fix, uuid1 python module function
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32579>
_______________________________________

From report at bugs.python.org  Wed Jan 17 06:50:32 2018
From: report at bugs.python.org (Nitish)
Date: Wed, 17 Jan 2018 11:50:32 +0000
Subject: [issue32536] ast and tokenize disagree about line number
In-Reply-To: <1515759409.32.0.467229070634.issue32536@psf.upfronthosting.co.za>
Message-ID: <1516189832.94.0.467229070634.issue32536@psf.upfronthosting.co.za>


Nitish <nitishch at protonmail.com> added the comment:

What should happen ideally? The stray '\r' be treated like a whitespace?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32536>
_______________________________________

From report at bugs.python.org  Wed Jan 17 06:55:57 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jan 2018 11:55:57 +0000
Subject: [issue32576] concurrent.futures.thread potential deadlock due to
 Queue in weakref callback
In-Reply-To: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>
Message-ID: <1516190157.71.0.467229070634.issue32576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We could also switch multiprocessing.Pool.  Unfortunately some code in multiprocessing.Pool relies on internal details of queue.Queue (!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Wed Jan 17 07:10:52 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jan 2018 12:10:52 +0000
Subject: [issue32576] concurrent.futures.thread potential deadlock due to
 Queue in weakref callback
In-Reply-To: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>
Message-ID: <1516191052.63.0.467229070634.issue32576@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5069
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Wed Jan 17 07:52:29 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 17 Jan 2018 12:52:29 +0000
Subject: [issue19417] Bdb: add a unittest file (test.test_bdb)
In-Reply-To: <1382896308.72.0.45441786626.issue19417@psf.upfronthosting.co.za>
Message-ID: <1516193549.69.0.467229070634.issue19417@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +5070

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Wed Jan 17 07:57:59 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 17 Jan 2018 12:57:59 +0000
Subject: [issue19417] Bdb: add a unittest file (test.test_bdb)
In-Reply-To: <1382896308.72.0.45441786626.issue19417@psf.upfronthosting.co.za>
Message-ID: <1516193879.25.0.467229070634.issue19417@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

PR 5217 adds the test.test_bdb module and provides a framework for adding more tests to the bdb module.

Added versions 3.6 and 2.7. This is consistent with what was done in issues #21916 and #25616 for example, but the main reason is that most bdb bug fixes need to be backported to the maintenance and 2.7 versions and should use the same test case whenever possible.

----------
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:11:08 2018
From: report at bugs.python.org (=?utf-8?b?SmVybmVqIFNpbW9uxI1pxI0=?=)
Date: Wed, 17 Jan 2018 13:11:08 +0000
Subject: [issue32580] Fallback to dev_urandom doesn't work when py_getrandom
 returns -1
Message-ID: <1516194668.11.0.467229070634.issue32580@psf.upfronthosting.co.za>


New submission from Jernej Simon?i? <jernej+s-python at eternallybored.org>:

I'm playing with Gentoo in LXC running on ARM-based QNAP NAS, and when trying to compile Python 3.5.4, the build failed with "Fatal Python error: failed to get random numbers to initialize Python" (full details at https://forums.gentoo.org/viewtopic-p-8172124.html ).

glibc in the environment is 2.25 (supports getrandom), while kernel is 3.10 (doesn't support getrandom).

Looking at random.c, pyurandom returns -1 instead of falling back to dev_urandom when py_getrandom returns -1, so the attached fix is simple.

----------
components: Build
files: random_fallback.patch
keywords: patch
messages: 310158
nosy: jernejs
priority: normal
severity: normal
status: open
title: Fallback to dev_urandom doesn't work when py_getrandom returns -1
versions: Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47389/random_fallback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32580>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:16:45 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jan 2018 13:16:45 +0000
Subject: [issue32577] Pip creates entry point commands in the wrong place when
 invoked in a venv nested in a virtualenv
In-Reply-To: <1516169669.76.0.467229070634.issue32577@psf.upfronthosting.co.za>
Message-ID: <1516195005.71.0.467229070634.issue32577@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is sounds like a variation on issue 30811.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32577>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:36:07 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 13:36:07 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516196167.31.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

> FWIW, we've encountered a number of situations in the past when something that improved the timings on one compiler would make timings worse on another compiler.  There was also variance between timings on 32-bit builds versus 64-bit builds.

I've verified that both clang and gcc generate similar assembly (memcpy is not inlined and the loop is not vectorized) 32-bit mode. I'd wager that the improvement with vectorization (in memmove) would be even more pronounced on 32-bit systems, given that pointers are half the size and cache lines are still 64 bytes wide.

> It's 1.08x faster (-7.8%). It's small for a microbenchmark, usually an optimization should make a *microbenchmark* at least 10% faster.

That's true if we assume lists to have 100 or lesser elements. On the other hand, on the pyperformance comparison I'd posted yesterday[1], there seems to be an average improvement of 1.27x  on the first seven benchmarks, and the slowest slowdown is only 1.03x. Albeit, the improvement cannot be better than by a constant factor with the vectorized loop in memmove.

> Using memmove() for large copy is a good idea. The main question is the "if (n <= INS1_MEMMOVE_THRESHOLD)" test. Is it slower if we always call memmove()?

The overhead of calling memmove makes it slower for small lists. That's how I arrived at this patch in the first place. I tried replacing the loop with a memmove() and it was slower on pyperformance and it was faster with switching to memmove() after a threshold.

> Previously, Python had a Py_MEMCPY() macro which also had such threshold. Basically, it's a workaround for compiler performance issues:

That's very interesting! I think it boils down to the pointer aliasing problem. The pointers in memcpy()'s signature have the `restrict` qualifier, which gives the compiler more leeway to optimize calls to memcpy, while the compiler has to be more conservative with memmove(). I wonder if it's worth trying out a Py_MEMMOVE() :)


[1]: https://gist.github.com/jeethu/d6e4045f7932136548a806380eddd030

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:37:37 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jan 2018 13:37:37 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1516196167.31.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <c7c4e16c-55a4-0679-e98b-2c3e655c7ca4@free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le 17/01/2018 ? 14:36, Jeethu Rao a ?crit?:
> 
> On the other hand, on the pyperformance comparison I'd posted yesterday[1], there seems to be an average improvement of 1.27x  on the first seven benchmarks, and the slowest slowdown is only 1.03x.

I still think those numbers are misleading or downright bogus.  There is
no existing proof that list.insert() is a critical path in those benchmarks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:40:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 13:40:05 +0000
Subject: [issue32580] Fallback to dev_urandom doesn't work when py_getrandom
 returns -1
In-Reply-To: <1516194668.11.0.467229070634.issue32580@psf.upfronthosting.co.za>
Message-ID: <1516196405.16.0.467229070634.issue32580@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I'm playing with Gentoo in LXC running on ARM-based QNAP NAS, and when trying to compile Python 3.5.4, the build failed with "Fatal Python error: failed to get random numbers to initialize Python" (full details at https://forums.gentoo.org/viewtopic-p-8172124.html ).

I'm surprised. Python 3.5.4 does contain my latest fix: commit 035ba5da3e53e45c712b39fe1f6fb743e697c032 (bpo-29157).

> Looking at random.c, pyurandom returns -1 instead of falling back to dev_urandom when py_getrandom returns -1, so the attached fix is simple.

Ignoring failures is not a good idea.

What is the result of the getrandom() function?

> glibc in the environment is 2.25 (supports getrandom), while kernel is 3.10 (doesn't support getrandom).

I expect n < 0 with errno = ENOSYS: py_getrandom() should return 0 in this case, not -1.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32580>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:43:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 13:43:26 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516196606.18.0.467229070634.issue32534@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I still think those numbers are misleading or downright bogus.  There is no existing proof that list.insert() is a critical path in those benchmarks.

Can someone check if these bencmarks really use list.insert() in hot code? If yes, why? :-) The cost of list.insert() is known, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:55:20 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jan 2018 13:55:20 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516197320.73.0.467229070634.issue30693@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Given the reproducible builds angle, I'd say this was worth doing.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:59:56 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 17 Jan 2018 13:59:56 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1516197596.39.0.467229070634.issue11192@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

I have tried jumping into the pdp using

but do not come much further in understanding how the expectations expressed in these comments are satisfied:

 +2153  # Tests for the sendmsg()/recvmsg() interface.  Where possible, the
 +2154  # same test code is used with different families and types of socket
 +2155  # (e.g. stream, datagram), and tests using recvmsg() are repeated
 +2156  # using recvmsg_into().
 +2157  #
 +2158  # The generic test classes such as SendmsgTests and
 +2159  # RecvmsgGenericTests inherit from SendrecvmsgBase and expect to be
 +2160  # supplied with sockets cli_sock and serv_sock representing the
 +2161  # client's and the server's end of the connection respectively, and
 +2162  # attributes cli_addr and serv_addr holding their (numeric where
 +2163  # appropriate) addresses.
 +2164  #


++ Details ++
14 tests failed again:
    test_asyncio test_cmath test_ctypes test_datetime test_distutils
    test_httplib test_httpservers test_os test_posix test_socket
    test_ssl test_subprocess test_time test_utf8_mode


()
-> super().setUp()
(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2187)setUp()
-> def setUp(self):
(Pdb) l
2182
2183        # Time in seconds to wait before considering a test failed, or
2184        # None for no timeout.  Not all tests actually set a timeout.
2185        fail_timeout = 3.0
2186
2187 ->     def setUp(self):
2188            self.misc_event = threading.Event()
2189            super().setUp()
2190
2191        def sendToServer(self, msg):
2192            # Send msg to the server.
(Pdb) s
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2188)setUp()
-> self.misc_event = threading.Event()
(Pdb) self
<test.test_socket.RFC3542AncillaryTest testMethod=testCmsgTruncNoBufSize>
(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(499)__init__()
-> def __init__(self):
(Pdb) self
<threading.Event object at 0x3035f3d0>
(Pdb) dir(self)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_reset_internal_locks', 'clear', 'isSet', 'is_set', 'set', 'wait']
(Pdb) l
494
495         """
496
497         # After Tim Peters' event class (without is_posted())
498
499  ->     def __init__(self):
500             self._cond = Condition(Lock())
501             self._flag = False
502
503         def _reset_internal_locks(self):
504             # private!  called by Thread._reset_internal_locks by _after_fork()
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(500)__init__()
-> self._cond = Condition(Lock())
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(501)__init__()
-> self._flag = False
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(501)__init__()->None
-> self._flag = False
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2189)setUp()
-> super().setUp()
(Pdb) l
2184        # None for no timeout.  Not all tests actually set a timeout.
2185        fail_timeout = 3.0
2186
2187        def setUp(self):
2188            self.misc_event = threading.Event()
2189 ->         super().setUp()
2190
2191        def sendToServer(self, msg):
2192            # Send msg to the server.
2193            return self.cli_sock.send(msg)
2194
(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(453)setUp()
-> def setUp(self):
(Pdb) l
448             called after tearDown on test failure or success.
449
450             Cleanup items are called even if setUp fails (unlike tearDown)."""
451             self._cleanups.append((function, args, kwargs))
452
453  ->     def setUp(self):
454             "Hook method for setting up the test fixture before exercising it."
455             pass
456
457         def tearDown(self):
458             "Hook method for deconstructing the test fixture after testing it."
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(455)setUp()
-> pass
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(455)setUp()->None
-> pass
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2189)setUp()->None
-> super().setUp()
(Pdb) l
2184        # None for no timeout.  Not all tests actually set a timeout.
2185        fail_timeout = 3.0
2186
2187        def setUp(self):
2188            self.misc_event = threading.Event()
2189 ->         super().setUp()
2190
2191        def sendToServer(self, msg):
2192            # Send msg to the server.
2193            return self.cli_sock.send(msg)
2194
(Pdb) s
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2375)setUp()
-> print('stop here') #@@@
(Pdb) l
2370
2371        def setUp(self):
2372            import pdb #@@@
2373            pdb.set_trace() #@@@
2374            super().setUp()
2375 ->         print('stop here') #@@@
2376            print(self)
2377            super().setUp()
2378            self.serv_sock.settimeout(self.fail_timeout)
2379
2380
(Pdb) dir(self)
['__call__', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_addExpectedFailure', '_addSkip', '_addUnexpectedSuccess', '_baseAssertEqual', '_classSetupFailed', '_cleanup_lock', '_cleanups', '_deprecate', '_diffThreshold', '_feedErrorsToResult', '_formatMessage', '_getAssertEqualityFunc', '_outcome', '_subtest', '_testCmsgTruncNoBufSize', '_testMethodDoc', '_testMethodName', '_testOddCmsgSize', '_testRecvHopLimit', '_testRecvHopLimitCMSG_SPACE', '_testRecvTrafficClassAndHopLimit', '_testRecvTrafficClassAndHopLimitCMSG_SPACE', '_testSecomdCmsgTruncInData', '_testSecondCmsgTrunc0', '_testSecondCmsgTrunc1', '_testSecondCmsgTrunc2Int', '_testSecondCmsgTruncLen0Minus1', '_testSetHopLimit', '_testSetTrafficClassAndHopLimit', '_testSingleCmsgTrunc0', '_testSingleCmsgTrunc1', '_testSingleCmsgTrunc2Int', '_testSingleCmsgTruncInData', '_testSingleCmsgTruncLen0Minus1', '_truncateMessage', '_type_equality_funcs', 'addCleanup', 'addTypeEqualityFunc', 'ancillaryMapping', 'assertAlmostEqual', 'assertAlmostEquals', 'assertCountEqual', 'assertDictContainsSubset', 'assertDictEqual', 'assertEqual', 'assertEquals', 'assertFalse', 'assertGreater', 'assertGreaterEqual', 'assertIn', 'assertIs', 'assertIsInstance', 'assertIsNone', 'assertIsNot', 'assertIsNotNone', 'assertLess', 'assertLessEqual', 'assertListEqual', 'assertLogs', 'assertMultiLineEqual', 'assertNotAlmostEqual', 'assertNotAlmostEquals', 'assertNotEqual', 'assertNotEquals', 'assertNotIn', 'assertNotIsInstance', 'assertNotRegex', 'assertNotRegexpMatches', 'assertRaises', 'assertRaisesRegex', 'assertRaisesRegexp', 'assertRegex', 'assertRegexpMatches', 'assertSequenceEqual', 'assertSetEqual', 'assertTrue', 'assertTupleEqual', 'assertWarns', 'assertWarnsRegex', 'assert_', 'checkFlags', 'checkHopLimit', 'checkHopLimitTruncatedHeader', 'checkRecvmsgAddress', 'checkTrafficClassAndHopLimit', 'checkTruncatedSecondHeader', 'countTestCases', 'debug', 'defaultTestResult', 'doCleanups', 'doRecvmsg', 'fail', 'failIf', 'failIfAlmostEqual', 'failIfEqual', 'failUnless', 'failUnlessAlmostEqual', 'failUnlessEqual', 'failUnlessRaises', 'fail_timeout', 'failureException', 'hop_limit', 'id', 'longMessage', 'maxDiff', 'misc_event', 'msg_flags_common_set', 'msg_flags_common_unset', 'msg_flags_eor_indicator', 'msg_flags_non_eor_indicator', 'name', 'registerRecvmsgResult', 'run', 'sendToServer', 'sendmsgToServer', 'sendmsg_to_server_defaults', 'setUp', 'setUpClass', 'shortDescription', 'skipTest', 'subTest', 'tearDown', 'tearDownClass', 'testCmsgTruncNoBufSize', 'testOddCmsgSize', 'testRecvHopLimit', 'testRecvHopLimitCMSG_SPACE', 'testRecvTrafficClassAndHopLimit', 'testRecvTrafficClassAndHopLimitCMSG_SPACE', 'testSecomdCmsgTruncInData', 'testSecondCmsgTrunc0', 'testSecondCmsgTrunc1', 'testSecondCmsgTrunc2Int', 'testSecondCmsgTruncLen0Minus1', 'testSetHopLimit', 'testSetTrafficClassAndHopLimit', 'testSingleCmsgTrunc0', 'testSingleCmsgTrunc1', 'testSingleCmsgTrunc2Int', 'testSingleCmsgTruncInData', 'testSingleCmsgTruncLen0Minus1', 'traffic_class']
(Pdb) self
<test.test_socket.RFC3542AncillaryTest testMethod=testCmsgTruncNoBufSize>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:07:20 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 17 Jan 2018 14:07:20 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516198040.8.0.467229070634.issue30693@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

+1 from me

In my opinion it's both a good idea to not sort the result of glob.glob() and make the order of tar and zip module content ordered. The glob module is low level and it makes sense to expose the file system sort order.

On the other hand tar and zip modules are on a higher level. Without sorting it's impossible to create reproducible archives. The performance impact is irrelevant. I/O and compression dominant performance.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:08:30 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 17 Jan 2018 14:08:30 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516198110.81.0.467229070634.issue30693@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

PS: I'm -0 to backport the change to 3.6 and 2.7. 3.5 is in security fix mode and therefore completely out of scope.

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:11:48 2018
From: report at bugs.python.org (jiangjinhu)
Date: Wed, 17 Jan 2018 14:11:48 +0000
Subject: [issue32581] A bug of the write funtion of ConfigParser.py
Message-ID: <1516198308.88.0.467229070634.issue32581@psf.upfronthosting.co.za>


New submission from jiangjinhu <jiangjinhu000 at 126.com>:

By the write funtion of ConfigParser.py,the partial content of the configue will change.

----------
components: Library (Lib)
messages: 310168
nosy: jiangjinhu666
priority: normal
severity: normal
status: open
title: A bug of the write funtion of ConfigParser.py
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32581>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:11:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 14:11:55 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516198315.22.0.467229070634.issue30693@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Since we currently don't warranty *anything* about ordering, I like the idea of *fixing* Python 2.7 and 3.6 as well. +1 for fix it in 2.7, 3.6 and master.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:14:01 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jan 2018 14:14:01 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516198441.23.0.467229070634.issue30693@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I was just going to ask about that.  I guess I'm -0 on the backport as well.  The other reproducible build stuff is only going to land in 3.7. However, this is in a more general category than the pyc stuff, so I can see the argument for backporting it.

----------
nosy:  -vstinner
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:14:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 14:14:14 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516198454.1.0.467229070634.issue30693@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The only warranty in that TarFile.getmembers(), TarFile.getnames() and ZipFile.infolist() returns members/names "in the same order as the members in the archive".

Currently, there is no warranty when packing, only on unpack.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:16:31 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jan 2018 14:16:31 +0000
Subject: [issue32581] A bug of the write funtion of ConfigParser.py
In-Reply-To: <1516198308.88.0.467229070634.issue32581@psf.upfronthosting.co.za>
Message-ID: <1516198591.72.0.467229070634.issue32581@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please provide a way to reproduce the problem you are observing.  There is insufficient information here so far to understand the problem.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32581>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:20:23 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 17 Jan 2018 14:20:23 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516198823.84.0.467229070634.issue30693@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The patch changes behavior. It's fine for 3.7 but not for 3.6/2.7. Somebody may depend on filesystem order.

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:21:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 14:21:55 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516198915.84.0.467229070634.issue32248@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 3a0cf931796b9ad1b4833ab89c79d284b4253c91 by Victor Stinner in branch 'master':
bpo-32248: Fix test_importlib.test_open() (#5213)
https://github.com/python/cpython/commit/3a0cf931796b9ad1b4833ab89c79d284b4253c91


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:26:47 2018
From: report at bugs.python.org (jiangjinhu)
Date: Wed, 17 Jan 2018 14:26:47 +0000
Subject: [issue32581] A bug of the write funtion of ConfigParser.py
In-Reply-To: <1516198308.88.0.467229070634.issue32581@psf.upfronthosting.co.za>
Message-ID: <1516199207.36.0.467229070634.issue32581@psf.upfronthosting.co.za>


jiangjinhu <jiangjinhu000 at 126.com> added the comment:

def write(self, fp):
        """Write an .ini-format representation of the configuration state."""
        if self._defaults:
            fp.write("[%s]\n" % DEFAULTSECT)
            for (key, value) in self._defaults.items():
                fp.write("%s = %s\n" % (key, str(value).replace('\n', '\n\t')))
            fp.write("\n")
        for section in self._sections:
            fp.write("[%s]\n" % section)
            for (key, value) in self._sections[section].items():
                if key == "__name__":
                    continue
                if (value is not None) or (self._optcre == self.OPTCRE):
                    if value == "":    #
                        value = "\"\""  #
                        key = " = ".join((key, str(value).replace('\n', '\n\t')))#
                    else:                                         #
                        key = " = ".join((key, str(value).replace('\n', '\n\t')))

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

                fp.write("%s\n" % (key))
            fp.write("\n")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32581>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:27:42 2018
From: report at bugs.python.org (jiangjinhu)
Date: Wed, 17 Jan 2018 14:27:42 +0000
Subject: [issue32581] A bug of the write funtion of ConfigParser.py
In-Reply-To: <1516198308.88.0.467229070634.issue32581@psf.upfronthosting.co.za>
Message-ID: <1516199262.4.0.467229070634.issue32581@psf.upfronthosting.co.za>


jiangjinhu <jiangjinhu000 at 126.com> added the comment:

The configure file "test.ini":

[section_a]
addr = "127.0.0.1"
password = ""

Change the value of addr by the "test.py":

import ConfigParser

tmpfile = "test.ini"
conf = ConfigParser.ConfigParser()
conf.read(tmpfile)
conf.set("section_a", "addr", "\"127.0.0.2\"")
cfgfile = open(tmpfile, 'w')
conf.write(cfgfile) 

After change the value of addr to 127.0.0.2,the test.ini will be:

[section_a]
addr = "127.0.0.2"
password = 

The "" of the password lost!

And one method which will fix this bug of the write function of the ConfigParder.py:

    def write(self, fp):
        """Write an .ini-format representation of the configuration state."""
        if self._defaults:
            fp.write("[%s]\n" % DEFAULTSECT)
            for (key, value) in self._defaults.items():
                fp.write("%s = %s\n" % (key, str(value).replace('\n', '\n\t')))
            fp.write("\n")
        for section in self._sections:
            fp.write("[%s]\n" % section)
            for (key, value) in self._sections[section].items():
                if key == "__name__":
                    continue
                if (value is not None) or (self._optcre == self.OPTCRE):
                    if value == "":    #
                        value = "\"\""  #
                        key = " = ".join((key, str(value).replace('\n', '\n\t')))#
                    else:                                         #
                        key = " = ".join((key, str(value).replace('\n', '\n\t')))

    
                fp.write("%s\n" % (key))
            fp.write("\n") 


Please check it.
Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32581>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:28:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 14:28:41 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516199321.84.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

test_readline pass again on all buildbots, especially on FreeBSD 3.6 and 3.x buildbots.

There are no more known issues, the implementation of the PEP 540 (UTF-8 Mode) is now complete!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:32:06 2018
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Wed, 17 Jan 2018 14:32:06 +0000
Subject: [issue32582] chr raises OverflowError
Message-ID: <1516199526.4.0.467229070634.issue32582@psf.upfronthosting.co.za>


New submission from Uwe Kleine-K?nig <uwe+python at kleine-koenig.org>:

Hello,

the description for chr (from https://docs.python.org/3/library/functions.html#chr) reads as:

        Return the string representing a character whose Unicode code
        point is the integer i. [...] The valid range for the argument
        is from 0 through 1,114,111 (0x10FFFF in base 16). ValueError
        will be raised if i is outside that range.

If however a value > 0x7fffffff (or < -0x80000000) is provided, the function raises an Overflow error:

        $ python3 -c 'print(chr(0x80000000))'
        Traceback (most recent call last):
          File "<string>", line 1, in <module>
        OverflowError: signed integer is greater than maximum

This is either a documentation problem or (more like) an implementation issue. I attached a patch that fixes the issue for me. (I'm not sure however if I should call PyErr_Clear() before raising ValueError.)

----------
components: Interpreter Core
files: chr-OverflowError.patch
keywords: patch
messages: 310178
nosy: ukl
priority: normal
severity: normal
status: open
title: chr raises OverflowError
versions: Python 3.6
Added file: https://bugs.python.org/file47390/chr-OverflowError.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32582>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:34:04 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jan 2018 14:34:04 +0000
Subject: [issue32581] A bug of the write funtion of ConfigParser.py
In-Reply-To: <1516198308.88.0.467229070634.issue32581@psf.upfronthosting.co.za>
Message-ID: <1516199644.02.0.467229070634.issue32581@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'll defer to Lukasz, but I don't believe this is a bug.  An empty value and a value of "" are equivalent in config.ini syntax, as far as I know.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32581>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:43:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 14:43:14 +0000
Subject: [issue32582] chr raises OverflowError
In-Reply-To: <1516199526.4.0.467229070634.issue32582@psf.upfronthosting.co.za>
Message-ID: <1516200194.24.0.467229070634.issue32582@psf.upfronthosting.co.za>


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


----------
pull_requests: +5071
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32582>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:44:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 14:44:42 +0000
Subject: [issue32582] chr raises OverflowError
In-Reply-To: <1516199526.4.0.467229070634.issue32582@psf.upfronthosting.co.za>
Message-ID: <1516200282.28.0.467229070634.issue32582@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

It's more an implementation issue.

I proposed PR 5218 to also raise a ValueError on overflow.

I propose to only change Python 3.7, and only Python 2.7 and 3.6 unchanged.

----------
nosy: +vstinner
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32582>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:53:40 2018
From: report at bugs.python.org (jiangjinhu)
Date: Wed, 17 Jan 2018 14:53:40 +0000
Subject: [issue32581] A bug of the write funtion of ConfigParser.py
In-Reply-To: <1516198308.88.0.467229070634.issue32581@psf.upfronthosting.co.za>
Message-ID: <1516200820.8.0.467229070634.issue32581@psf.upfronthosting.co.za>


jiangjinhu <jiangjinhu000 at 126.com> added the comment:

But accidentally,with the "password = "" " in the configure files ,which are called by my services, the service will start successfully,and with "password =   ",the services can not.On the other hand ,I just set the option "addr = "127.0.0.1"",why the option "password = "" " will change.
Just add this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32581>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:54:33 2018
From: report at bugs.python.org (Kiran)
Date: Wed, 17 Jan 2018 14:54:33 +0000
Subject: [issue32566] Not able to open Python IDLE
In-Reply-To: <1516095028.12.0.467229070634.issue32566@psf.upfronthosting.co.za>
Message-ID: <1516200873.55.0.467229070634.issue32566@psf.upfronthosting.co.za>


Kiran <kiranreddy.p.s at gmail.com> added the comment:

Hi,

Can someone help me to resolve the issue or let me know the cause of this error.

Thanks in advance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32566>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:05:12 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 17 Jan 2018 15:05:12 +0000
Subject: [issue32577] Pip creates entry point commands in the wrong place when
 invoked in a venv nested in a virtualenv
In-Reply-To: <1516169669.76.0.467229070634.issue32577@psf.upfronthosting.co.za>
Message-ID: <1516201512.05.0.467229070634.issue32577@psf.upfronthosting.co.za>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

Yup, seems so. Closing as duplicate then.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32577>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:07:24 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 15:07:24 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516201644.03.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

> > I still think those numbers are misleading or downright bogus.  There is no existing proof that list.insert() is a critical path in those benchmarks.

> Can someone check if these bencmarks really use list.insert() in hot code? If yes, why? :-) The cost of list.insert() is known, no?

Sure! https://gist.github.com/jeethu/000a2d3ecd9033c0ef51331f062ac294

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:12:30 2018
From: report at bugs.python.org (Alexander Sibiryakov)
Date: Wed, 17 Jan 2018 15:12:30 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
Message-ID: <1516201950.63.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Alexander Sibiryakov <sixty-one at yandex.ru>:


----------
files: decode_crash.py
nosy: sibiryakov
priority: normal
severity: normal
status: open
title: Crash during decoding using UTF-16/32 and custom error handler
type: crash
versions: Python 3.5, Python 3.7
Added file: https://bugs.python.org/file47391/decode_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:13:32 2018
From: report at bugs.python.org (Alexander Sibiryakov)
Date: Wed, 17 Jan 2018 15:13:32 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
Message-ID: <1516202012.78.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Alexander Sibiryakov <sixty-one at yandex.ru>:


Added file: https://bugs.python.org/file47392/test_string.bin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:18:06 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 17 Jan 2018 15:18:06 +0000
Subject: [issue30811] A venv created and activated from within a virtualenv
 uses the outer virtualenv's site-packages rather than its own.
In-Reply-To: <1498813368.34.0.349011380575.issue30811@psf.upfronthosting.co.za>
Message-ID: <1516202286.79.0.467229070634.issue30811@psf.upfronthosting.co.za>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

Would it be possible for venv to do this automatically? Instead of using sys.executable, use

    import sysconfig
    dirname, exename = sysconfig.get_config_vars('BINDIR', 'BUILDPYTHON')

to populate values in the context?

----------
nosy: +uranusjr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30811>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:21:24 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 17 Jan 2018 15:21:24 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516202484.07.0.467229070634.issue32493@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

Actually, the libc/libuuid function called should be setting the version/variant values as well.

So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_generate() function is wrong (if that is what it is using - was it/can it also use the uuid_generate* routines?

FYI:

I notice the AIX include file does not actually define the bits for RFC_4122, etc.., but the include file comments does show that the implementation is taking them into account.

/** The strlen() of a UUID string (does not include terminating null) */
#define UUID_STRLEN 36
/**
 * Constant value indicating an as-yet undetermined UUID for a thing.  Spells \c
 * "\0\0UUID\x10_\x80UNKNOWN" in ASCII.  Zeroes at the top make it very unlikely
 * to collide with a uuid_create()d value, which puts a timestamp in that spot.
 * The \c "\x10" and \c "\x80" are reserved/version/mask bits that make this
 * conform to the format expected by the uuid.h API.
 */
#define UUID_UNKNOWN (uuid_t){0x00005555, 0x4944, 0x105F, 0x80, 0x55, {0x4E, 0x4B, 0x4E, 0x4F, 0x57, 0x4E}}
#define UUID_UNKNOWN_STR       "00005555-4944-105f-8055-4e4b4e4f574e"

I wrote a simple program to examine uuid for myself.

Maybe - if you ran a loop (looking at uuid1().variant and uuid1().version you could see if there is an incorrect version showing up. Rather than python - that would seem to be a library function error.

My very simple program:

cat -n ../x4.py
     1  import _uuid
     2  import uuid
     3  _generate_time_safe = _uuid.generate_time_safe
     4  _has_uuid_generate_time_safe = _uuid.has_uuid_generate_time_safe
     5  uuid_time, _ = _generate_time_safe()
     6
     7  uu1a = uuid.UUID(bytes=uuid_time)
     8  uu1b = uuid.uuid1()
     9  uu4 = uuid.uuid4()
    10
    11  print("a)uuid1 = %x" % uu1a.int)
    12  print("b)uuid1 = %x" % uu1b.int)
    13  print("")
    14  print("a uuid1 = ",uu1a.fields, uu1a.version, uu1a.variant)
    15  print("b uuid1 = ",uu1b.fields, uu1b.version, uu1b.variant)
    16  uu1c = uuid.uuid1()
    17  print("c uuid1 = ",uu1c.fields, uu1c.version, uu1c.variant)
    18  print("")
    19  print("  uuid4 = %x" % uu4.int)
    20  print("  uuid4 = ",uu4.fields, uu4.version, uu4.variant)
    21  print("")
    22  uu4 = uuid.uuid4()
    23  print("  uuid4 = %x" % uu4.int)
    24  print("  uuid4 = ",uu4.fields, uu4.version, uu4.variant)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:24:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 15:24:52 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516202692.59.0.467229070634.issue32534@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Sure! https://gist.github.com/jeethu/000a2d3ecd9033c0ef51331f062ac294

I don't understand how to read this output.

"54640 ins1 called 40050 times"

What is 54640?

I'm interested to know which benchmarks call list.insert() 40k times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:27:50 2018
From: report at bugs.python.org (Alexander Sibiryakov)
Date: Wed, 17 Jan 2018 15:27:50 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
Message-ID: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>


New submission from Alexander Sibiryakov <sixty-one at yandex.ru>:

The CPython interpreter gets SIGSEGV or SIGABRT during the run. The script attempts to decode binary file using UTF-16-LE encoding and custom error handler. The error handler is poorly built, and doesn't respect the unicode standard with wrong calculation of the new position for decoder to continue. This somehow interfere with internal C code doing memory allocation. The result is invalid writes outside of allocated block.

Here is how it looks like with Python 3.7.0a4+ (heads/master:44a70e9, Jan 17 2018, 12:18:45) run under Valgrind 3.11.0. Please see the full Valgrind output in attached valgrind.log.

==24836== Invalid write of size 4
==24836==    at 0x4C6B17: ucs4lib_utf16_decode (codecs.h:540)
==24836==    by 0x4C6B17: PyUnicode_DecodeUTF16Stateful (unicodeobject.c:5600)
==24836==    by 0x55AAD3: _codecs_utf_16_le_decode_impl (_codecsmodule.c:363)
==24836==    by 0x55AB6C: _codecs_utf_16_le_decode (_codecsmodule.c.h:371)
==24836==    by 0x4315D6: _PyMethodDef_RawFastCallKeywords (call.c:651)
==24836==    by 0x431840: _PyCFunction_FastCallKeywords (call.c:730)
==24836==    by 0x4ED159: call_function (ceval.c:4580)
==24836==    by 0x4ED159: _PyEval_EvalFrameDefault (ceval.c:3134)
==24836==    by 0x4E302D: PyEval_EvalFrameEx (ceval.c:545)
==24836==    by 0x4E3A42: _PyEval_EvalCodeWithName (ceval.c:3971)
==24836==    by 0x430EDD: _PyFunction_FastCallDict (call.c:376)
==24836==    by 0x4336B0: PyObject_Call (call.c:226)
==24836==    by 0x433839: PyEval_CallObjectWithKeywords (call.c:826)
==24836==    by 0x4FEAA6: _PyCodec_DecodeInternal (codecs.c:471)
==24836==  Address 0x6cf4bf8 is 0 bytes after a block of size 339,112 alloc'd
==24836==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24836==    by 0x467635: _PyMem_RawMalloc (obmalloc.c:75)
==24836==    by 0x467B7D: _PyMem_DebugRawAlloc (obmalloc.c:2033)
==24836==    by 0x467C1F: _PyMem_DebugRawMalloc (obmalloc.c:2062)
==24836==    by 0x467C40: _PyMem_DebugMalloc (obmalloc.c:2202)
==24836==    by 0x468BFF: PyObject_Malloc (obmalloc.c:616)
==24836==    by 0x493902: PyUnicode_New (unicodeobject.c:1293)
==24836==    by 0x4BEA4F: _PyUnicodeWriter_PrepareInternal (unicodeobject.c:13456)
==24836==    by 0x4C6D39: _PyUnicodeWriter_WriteCharInline (unicodeobject.c:13494)
==24836==    by 0x4C6D39: PyUnicode_DecodeUTF16Stateful (unicodeobject.c:5637)
==24836==    by 0x55AAD3: _codecs_utf_16_le_decode_impl (_codecsmodule.c:363)
==24836==    by 0x55AB6C: _codecs_utf_16_le_decode (_codecsmodule.c.h:371)
==24836==    by 0x4315D6: _PyMethodDef_RawFastCallKeywords (call.c:651)

----------
Added file: https://bugs.python.org/file47393/valgrind.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:29:13 2018
From: report at bugs.python.org (Antony Lee)
Date: Wed, 17 Jan 2018 15:29:13 +0000
Subject: [issue30811] A venv created and activated from within a virtualenv
 uses the outer virtualenv's site-packages rather than its own.
In-Reply-To: <1498813368.34.0.349011380575.issue30811@psf.upfronthosting.co.za>
Message-ID: <1516202953.61.0.467229070634.issue30811@psf.upfronthosting.co.za>


Change by Antony Lee <anntzer.lee at gmail.com>:


----------
nosy:  -Antony.Lee

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30811>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:30:00 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 15:30:00 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516203000.04.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

> What is 54640?

That's the pid of the process.

> I'm interested to know which benchmarks call list.insert() 40k times.

The django_template benchmark.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:32:24 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 17 Jan 2018 15:32:24 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516203144.39.0.467229070634.issue32493@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

typo here:

So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_create() function is wrong (if that is what it is using - was it/can it also use the uuid_generate* routines?

i.e., does AMD FreeBSD use uuid_create() or uuid_generate() - or can it use both?

Could someone with AMD try:
Modules/_uuidmodule.c

 +12  static PyObject *
   +13  py_uuid_generate_time_safe(void)
   +14  {
   +15      uuid_t uuid;
   +16  #ifdef HAVE_UUID_GENERATE_TIME_SAFE
   +17      int res;
   +18
   +19      res = uuid_generate_time_safe(uuid);
   +20      return Py_BuildValue("y#i", (const char *) uuid, sizeof(uuid), res);
   +21  #elif HAVE_UUID_GENERATE_TIME
   +22      uuid_generate_time(uuid);
   +23      return Py_BuildValue("y#O", (const char *) uuid, sizeof(uuid), Py_None);
   +24  #elif HAVE_UUID_CREATE
   +25      uint32_t status;
   +26      uuid_create(&uuid, &status);
   +27      return Py_BuildValue("y#i", (const char *) &uuid, sizeof(uuid), (int) status);
   +28  #else
   +29  #error "no uuid library function available"
   +30  #endif
   +31  }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:35:04 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 15:35:04 +0000
Subject: [issue32584] Uninitialized free_extra in code_dealloc
Message-ID: <1516203304.77.0.467229070634.issue32584@psf.upfronthosting.co.za>


New submission from Jeethu Rao <jeethu at jeethurao.com>:

In one of patches I'm building, (yet another attempt at caching LOAD_GLOBALS)[1], I'm using the private APIs from PEP 523 to store an array with every code object. I'm calling _PyEval_RequestCodeExtraIndex with PyMem_Free for the freefunc argument. While running  the cpython testsuite, I found that test_embed case crashes with a segfault. The gdb backtrace[2] seems to indicate that PyInterpreterState::co_extra_freefuncs is uninitialized, while it should be a pointer to the PyMem_Free function. 

One way to work around this is to set the array as a member on the PyCodeObject struct and use it directly. And I've verified that it works. Am I using the PEP 523 private api correctly? Also, on Linux, this consistently crashes while on OSX, it occasionally doesn't crash which makes me wonder if it's some kind of a race condition involving Sub-interpreters. The attached gist[2] has steps for repro.

[1]: https://github.com/python/cpython/compare/master...jeethu:py3.7_load_global_cache
[2]: https://gist.github.com/jeethu/6d92185ca97dd692e7fadcd105e0ef70

----------
components: Interpreter Core
messages: 310191
nosy: jeethu
priority: normal
severity: normal
status: open
title: Uninitialized free_extra in code_dealloc
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32584>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:36:45 2018
From: report at bugs.python.org (David CARLIER)
Date: Wed, 17 Jan 2018 15:36:45 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516203405.57.0.467229070634.issue32493@psf.upfronthosting.co.za>


David CARLIER <devnexen at gmail.com> added the comment:

uuid_create only I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:39:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 15:39:41 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516203581.83.0.467229070634.issue32534@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

In https://gist.github.com/jeethu/dc0811d415dd6d1a1621761e43842f88 I read:

| django_template | 160 ms | 129 ms | 1.24x faster | Significant (t=15.05) |

So on this benchmark, the optimization seems significant. But in the same paste, I see other benchmarks 1.2x faster whereas they don't abuse list.insert(), and maybe don't use list.insert() at all.

Maybe Django template engine should be fixed to use deque instead ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:41:20 2018
From: report at bugs.python.org (David CARLIER)
Date: Wed, 17 Jan 2018 15:41:20 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516203680.59.0.467229070634.issue32493@psf.upfronthosting.co.za>


David CARLIER <devnexen at gmail.com> added the comment:

Gives same outcome but maybe someone else can confir,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:50:49 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 15:50:49 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516204249.41.0.467229070634.issue32534@psf.upfronthosting.co.za>


Jeethu Rao <jeethu at jeethurao.com> added the comment:

It's also interesting that in https://gist.github.com/pitrou/29eb7592fa1eae2be390f3bfa3db0a3a :

| django_template         | 307 ms    | 312 ms                   | 1.02x slower | Not significant        |

It seems to be slower and the benchmarks before it (2to3, chameleon, chaos, crypto_pyaes, deltablue) which we now know barely use list.insert are slightly faster :)

?\_(?)_/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Wed Jan 17 11:45:37 2018
From: report at bugs.python.org (=?utf-8?b?SmVybmVqIFNpbW9uxI1pxI0=?=)
Date: Wed, 17 Jan 2018 16:45:37 +0000
Subject: [issue32580] Fallback to dev_urandom doesn't work when py_getrandom
 returns -1
In-Reply-To: <1516194668.11.0.467229070634.issue32580@psf.upfronthosting.co.za>
Message-ID: <1516207537.34.0.467229070634.issue32580@psf.upfronthosting.co.za>


Jernej Simon?i? <jernej+s-python at eternallybored.org> added the comment:

OK, looks like Qnap is doing something weird there - calls to getrandom result in EFAULT, which results in . PHP had the same problem: https://bugs.php.net/bug.php?id=75409

Changing "if (errno == ENOSYS || errno == EPERM) {" to "if (errno == ENOSYS || errno == EPERM || errno == EFAULT) {" also works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32580>
_______________________________________

From report at bugs.python.org  Wed Jan 17 12:03:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 17:03:55 +0000
Subject: [issue32580] Fallback to dev_urandom doesn't work when py_getrandom
 returns -1
In-Reply-To: <1516194668.11.0.467229070634.issue32580@psf.upfronthosting.co.za>
Message-ID: <1516208635.36.0.467229070634.issue32580@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

OK, looks like Qnap is doing something weird there - calls to getrandom result in EFAULT

Aha, first time that I see this error on getrandom().

Is it a kernel change? A libc change? Is Qnap a kind of sandbox?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32580>
_______________________________________

From report at bugs.python.org  Wed Jan 17 12:17:11 2018
From: report at bugs.python.org (Alan Moore)
Date: Wed, 17 Jan 2018 17:17:11 +0000
Subject: [issue32585] Add ttk::spinbox to tkinter.ttk
Message-ID: <1516209431.55.0.467229070634.issue32585@psf.upfronthosting.co.za>


New submission from Alan Moore <me at alandmoore.com>:

Ttk has a spinbox widget, which is a themed version of Tkinter spinbox, but this is missing from Python's ttk implementation.

----------
components: Tkinter
messages: 310198
nosy: Alan Moore
priority: normal
severity: normal
status: open
title: Add ttk::spinbox to tkinter.ttk
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32585>
_______________________________________

From report at bugs.python.org  Wed Jan 17 12:26:28 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 17 Jan 2018 17:26:28 +0000
Subject: [issue32585] Add ttk::spinbox to tkinter.ttk
In-Reply-To: <1516209431.55.0.467229070634.issue32585@psf.upfronthosting.co.za>
Message-ID: <1516209988.05.0.467229070634.issue32585@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5072
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32585>
_______________________________________

From report at bugs.python.org  Wed Jan 17 12:30:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Jan 2018 17:30:16 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516210216.96.0.467229070634.issue32571@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5073

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Wed Jan 17 12:35:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Jan 2018 17:35:42 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516210542.42.0.467229070634.issue32571@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 5222 provides functions _PyObject_LookupAttr() and _PyObject_LookupAttrId() with alternate interface. Some code becomes even more simpler.

The possible drawback of this approach is that the compiler should allocate the variable for the result on the stack instead of passing the result in a register (unless compilers are smart enough for optimizing out this case).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Wed Jan 17 12:41:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Jan 2018 17:41:36 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516210896.6.0.467229070634.issue32571@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Because this API is experimental. It was changed in recent 24 hours and may be changed more before merging or even after releasing 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:00:55 2018
From: report at bugs.python.org (Tim Morris)
Date: Wed, 17 Jan 2018 18:00:55 +0000
Subject: [issue32586] urllib2 HOWTO URLError example minor error
Message-ID: <1516212055.1.0.467229070634.issue32586@psf.upfronthosting.co.za>


New submission from Tim Morris <timothy at morrises.org.uk>:

In the HOWTO for urllib2 for Python 2, in the Handling Exceptions section, it discusses the URLError exception being raised by urlopen() (https://docs.python.org/2/howto/urllib2.html#urlerror). The code snippet example for this has (I think) a minor error:
the 3rd line reads:
"except URLError as e:"
which I think should be:
"except urllib2.URLError as e:"

The code as given only works if urllib2 had been imported via:
"from urllib2 import *"
The snippet doesn't list the import statements but all the other examples just use "import urllib2" (and obviously "from x import *" is bad practice anyway and wouldn't be encouraged or expected).

I am relatively new to Python, so it's possible it *is* correct and I just implemented it incorrectly. But if not, it would be helpful to correct it (even though it's a very minor error) so that other newbies like me don't come unstuck when using the tutorial.

----------
assignee: docs at python
components: Documentation
messages: 310201
nosy: MarmiteFox, docs at python
priority: normal
severity: normal
status: open
title: urllib2 HOWTO URLError example minor error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32586>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:04:42 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 17 Jan 2018 18:04:42 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1516212282.28.0.467229070634.issue32529@psf.upfronthosting.co.za>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:07:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 17 Jan 2018 18:07:32 +0000
Subject: [issue32529] Call readinto in shutil.copyfileobj
In-Reply-To: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>
Message-ID: <1516212452.45.0.467229070634.issue32529@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:09:12 2018
From: report at bugs.python.org (Seppo Yli-Olli)
Date: Wed, 17 Jan 2018 18:09:12 +0000
Subject: [issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
Message-ID: <1516212552.32.0.467229070634.issue32587@psf.upfronthosting.co.za>


New submission from Seppo Yli-Olli <seppo.yli-olli at iki.fi>:

MSDN documents that REG_MULTI_SZ is not supposed to have \0\0 anywhere else than in the end. The comment in  
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/PC/winreg.c#L504
clearly shows that Python has the assumption that this specification is actually correct. However, Microsoft is violating it eg in https://technet.microsoft.com/en-us/library/cc960241.aspx which prevents you from reading that registry key in Python at all. This is a list which is treated as pairs:
"""
foo

meep
bar
"""
so you can have empty items which in Windows semantics means "remove this file". This results in a string like "foo\0\0meep\0\bar\0\0". I'm proposing relaxing Python registry handling semantics because it's clearly Microsoft isn't following this either

----------
messages: 310202
nosy: nanonyme
priority: normal
severity: normal
status: open
title: Make REG_MULTI_SZ support PendingFileRenameOperations

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32587>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:23:36 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Jan 2018 18:23:36 +0000
Subject: [issue32576] concurrent.futures.thread potential deadlock due to
 Queue in weakref callback
In-Reply-To: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>
Message-ID: <1516213416.05.0.467229070634.issue32576@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also https://bugs.python.org/issue21009

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:41:56 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 17 Jan 2018 18:41:56 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516214516.8.0.467229070634.issue32571@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Well, mostly I just want to draw your attention to that use case to encourage you to make it public when it's ready :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Wed Jan 17 15:20:20 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Jan 2018 20:20:20 +0000
Subject: [issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
In-Reply-To: <1516212552.32.0.467229070634.issue32587@psf.upfronthosting.co.za>
Message-ID: <1516220420.01.0.467229070634.issue32587@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32587>
_______________________________________

From report at bugs.python.org  Wed Jan 17 15:29:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Jan 2018 20:29:51 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516220991.65.0.467229070634.issue30693@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

This doesn't seem appropriate to me for backporting to existing releases (3.6. and 2.7).  AFAIK, the current file-system-order behavior has never been identified as a bug.  Unless there is a stronger case for changing the existing 3.6.x behavior, I am -1 on backporting.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 17 15:52:11 2018
From: report at bugs.python.org (=?utf-8?b?SmVybmVqIFNpbW9uxI1pxI0=?=)
Date: Wed, 17 Jan 2018 20:52:11 +0000
Subject: [issue32580] Fallback to dev_urandom doesn't work when py_getrandom
 returns -1
In-Reply-To: <1516194668.11.0.467229070634.issue32580@psf.upfronthosting.co.za>
Message-ID: <1516222330.99.0.467229070634.issue32580@psf.upfronthosting.co.za>


Jernej Simon?i? <jernej+s-python at eternallybored.org> added the comment:

Qnap is a NAS, and while I'm running Gentoo inside LXC, EFAULT is returned by getrandom syscall even in the host OS. The model I'm doing this on is TS-228, uname -a of the host OS reports:

Linux qnap 3.10.20-al-2.5.3 #67 SMP PREEMPT Sat Dec 30 04:29:34 CST 2017 armv7l unknown

This is with the latest firmware installed as of this writing - 4.3.4.0435 (30.12.2017).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32580>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:03:30 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 17 Jan 2018 22:03:30 +0000
Subject: [issue21009] Potential deadlock in concurrent futures when garbage
 collection occurs during Queue.get
In-Reply-To: <1395416846.85.0.759574712799.issue21009@psf.upfronthosting.co.za>
Message-ID: <1516226610.26.0.467229070634.issue21009@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

there's a PR on the other issue i opened for this without noticing this one so i'm marking this as the dup.

----------
nosy: +gregory.p.smith
resolution:  -> duplicate
stage:  -> patch review
status: open -> closed
superseder: queue.Queue() is not reentrant, so signals and GC can cause deadlocks -> concurrent.futures.thread potential deadlock due to Queue in weakref callback

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21009>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:04:37 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 17 Jan 2018 22:04:37 +0000
Subject: [issue32576] concurrent.futures.thread deadlock due to Queue in
 weakref callback
In-Reply-To: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>
Message-ID: <1516226677.67.0.467229070634.issue32576@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
title: concurrent.futures.thread potential deadlock due to Queue in weakref callback -> concurrent.futures.thread deadlock due to Queue in weakref callback

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:08:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 22:08:21 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1516226901.15.0.467229070634.issue32226@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset e860089fd93728824cf586fa4d91f08eff3bab73 by Victor Stinner in branch 'master':
bpo-32226: Fix memory leak in generic_alias_dealloc() (#5212)
https://github.com/python/cpython/commit/e860089fd93728824cf586fa4d91f08eff3bab73


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:09:56 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Jan 2018 22:09:56 +0000
Subject: [issue32588] Move _findvs into its own extension module
Message-ID: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

The _findvs module I added for distutils has added load-time dependencies on the ole32 and oleaut32 DLLs.

To reduce startup time, we should move _findvs into its own .pyd (unless I hear a better suggestion, I like "distutils._findvs.pyd").

----------
components: Distutils, Windows
messages: 310209
nosy: dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Move _findvs into its own extension module
type: performance
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:10:27 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jan 2018 22:10:27 +0000
Subject: [issue32576] concurrent.futures.thread deadlock due to Queue in
 weakref callback
In-Reply-To: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>
Message-ID: <1516227027.73.0.467229070634.issue32576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the heads up Mark.  Unfortunately the reproducer script https://bugs.python.org/issue21009 needs to hack into Queue.get(), which isn't possible for the C-implemented SimpleQueue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:11:12 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Jan 2018 22:11:12 +0000
Subject: [issue32588] Move _findvs into its own extension module
In-Reply-To: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>
Message-ID: <1516227072.15.0.467229070634.issue32588@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Actually, I'd prefer not dropping it into the Lib directory, so probably DLLs/_distutils_findvs.pyd is the way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:11:42 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jan 2018 22:11:42 +0000
Subject: [issue21009] Potential deadlock in concurrent futures when garbage
 collection occurs during Queue.get
In-Reply-To: <1395416846.85.0.759574712799.issue21009@psf.upfronthosting.co.za>
Message-ID: <1516227102.65.0.467229070634.issue21009@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a proposed fix in https://github.com/python/cpython/pull/5216
It would be nice if someone able to reproduce this issue could test it (the reproducer script here wouldn't work with the new SimpleQueue implementation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21009>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:24:11 2018
From: report at bugs.python.org (Daniel)
Date: Wed, 17 Jan 2018 22:24:11 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1516227851.96.0.467229070634.issue9033@psf.upfronthosting.co.za>


Daniel <dbkats at gmail.com> added the comment:

I can confirm this behaviour for python 3.6.0 on Mac OS X 10.12.6

----------
nosy: +boompig
versions: +Python 3.6 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Wed Jan 17 18:05:43 2018
From: report at bugs.python.org (Daniel Plakhotich)
Date: Wed, 17 Jan 2018 23:05:43 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1516230343.27.0.467229070634.issue3177@psf.upfronthosting.co.za>


Daniel Plakhotich <daniel.plakhotich at gmail.com> added the comment:

> tl;dr: shutil.whatever should call startfile(..., 'edit') or xdg-open; other actions implemented by startfile are not cross-platform.

xdg-open is just a shell script that calls desktop-specific launchers. The behavior of these launchers is very different when it comes to executables. There is no guarantee that calling xdg-open for a script will open it for editing.

For example, there are 3 launchers on my XFCE machine: exo-open (native for XFCE), gvfs-open (GNOME), and kde-open. When called with a .py script with shebang line and executable bit set, exo-open and kde-open open text editor, but gvfs-open launches the script. When called for a real exe, exo-open and gvfs-open launch it, but kde-open brings a message box saying that the exe will not be started for safety reasons.

***

The patch raises NoAssociatedApplicationError when xdg-open returns 3, but this error code actually means that a launcher was not found.

----------
nosy: +plakhotich

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Wed Jan 17 18:17:27 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Jan 2018 23:17:27 +0000
Subject: [issue32566] Not able to open Python IDLE
In-Reply-To: <1516095028.12.0.467229070634.issue32566@psf.upfronthosting.co.za>
Message-ID: <1516231047.07.0.467229070634.issue32566@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Looks like you have a prerelease version of the CRT on your machine. Try finding and installing the latest Visual C++ 2017 Redistributables from Microsoft.

A newer version would have been installed by Python but since it wasn't I assume you have some other program on your PATH that has included a (not quite) private copy of ucrtbase.dll. If you can find and update or uninstall that program, and then reinstall Python it should resolve it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32566>
_______________________________________

From report at bugs.python.org  Wed Jan 17 19:38:23 2018
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Jan 2018 00:38:23 +0000
Subject: [issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
In-Reply-To: <1516212552.32.0.467229070634.issue32587@psf.upfronthosting.co.za>
Message-ID: <1516235903.16.0.467229070634.issue32587@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

PyWin32's win32api.RegQueryValueEx and win32api.RegEnumValue also use the same documented interpretation of REG_MULTI_SZ [1] (i.e. a "sequence of null-terminated strings, terminated by an empty string").

[1]: https://msdn.microsoft.com/en-us/library/ms724884

However, in practice Windows doesn't follow this literal interpretation. For example, the Session Manager (smss.exe) reads the "PendingFileRenameOperations" REG_MULTI_SZ value using the documented runtime library function RtlQueryRegistryValues [2]. By default, this function calls the specified QueryRoutine for each null-terminated string when reading a REG_MULTI_SZ value. 

[2]: https://msdn.microsoft.com/en-us/library/ff562046

I've verified that RtlQueryRegistryValues does not terminate the read on the first empty string, but instead continues to iterate through the entire value. See the attached test script, rtlqueryreg.py. The following output was obtained after two calls to MoveFileEx with the flag MOVEFILE_DELAY_UNTIL_REBOOT that pended operations to delete "foo" and rename "meep" to "bar":

    PendingFileRenameOperations, REG_SZ, \??\C:\Temp\foo
    PendingFileRenameOperations, REG_SZ, <empty>
    PendingFileRenameOperations, REG_SZ, \??\C:\Temp\meep
    PendingFileRenameOperations, REG_SZ, \??\C:\Temp\bar

Currently, winreg terminates reading this value at the first empty string. For example:

    >>> hkey = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,
    ...     r'SYSTEM\CurrentControlSet\Control\Session Manager')
    >>> winreg.QueryValueEx(hkey, 'PendingFileRenameOperations')
    (['\\??\\C:\\Temp\\foo'], 7)

This behavior is inconsistent with Windows, which I think presents a strong case for the suggested change. As always, there's an issue with introducing breaking changes. It may be too late in the development cycle to introduce this change in 3.7.

----------
nosy: +eryksun
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47394/rtlqueryreg.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32587>
_______________________________________

From report at bugs.python.org  Wed Jan 17 19:49:57 2018
From: report at bugs.python.org (Angie G)
Date: Thu, 18 Jan 2018 00:49:57 +0000
Subject: [issue29406] asyncio SSL contexts leak sockets after calling close
 with certain Apache servers
In-Reply-To: <1485909545.04.0.650924943503.issue29406@psf.upfronthosting.co.za>
Message-ID: <1516236597.93.0.467229070634.issue29406@psf.upfronthosting.co.za>


Change by Angie G <angelynn68sky at gmail.com>:


----------
components: +Build, SSL
type: resource usage -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29406>
_______________________________________

From report at bugs.python.org  Wed Jan 17 20:03:38 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 01:03:38 +0000
Subject: [issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
In-Reply-To: <1516212552.32.0.467229070634.issue32587@psf.upfronthosting.co.za>
Message-ID: <1516237418.94.0.467229070634.issue32587@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I don't think it's too late (and I don't think this counts as a feature either, so the b1 deadline doesn't apply), but the patch would need to include an update to What's New as well as the usual stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32587>
_______________________________________

From report at bugs.python.org  Wed Jan 17 21:59:27 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 18 Jan 2018 02:59:27 +0000
Subject: [issue14127] add st_*time_ns fields to os.stat(),
 add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds
In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>
Message-ID: <1516244367.79.0.467229070634.issue14127@psf.upfronthosting.co.za>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14127>
_______________________________________

From report at bugs.python.org  Wed Jan 17 22:33:41 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 03:33:41 +0000
Subject: [issue32588] Move _findvs into its own extension module
In-Reply-To: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>
Message-ID: <1516246421.24.0.467229070634.issue32588@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Wed Jan 17 22:34:25 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 03:34:25 +0000
Subject: [issue29911] Uninstall command line in Windows registry does not
 uninstall
In-Reply-To: <1490551774.28.0.407532543156.issue29911@psf.upfronthosting.co.za>
Message-ID: <1516246465.15.0.467229070634.issue29911@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29911>
_______________________________________

From report at bugs.python.org  Wed Jan 17 23:02:53 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 04:02:53 +0000
Subject: [issue32588] Move _findvs into its own extension module
In-Reply-To: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>
Message-ID: <1516248173.99.0.467229070634.issue32588@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +5074
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Wed Jan 17 23:32:16 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 04:32:16 +0000
Subject: [issue32588] Move _findvs into its own extension module
In-Reply-To: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>
Message-ID: <1516249936.84.0.467229070634.issue32588@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +5075

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Wed Jan 17 23:54:22 2018
From: report at bugs.python.org (Matthias Gilch)
Date: Thu, 18 Jan 2018 04:54:22 +0000
Subject: [issue32589] Statistics as a result from timeit
Message-ID: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>


New submission from Matthias Gilch <matthias.gilch.mg+py at gmail.com>:

I propose to add a function parameter for timeit to get some statistics back from it. I think it's inconvenient to write those stubs every time when we have a method for this in the standard library that could be easily used with a few changes in it.

----------
components: Library (Lib)
messages: 310218
nosy: MGilch
priority: normal
severity: normal
status: open
title: Statistics as a result from timeit
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Thu Jan 18 00:05:22 2018
From: report at bugs.python.org (Matthias Gilch)
Date: Thu, 18 Jan 2018 05:05:22 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516251922.45.0.467229070634.issue32589@psf.upfronthosting.co.za>


Change by Matthias Gilch <matthias.gilch.mg+py at gmail.com>:


----------
keywords: +patch
pull_requests: +5076
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Thu Jan 18 00:32:11 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 18 Jan 2018 05:32:11 +0000
Subject: [issue32590] Proposal: add an "ensure(arg)" builtin for parameter
 validation
Message-ID: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

This proposal is an outcome of repeated requests on python-ideas that assert statements be made unconditional, so they can be legitimately used for parameter validation, rather than solely as a form of inline self-test.

Rather than changing the assert statement, an alternative option would be to provide a new builtin (suggested name: "ensure") that raises ValidationError (a new subclass of AssertionError) if the first argument is false.

As a function, the new builtin could accept parameters for:

- the message to be reported on failure
- the exception type to be raised on failure

And since it would only be a new builtin rather than a new keyword, existing uses of the name "ensure" would be unaffected (except to the extent that linters may start warning about shadowing a builtin).

(Since it's a suggestion for a new builtin, actually doing this would require a PEP, which I'm not planning to write, I just wanted to get the suggestion explicitly on the record rather than leaving it buried in mailing list archives)

----------
messages: 310219
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Proposal: add an "ensure(arg)" builtin for parameter validation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Thu Jan 18 01:02:39 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 18 Jan 2018 06:02:39 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516255359.1.0.467229070634.issue32589@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

What sort of statistics, and why do you think they are going to be meaningful?

Measurement errors in the timings aren't two-sided, they are only one-sided, which means calculating the mean and standard deviation isn't appropriate. This is documented in the Timer.repeat() method:

    Note: it's tempting to calculate mean and standard deviation
    from the result vector and report these.  However, this is not
    very useful.  In a typical case, the lowest value gives a lower
    bound for how fast your machine can run the given code snippet;
    higher values in the result vector are typically not caused by
    variability in Python's speed, but by other processes interfering
    with your timing accuracy.  So the min() of the result is
    probably the only number you should be interested in.


The purpose of the mean is to estimate the actual time taken by the computation, less any random errors ("noise") in the measurement values.

If random noise is centred around zero, then the positive errors and the negative errors tend to cancel, and the mean is the best estimate of the actual computation time. But the noise isn't centred on zero, there are no negative noise, and the mean estimates the computation time plus the average measurement error, not the computation time.

In other words, given a bunch of measurements:

timer = Timer(code, setup)
values = timer.repeat()

the closest estimate to the true computation time is min(values), not mean(values).

If you still insist on generating statistics, they're not difficult to collect using the statistics module:

statistics.mean(values)
statistics.stdev(values)

If there are additional statistics you would like to see, they should be added to the statistics module, not timeit.

----------
nosy: +steven.daprano, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Thu Jan 18 01:10:38 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 18 Jan 2018 06:10:38 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516255838.74.0.467229070634.issue32589@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> What sort of statistics...?

I answered my own question... I see that in your PR, you return a dict with the mean, median, *population* variance and standard deviation, and total.

Why the population variance/stdev rather than the sample? That seems inappropriate to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Thu Jan 18 01:21:15 2018
From: report at bugs.python.org (Matthias Gilch)
Date: Thu, 18 Jan 2018 06:21:15 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516256475.23.0.467229070634.issue32589@psf.upfronthosting.co.za>


Matthias Gilch <matthias.gilch.mg+py at gmail.com> added the comment:

Population seemed appropriate to me. 

I'd define the list of times as a whole "population" that stands for its own. 

I should probably add both, the sample and population, values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Thu Jan 18 01:28:16 2018
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 18 Jan 2018 06:28:16 +0000
Subject: [issue31087] asyncio.create_subprocess_* do not honor `encoding`
In-Reply-To: <1501477317.46.0.791551033282.issue31087@psf.upfronthosting.co.za>
Message-ID: <1516256896.64.0.467229070634.issue31087@psf.upfronthosting.co.za>


Dima Tisnek <dimaqq at gmail.com> added the comment:

I'd love to see universal_newlines=True in asyncio.subprocess.

----------
nosy: +Dima.Tisnek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31087>
_______________________________________

From report at bugs.python.org  Thu Jan 18 01:51:19 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 18 Jan 2018 06:51:19 +0000
Subject: [issue31087] asyncio.create_subprocess_* do not honor `encoding`
In-Reply-To: <1501477317.46.0.791551033282.issue31087@psf.upfronthosting.co.za>
Message-ID: <1516258279.69.0.467229070634.issue31087@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Python's codecs already support partial decode, exactly to handle this kind of case. See codecs.getincremental{en,de}coder and

https://docs.python.org/3/library/codecs.html#incremental-encoding-and-decoding

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31087>
_______________________________________

From report at bugs.python.org  Thu Jan 18 01:52:11 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 18 Jan 2018 06:52:11 +0000
Subject: [issue32590] Proposal: add an "ensure(arg)" builtin for parameter
 validation
In-Reply-To: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>
Message-ID: <1516258331.4.0.467229070634.issue32590@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oh I can just imagine the bike-shedding on this one :-)

I'm not really convinced this is needed, but for what it's worth I think that given the intended use-case (checking function parameters) ValueError would be a more appropriate default exception type. The given argument has the wrong value, hence ValueError.

On the other hand, it is more common (at least for me) to check arguments with isinstance, so maybe the default should be TypeError.

Definitely needs a PEP.

----------
nosy: +steven.daprano
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Thu Jan 18 02:09:05 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 18 Jan 2018 07:09:05 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
Message-ID: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

sys.set_coroutine_wrapper is a problematic API. It was added to solve a specific problem: asyncio debug mode wanting to track where coroutine objects are created, so that when unawaited coroutines are GC'ed, the warning they print can include a traceback. But to do this, it adds a *very* generic hook that lets you hook into the coroutine creation code to replace all instances of a built-in type with an arbitrary new type, which is highly unusual. It's hard to use correctly (see bpo-30578, and bpo-24342 before it). It's hard to use without creating performance problems, since anything you do here tends to add overhead to every async function call, and in many cases also every async function frame suspend/resume cycle.

Fortunately, it's explicitly documented as provisional. (I think Yury intentionally excluded it from the stabilization of the rest of asyncio and async/await, because of the reasons above.) And the things we *actually* want to do here are very simple. The only known use cases are the one mentioned above (see asyncio.coroutines.CoroWrapper), and the one in bpo-30491. So after discussions with Yury, I'm proposing to migrate those both into the interpreter as directly usable, fast, built-in features that can be used individually or together, and deprecate sys.set_coroutine_wrapper.

See bpo-30491 for details on that use case; here I'll discuss my plan for replacing the "coroutine origin tracking" that asyncio debug mode does.

We add a new function sys.set_coroutine_origin_tracking(depth), and I guess sys.get_coroutine_origin_tracking() because why not. The depth is thread-local, and defaults to 0, which means that newly created coroutines don't capture any origin info.

When a coroutine is created, it will check the current origin_tracking depth, and capture that many frames of traceback information. Like the current asyncio debug code and unlike real tracebacks, we won't capture actual frame objects -- we'll just capture (filename, lineno, function) information, to avoid pinning objects in memory. This is a debug helper, so it should avoid changing semantics whenever possible.

Later, we can retrieve the captured information by accessing the new attribute coro.origin.

In addition, the code in CoroutineType.__del__ that currently emits a warning for unawaited coroutines, will be modified to check for whether 'self' has origin information, and print it if so, similar to the current asyncio debug wrapper.

Some particular points where I'd appreciate feedback:

Should we add an envvar to configure coroutine source tracking? What about an -X switch?

Should it be coro.origin or coro.cr_origin? On the one hand the cr_ prefixing is super annoying and I think we should probably get rid of it; on the other maybe we should keep it here so things stay consistent and then have a separate the debate about removing it in general.

Most important: what format should we use for storing the origin information? I can see three plausible approaches:

1. Call traceback.StackSummary.extract. This means re-entering the Python interpreter from inside the coroutine setup code, which makes me a little nervous. I guess there can't be any real re-entrancy issues here because if there were, set_coroutine_wrapper would already be hitting them. Can it cause problems during shutdown when the traceback module might have disappeared? (Not that anyone's likely to be instantiating coroutines at that point.) It also might be a bit slower than the other options below, but this isn't clear. OTOH, it has the benefit that coro.origin could be a full-fledged StackSummary with all its features, like traceback printing. Which honestly feels a little weird to me, because I know coroutine objects are built-in and StackSummary objects aren't, but it would certainly be convenient.

2. Capture (filename, lineno, function) directly in a packed struct, similar to how tracemalloc works. Then coro.origin can unpack this into a list of tuples or whatever. This is definitely very fast, and avoids re-entering Python. In practice we'd probably still end up needing to re-enter Python and using the traceback module when it came time to print a warning, though, because traceback printing is complicated and we don't want to reimplement it. Also, if the origin comes from a custom importer like zipimport, then we may not be able to look up the line information later, because that requires access to frame.f_globals["__loader__"].

3. Like (2), but insert a call to linecache.lazycache for each origin frame we capture. This would fix option (2)'s issue with printing source lines, but it means re-entering Python as well, so at this point maybe it'd just be simpler to go with option (1).

Given this analysis I guess I'm leaning towards just calling StackSummary.extract, but I don't feel like I fully understand the consequences of calling into a Python module like that so want to hear what others think.

----------
components: Interpreter Core, asyncio
messages: 310226
nosy: asvetlov, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate sys.set_coroutine_wrapper and replace it with more focused API(s)
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Thu Jan 18 03:35:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 08:35:29 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1516264529.85.0.467229070634.issue9566@psf.upfronthosting.co.za>


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


----------
pull_requests: +5077

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Thu Jan 18 04:37:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 09:37:18 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
Message-ID: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

https://docs.python.org/dev/using/windows.html#supported-versions

"As specified in PEP 11, a Python release only supports a Windows platform while Microsoft considers the platform under extended support. This means that Python 3.7 supports Windows Vista and newer. If you require Windows XP support then please install Python 3.4."

But Windows Vista extended supported already ended last year, in April 2017.

Attached PR removes code to support Windows Vista.

----------
components: Windows
messages: 310227
nosy: paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Drop support of Windows Vista in Python 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Thu Jan 18 04:38:10 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Jan 2018 09:38:10 +0000
Subject: [issue32576] concurrent.futures.thread deadlock due to Queue in
 weakref callback
In-Reply-To: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>
Message-ID: <1516268290.58.0.467229070634.issue32576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset ab74504346a6e2569b3255b7b621c589716888c4 by Antoine Pitrou in branch 'master':
bpo-32576: use queue.SimpleQueue in critical places (#5216)
https://github.com/python/cpython/commit/ab74504346a6e2569b3255b7b621c589716888c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Thu Jan 18 04:38:23 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Jan 2018 09:38:23 +0000
Subject: [issue32576] concurrent.futures.thread deadlock due to Queue in
 weakref callback
In-Reply-To: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>
Message-ID: <1516268303.09.0.467229070634.issue32576@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Thu Jan 18 04:38:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 09:38:45 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516268325.05.0.467229070634.issue32592@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5078
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:01:19 2018
From: report at bugs.python.org (Me01100Nobody)
Date: Thu, 18 Jan 2018 10:01:19 +0000
Subject: [issue29564] ResourceWarning: suggest to enable tracemalloc in the
 message
In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za>
Message-ID: <1516269679.39.0.467229070634.issue29564@psf.upfronthosting.co.za>


Change by Me01100Nobody <electronnn at gmail.com>:


----------
nosy: +Me01100Nobody

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29564>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:08:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 10:08:47 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
Message-ID: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

FreeBSD 9.3 support ended at December 31, 2016. It's time to drop code for compatibility with FreeBSD 9 and older.
https://www.freebsd.org/security/unsupported.html

Attached PR removes this code.

----------
components: Build
messages: 310229
nosy: vstinner
priority: normal
severity: normal
status: open
title: Drop support of FreeBSD 9 and older in Python 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:09:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 10:09:30 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516270170.71.0.467229070634.issue32593@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5079
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:09:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 10:09:50 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516270190.67.0.467229070634.issue32593@psf.upfronthosting.co.za>


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


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:15:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 10:15:27 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1516270527.6.0.467229070634.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 05d68a8bd84cb141be9f9335f5b3540f15a989c4 by Victor Stinner in branch 'master':
bpo-9566: Fix size_t=>int downcast warnings (#5230)
https://github.com/python/cpython/commit/05d68a8bd84cb141be9f9335f5b3540f15a989c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:41:10 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 18 Jan 2018 10:41:10 +0000
Subject: [issue32590] Proposal: add an "ensure(arg)" builtin for parameter
 validation
In-Reply-To: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>
Message-ID: <1516272070.13.0.467229070634.issue32590@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Since this is intended for argument checking, i.e. testing preconditions, the Eiffel term "require" seems more appropriate.

https://www.eiffel.org/doc/eiffel/ET:%20Design%20by%20Contract%20(tm),%20Assertions%20and%20Exceptions#Preconditions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:56:09 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 18 Jan 2018 10:56:09 +0000
Subject: [issue30811] A venv created and activated from within a virtualenv
 uses the outer virtualenv's site-packages rather than its own.
In-Reply-To: <1498813368.34.0.349011380575.issue30811@psf.upfronthosting.co.za>
Message-ID: <1516272969.63.0.467229070634.issue30811@psf.upfronthosting.co.za>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

Plot twist: the workaround does not work on Windows.

    $ cd SOMEDIR   ; Placeholder for a valid directory.
    $ virtualenv env1
    ...
    $ env\Scripts\python.exe
    Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sysconfig
    >>> print(sysconfig.get_config_var('BINDIR'))
    SOMDIR\env1\Scripts

This points to the virtualenv's BINDIR, not the real Python installation's :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30811>
_______________________________________

From report at bugs.python.org  Thu Jan 18 06:01:27 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 11:01:27 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516273287.68.0.467229070634.issue32592@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

The only changes necessary in the installer should be in PythonBootstrapperApplication.cpp to make it an error when run on pre-Win7 OS. The pattern is already there, and the string references are in Tools/msi/bundle/Default.wxl

If you don't get to it, reassign the bug to me once you've merged the first part and I'll look at the installer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Thu Jan 18 06:02:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 11:02:12 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516273332.76.0.467229070634.issue32592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> If you don't get to it, reassign the bug to me once you've merged the first part and I'll look at the installer.

I like that :-) Will me. Right now, my PR doesn't compile, I broke something and I don't understand the error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Thu Jan 18 06:20:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 11:20:28 +0000
Subject: [issue29871] Enable optimized locks on Windows
In-Reply-To: <1490146396.76.0.76409234296.issue29871@psf.upfronthosting.co.za>
Message-ID: <1516274428.63.0.467229070634.issue29871@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

FYI I proposed a PR which removes the emulation of condition variable:
https://github.com/python/cpython/pull/5231

This PR removes code specific to Windows Vista: see bpo-32592.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29871>
_______________________________________

From report at bugs.python.org  Thu Jan 18 07:22:26 2018
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 18 Jan 2018 12:22:26 +0000
Subject: [issue32570] Python crash 0xc00000fd Windows10 x64 - "fail without
 words"
In-Reply-To: <1516122545.09.0.467229070634.issue32570@psf.upfronthosting.co.za>
Message-ID: <1516278146.68.0.467229070634.issue32570@psf.upfronthosting.co.za>


?????? ????????? <vasilij.kolomiets at gmail.com> added the comment:

sorry - wrong ideone example
this one better to look:
https://ideone.com/aV9Z8p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32570>
_______________________________________

From report at bugs.python.org  Thu Jan 18 08:40:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 13:40:52 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516282852.89.0.467229070634.issue32593@psf.upfronthosting.co.za>


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


----------
pull_requests: +5080

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Thu Jan 18 08:51:34 2018
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Jan 2018 13:51:34 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
Message-ID: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

I stumbled on what I think is an inconsistency in the "name" attribute of file objects. When a file is opened with an existing file descriptor, the "name" attribute is of type int (this from a 3.6.4 session, but it also exists in 2.7):

>>> import sys
>>> sys.stderr.name
'<stderr>'
>>> f = open(sys.stderr.fileno())
>>> f.name
2
>>> type(f.name)
<class 'int'>

I thought it odd that the standard I/O objects would be blessed with string filenames (despite not representing real filesystem paths), but that files opened by file descriptor would have that file descriptor as their name.

I looked in the documentation for open():

https://docs.python.org/3/library/functions.html#open

but saw no mention of the "name" attribute at all. In fact, the first argument to open() is called "file", so it's not obvious that the "name" attribute needs to be a copy of that parameter.

It seems to me that "name" attributes of open file objects should be of a consistent type, even if they might not represent an actual path in the filesystem. Even if this dual-type behavior is retained, it should be documented.

----------
assignee: docs at python
components: Documentation, IO, Interpreter Core
messages: 310237
nosy: docs at python, skip.montanaro
priority: normal
severity: normal
status: open
title: File object 'name' attribute inconsistent type and not obviously documented
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 08:55:49 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 18 Jan 2018 13:55:49 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516283749.73.0.467229070634.issue32594@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Skip,

I only tested with the last revision of 2.7

Python 2.7.14+ (heads/2.7:b1a52b1167, Jan 18 2018, 14:53:29) 
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stderr.name
'<stderr>'
>>> f = open(sys.stderr.fileno())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercing to Unicode: need string or buffer, int found


I can't create a file with an int.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 08:58:11 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 18 Jan 2018 13:58:11 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516283891.44.0.467229070634.issue32594@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

but I can confirm your issue with 3.6.4+

Python 3.6.4+ (heads/3.6:f31c70b0d6, Jan 18 2018, 14:57:01) 
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stderr.name
'<stderr>'
>>> f = open(sys.stderr.fileno())
>>> f.name
2
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 08:58:33 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 18 Jan 2018 13:58:33 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516283913.77.0.467229070634.issue32594@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 09:07:00 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Jan 2018 14:07:00 +0000
Subject: [issue31399] Let OpenSSL verify hostname and IP address
In-Reply-To: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
Message-ID: <1516284420.1.0.467229070634.issue31399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Bad news, LibreSSL is the worst. Even the latest release 2.6.4 does not implement https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PARAM_set1_host.html or X509_VERIFY_PARAM_set_hostflags(). I don't get why it provides X509_check_host() but not X509_VERIFY_PARAM_set1_host().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31399>
_______________________________________

From report at bugs.python.org  Thu Jan 18 09:16:40 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Jan 2018 14:16:40 +0000
Subject: [issue31399] Let OpenSSL verify hostname and IP address
In-Reply-To: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
Message-ID: <1516285000.81.0.467229070634.issue31399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

https://github.com/libressl-portable/portable/issues/381

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31399>
_______________________________________

From report at bugs.python.org  Thu Jan 18 09:36:16 2018
From: report at bugs.python.org (Matthias Gilch)
Date: Thu, 18 Jan 2018 14:36:16 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516286176.54.0.467229070634.issue32589@psf.upfronthosting.co.za>


Matthias Gilch <matthias.gilch.mg+py at gmail.com> added the comment:

Added sample stdev and variance to the PR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Thu Jan 18 09:41:05 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jan 2018 14:41:05 +0000
Subject: [issue32590] Proposal: add an "ensure(arg)" builtin for parameter
 validation
In-Reply-To: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>
Message-ID: <1516286465.18.0.467229070634.issue32590@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not clear why we want a bug tracker issue for something that is still only an idea.  We generally *send* people to python-ideas when they propose half-baked ideas here :)  (Not actually saying your idea is half-baked, but it clearly isn't fully baked since there's no PEP.)  

There is literally no point in discussing this proposal here.  Normally for an issue like this (where we've redirected someone to python-ideas for discussion) we would close the issue and tell them to come back and re-open it if there is a positive consensus on python-ideas.  Since you are designating this as PEP level, there seems to be no reason to keep the issue open.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Thu Jan 18 09:53:26 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jan 2018 14:53:26 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516287206.82.0.467229070634.issue32594@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This has been discussed previously.  The nature of the 'name' attribute for file objects is not really specified, so I'm not even sure what we would document.  Maybe just that it is unspecified.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 10:05:20 2018
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 18 Jan 2018 15:05:20 +0000
Subject: [issue32570] Python crash 0xc00000fd Windows10 x64 - "fail without
 words"
In-Reply-To: <1516122545.09.0.467229070634.issue32570@psf.upfronthosting.co.za>
Message-ID: <1516287920.01.0.467229070634.issue32570@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

CPython pushes a frame on the thread's stack for every Python frame. By default in Windows Python the thread's stack is allowed to grow up to about 2 MB. On Linux the default limit is 8 MB, but a higher limit can be set via `ulimit -s`. After the stack is full, pushing another value will crash the process due to a stack overflow. Windows raises a STATUS_STACK_OVERFLOW (0xC00000FD) exception. Linux raises a SIGSEGV signal (segmentation fault).

The default interpreter recursion limit of 1,000 is set to raise a Python RecursionError well before you'd see a hard crash from a stack overflow. If we ballpark a C stack frame at about 1 KB in 64-bit Python, then the default stack size on Windows should support a recursion limit of about 2,000. For a recursion limit of 100,000, I would estimate a 100 MB stack size.

You can call threading.stack_size(size_in_bytes) to reserve a larger stack size for new threads. However, in Python code it's better to rewrite such deeply recursive cases to use loops instead.

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32570>
_______________________________________

From report at bugs.python.org  Thu Jan 18 10:15:23 2018
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 18 Jan 2018 15:15:23 +0000
Subject: [issue32570] Python crash 0xc00000fd Windows10 x64 - "fail without
 words"
In-Reply-To: <1516122545.09.0.467229070634.issue32570@psf.upfronthosting.co.za>
Message-ID: <1516288523.95.0.467229070634.issue32570@psf.upfronthosting.co.za>


?????? ????????? <vasilij.kolomiets at gmail.com> added the comment:

Thanks a lot!
Grace and Honor!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32570>
_______________________________________

From report at bugs.python.org  Thu Jan 18 10:32:06 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 18 Jan 2018 15:32:06 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516289525.99.0.467229070634.issue32594@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Maybe we could add in the documentation.

"""
if we use a file descriptor as the parameter, the name of the returned file object will be the file descriptor itself.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 10:51:10 2018
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Jan 2018 15:51:10 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516290670.32.0.467229070634.issue32594@psf.upfronthosting.co.za>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

Apologies for the incomplete report. In 2.7 this anomaly exists in the io.open() function. You are correct, builtin open() in 2.x doesn't support opening by file descriptor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 11:01:06 2018
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Jan 2018 16:01:06 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516291266.66.0.467229070634.issue32594@psf.upfronthosting.co.za>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

I'm not terribly concerned with the end result, only that we wind up with a more consistent system. As I see it, there are two main problems:

1. The type of the name attribute varies

2. The name attribute appears to be undocumented, at least not in the obvious place.

Of lesser importance, but still unintuitive, is that the "name" attribute doesn't refer to an actual name in the filesystem. (I realize that the "name" of sys.std{in,out,err} is also meaningless when interpreted as an actual filename, but that ship sailed long ago.)

I realize that it might well be infeasible to modify behavior at this point. I do think it important to document the "name" attribute (item #2). After all, it doesn't appear to be obviously private.

I live in a Linux-only world, so this workaround in my own code is likely not useful everywhere, but, when I try to convert a builtin file object to an io.TextIOWrapper object using io.open(f.fileno()), I actually do this:

io.open("/dev/fd/{}".format(f.fileno()), ...)

This gives me a meaningful "name" attribute in that it is a string, and that it names an actual filename. How this might work on systems without "/dev/fd", I don't know, but might be worth thinking about for a couple minutes before dismissing it out-of-hand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 11:28:04 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 18 Jan 2018 16:28:04 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516292884.7.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

+1 on on the API and for adding it in 3.7 and for deprecating set_coroutine_wrapepr.  This will simplify asyncio code and other event loops (like uvloop) and will lead to less overhead on asyncio debug mode.

I always disliked the set_coroutine_wrapper API.  Even at the time when I added it to PEP 492 I understood that we'll have to replace it eventually with something more sensible.

I think we should start working on a patch.  Nathaniel, do you have time to champion the work?

> Most important: what format should we use for storing the origin information? I can see three plausible approaches:

I'd be strongly against calling `traceback.StackSummary.extract` when coroutine object is created.  Let's go with the option 2.  You can create a list of tuple objects without the need of inventing a new struct.  coroutine.cr_origin (let's have the "cr_" prefix; dropping the prefixes should be considered in a separate issue) should return that list object directly.

I'm not sure how exactly the warning print logic will work with a list of tuples in cr_origin, I propose to start working on the implementation and figure that out during the review process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Thu Jan 18 13:15:39 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jan 2018 18:15:39 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516299339.74.0.467229070634.issue32594@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe you are correct that it is too late to modify the existing behavior.  Too many programs depend on it.  As far as documenting, my point is that it is *not specified* what the name attribute contains.  It can contain literally anything, depending on the particular file object involved.

Could we document what the open function actually does?  That perhaps we could do, since it is likely that other python implementations will want to copy what CPython does in this case.  But as you observe, this can also be *system dependent*, so it is not completely clear to me exactly how we should do that.  That is, the description of what actually happens could be so complex that it might be better to just say something like "The exact type and value of the name attribute is not specified, but when the file is opened via a file system path it will almost always be that path as a string.".

I'd be happy for a better answer, though :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:09:20 2018
From: report at bugs.python.org (stein-k)
Date: Thu, 18 Jan 2018 19:09:20 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1516302560.57.0.467229070634.issue32498@psf.upfronthosting.co.za>


stein-k <karlsen.stein at gmail.com> added the comment:

Added a patch containing the fix, is this the proper way or should I create a pull request?

----------
keywords: +patch
Added file: https://bugs.python.org/file47395/urllib_parse_unquote_handle_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:28:25 2018
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 18 Jan 2018 19:28:25 +0000
Subject: [issue29752] Enum._missing_ not called for __getitem__ failures
In-Reply-To: <1488925792.17.0.971645599389.issue29752@psf.upfronthosting.co.za>
Message-ID: <1516303705.12.0.467229070634.issue29752@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

To move this forward:

The proposal is to add support for a new method, _missing_name_, which is called by __getitem__.

If such a method does not exist, the normal AttributeError exception is raised;

otherwise, the _missing_name_ method is called with the invalid name and should return a matching member or None;
- if None, the normal AttributeError exception is raised
- if a member, it is returned
- otherwise, a Type(?)Error is raised

----------
title: Enum._missing_ not called for __getattr__ failures -> Enum._missing_ not called for __getitem__ failures

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29752>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:28:39 2018
From: report at bugs.python.org (Seppo Yli-Olli)
Date: Thu, 18 Jan 2018 19:28:39 +0000
Subject: [issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
In-Reply-To: <1516212552.32.0.467229070634.issue32587@psf.upfronthosting.co.za>
Message-ID: <1516303719.57.0.467229070634.issue32587@psf.upfronthosting.co.za>


Seppo Yli-Olli <seppo.yli-olli at iki.fi> added the comment:

I don't personally know enough of CPython (I barely know enough C) to do the patches but I'd just comment that as this might increase complexity of implementation and wide char API's are used, it might be prudent to make sure the new implementation works with some more exotic input than fits into ASCII. PendingFileRenameOperations can contain any valid Windows path. Microsoft also warns that the end null byte can be redacted in some cases by the party storing the data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32587>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:31:45 2018
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 18 Jan 2018 19:31:45 +0000
Subject: [issue32218] add __iter__ to enum.Flag members
In-Reply-To: <1512445452.31.0.213398074469.issue32218@psf.upfronthosting.co.za>
Message-ID: <1516303905.04.0.467229070634.issue32218@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32218>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:33:12 2018
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 18 Jan 2018 19:33:12 +0000
Subject: [issue31801] vars() manipulation encounters problems with Enum
In-Reply-To: <1508199715.37.0.213398074469.issue31801@psf.upfronthosting.co.za>
Message-ID: <1516303992.71.0.467229070634.issue31801@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31801>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:34:17 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Jan 2018 19:34:17 +0000
Subject: [issue32590] Proposal: add an "ensure(arg)" builtin for parameter
 validation
In-Reply-To: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>
Message-ID: <1516304057.8.0.467229070634.issue32590@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I agree w/ David that this idea is premature. Plus I say it's easier to make it so -O is more fine-grained so you can leave in asserts but get __debug__ set to False.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:53:57 2018
From: report at bugs.python.org (Jonathan)
Date: Thu, 18 Jan 2018 19:53:57 +0000
Subject: [issue32595] Deque with iterable object as one object
Message-ID: <1516305237.13.0.467229070634.issue32595@psf.upfronthosting.co.za>


New submission from Jonathan <qjonathandaniel at gmail.com>:

Creating a deque with an iterable object creates extra overhead if you want to insert it as one element.

e.g:
import timeit

test1 = '''
str = "x" * 100000
lst = [str]
'''

test2 = '''
str = "x" * 100000
'''

print(timeit.timeit(test1, number=100000))
print(timeit.timeit(test2, number=100000))

If I want to add a string to a deque i will have to put it in a list first, this causes 23% slower performance in my case.

There should be a deque where this overhead is not needed because in most cases this will be used in performance demanding cases.

----------
components: Library (Lib)
messages: 310256
nosy: jonathandaniel
priority: normal
severity: normal
status: open
title: Deque with iterable object as one object
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32595>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:56:45 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Jan 2018 19:56:45 +0000
Subject: [issue32595] Deque with iterable object as one object
In-Reply-To: <1516305237.13.0.467229070634.issue32595@psf.upfronthosting.co.za>
Message-ID: <1516305405.54.0.467229070634.issue32595@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32595>
_______________________________________

From report at bugs.python.org  Thu Jan 18 15:27:49 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Jan 2018 20:27:49 +0000
Subject: [issue32595] Deque with iterable object as one object
In-Reply-To: <1516305237.13.0.467229070634.issue32595@psf.upfronthosting.co.za>
Message-ID: <1516307269.36.0.467229070634.issue32595@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry Jonathan, this is the way the python containers work if they take an iterable input.  In the case of a str, it is not possible for us to know whether you mean for deque('abc') to go it as three arguments or as one.

FWIW, if you don't what to put the single element in a list, the API provides the append() method for adding scalars and extend() method for adding iterables:

   d = deque()
   d.append('abc')
   d.extend('abc')

Note that lists behave the same way.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32595>
_______________________________________

From report at bugs.python.org  Thu Jan 18 15:35:10 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Jan 2018 20:35:10 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516307710.64.0.467229070634.issue26163@psf.upfronthosting.co.za>


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


----------
pull_requests: +5081

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Thu Jan 18 16:34:49 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Jan 2018 21:34:49 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1516311289.23.0.467229070634.issue26163@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5082

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26163>
_______________________________________

From report at bugs.python.org  Thu Jan 18 17:09:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 22:09:42 +0000
Subject: [issue32588] Move _findvs into its own extension module
In-Reply-To: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>
Message-ID: <1516313382.88.0.467229070634.issue32588@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 2507e29a9e4e9dcac6eab46546bd3d34a69342ba by Steve Dower in branch 'master':
bpo-32588: Move _findvs into its own module and add missing _queue module to installer (#5227)
https://github.com/python/cpython/commit/2507e29a9e4e9dcac6eab46546bd3d34a69342ba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Thu Jan 18 17:09:51 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 22:09:51 +0000
Subject: [issue32588] Move _findvs into its own extension module
In-Reply-To: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>
Message-ID: <1516313391.14.0.467229070634.issue32588@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset ccf7f05c5d3fdea89d857e775d2c6371f3e15b4a by Steve Dower in branch '3.6':
[3.6] bpo-32588 Move _distutils_findvs into its own module (GH-5227) (#5228)
https://github.com/python/cpython/commit/ccf7f05c5d3fdea89d857e775d2c6371f3e15b4a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Thu Jan 18 17:10:24 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 18 Jan 2018 22:10:24 +0000
Subject: [issue32588] Move _findvs into its own extension module
In-Reply-To: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>
Message-ID: <1516313424.8.0.467229070634.issue32588@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Thu Jan 18 18:39:01 2018
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 18 Jan 2018 23:39:01 +0000
Subject: [issue31801] vars() manipulation encounters problems with Enum
In-Reply-To: <1508199715.37.0.213398074469.issue31801@psf.upfronthosting.co.za>
Message-ID: <1516318741.2.0.467229070634.issue31801@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +5083
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31801>
_______________________________________

From report at bugs.python.org  Thu Jan 18 18:46:49 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 18 Jan 2018 23:46:49 +0000
Subject: [issue32586] urllib2 HOWTO URLError example minor error
In-Reply-To: <1516212055.1.0.467229070634.issue32586@psf.upfronthosting.co.za>
Message-ID: <1516319209.34.0.467229070634.issue32586@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +5084
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32586>
_______________________________________

From report at bugs.python.org  Thu Jan 18 18:49:56 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 18 Jan 2018 23:49:56 +0000
Subject: [issue32586] urllib2 HOWTO URLError example minor error
In-Reply-To: <1516212055.1.0.467229070634.issue32586@psf.upfronthosting.co.za>
Message-ID: <1516319396.45.0.467229070634.issue32586@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks for reporting this issue. Indeed, this is an error in the documentation. Notice that this is corrected in Python3 's version:

https://docs.python.org/3.6/howto/urllib2.html#handling-exceptions

I have prepared a Pull Request fixing this. Thanks!

----------
nosy: +pablogsal
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32586>
_______________________________________

From report at bugs.python.org  Thu Jan 18 18:59:20 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 18 Jan 2018 23:59:20 +0000
Subject: [issue32532] improve sys.settrace and sys.setprofile documentation
In-Reply-To: <1515651956.68.0.467229070634.issue32532@psf.upfronthosting.co.za>
Message-ID: <1516319960.25.0.467229070634.issue32532@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

There are some issues in the documentation for this function (slightly related) to this described here: https://bugs.python.org/issue17799. 

I can update the PR linked to that issue with this information as well.

----------
nosy: +pablogsal
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32532>
_______________________________________

From report at bugs.python.org  Thu Jan 18 19:16:15 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 19 Jan 2018 00:16:15 +0000
Subject: [issue32586] urllib2 HOWTO URLError example minor error
In-Reply-To: <1516212055.1.0.467229070634.issue32586@psf.upfronthosting.co.za>
Message-ID: <1516320975.89.0.467229070634.issue32586@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 8ca036d4716fc86ff42474ba35d3cd32f0188a15 by Mariatta (Pablo Galindo) in branch '2.7':
bpo-32586: Fix code example in urllib2's doc  (GH-5238)
https://github.com/python/cpython/commit/8ca036d4716fc86ff42474ba35d3cd32f0188a15


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32586>
_______________________________________

From report at bugs.python.org  Thu Jan 18 19:19:23 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 19 Jan 2018 00:19:23 +0000
Subject: [issue32586] urllib2 HOWTO URLError example minor error
In-Reply-To: <1516212055.1.0.467229070634.issue32586@psf.upfronthosting.co.za>
Message-ID: <1516321163.21.0.467229070634.issue32586@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32586>
_______________________________________

From report at bugs.python.org  Thu Jan 18 19:32:02 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 19 Jan 2018 00:32:02 +0000
Subject: [issue32537] multiprocessing.pool.Pool.starmap_async - wrong
 parameter name
In-Reply-To: <1515767877.08.0.467229070634.issue32537@psf.upfronthosting.co.za>
Message-ID: <1516321922.08.0.467229070634.issue32537@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Closed as is a duplicate of 31304. Thanks for reporting this!

----------
nosy: +pablogsal
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Update doc for starmap_async error_back kwarg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32537>
_______________________________________

From report at bugs.python.org  Thu Jan 18 19:43:54 2018
From: report at bugs.python.org (MarmiteFox)
Date: Fri, 19 Jan 2018 00:43:54 +0000
Subject: [issue32586] urllib2 HOWTO URLError example minor error
In-Reply-To: <1516212055.1.0.467229070634.issue32586@psf.upfronthosting.co.za>
Message-ID: <1516322634.5.0.467229070634.issue32586@psf.upfronthosting.co.za>


MarmiteFox <timothy at morrises.org.uk> added the comment:

Thanks for the fix and the tip about cross-checking in Python 3 - will remember that for the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32586>
_______________________________________

From report at bugs.python.org  Thu Jan 18 19:50:33 2018
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 19 Jan 2018 00:50:33 +0000
Subject: [issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
In-Reply-To: <1516212552.32.0.467229070634.issue32587@psf.upfronthosting.co.za>
Message-ID: <1516323033.1.0.467229070634.issue32587@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Currently countStrings and fixupMultiSZ halt the outer loop as soon as they hit an empty string. Basically, we'd be getting rid of that check. Then we have to prevent including an empty string for the final NUL in the normal case. We can do this by decrementing the length by 1 if the data ends on a NUL. We also need a check in the inner loop of fixupMultiSZ to ensure it doesn't get out of bounds. 

Example:

    static void
    fixupMultiSZ(wchar_t **str, wchar_t *data, int len)
    {
        int i;
        wchar_t *P, *Q;

        if (len > 0 && data[len - 1] == '\0') {
            Q = data + len - 1;
        } else {
            Q = data + len;
        }

        for (P = data, i = 0; P < Q; P++, i++) {
            str[i] = P;
            for(; P < Q && *P != '\0'; P++)
                ;
        }
    }

    static int
    countStrings(wchar_t *data, int len)
    {
        int strings;
        wchar_t *P, *Q;

        if (len > 0 && data[len - 1] == '\0') {
            Q = data + len - 1;
        } else {
            Q = data + len;
        }

        for (P = data, strings = 0; P < Q; P++, strings++) {
            for (; P < Q && *P != '\0'; P++)
                ;
        }
        return strings;
    }

Also, the REG_MULTI_SZ case in Reg2Py should use wcsnlen instead of wcslen, in case of malformed data that doesn't end on at least one NUL character. The upper limit would be the remaining length.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32587>
_______________________________________

From report at bugs.python.org  Thu Jan 18 20:02:06 2018
From: report at bugs.python.org (Jesse Bakker)
Date: Fri, 19 Jan 2018 01:02:06 +0000
Subject: [issue29564] ResourceWarning: suggest to enable tracemalloc in the
 message
In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za>
Message-ID: <1516323726.94.0.467229070634.issue29564@psf.upfronthosting.co.za>


Change by Jesse Bakker <jessebakker00 at gmail.com>:


----------
nosy: +Jesse Bakker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29564>
_______________________________________

From report at bugs.python.org  Thu Jan 18 20:10:30 2018
From: report at bugs.python.org (Jesse Bakker)
Date: Fri, 19 Jan 2018 01:10:30 +0000
Subject: [issue32534] Speed-up list.insert: use memmove()
In-Reply-To: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>
Message-ID: <1516324230.18.0.467229070634.issue32534@psf.upfronthosting.co.za>


Change by Jesse Bakker <jessebakker00 at gmail.com>:


----------
nosy: +Jesse Bakker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Thu Jan 18 20:55:30 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 19 Jan 2018 01:55:30 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1516326930.46.0.467229070634.issue31368@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +5085
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Thu Jan 18 22:05:03 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Fri, 19 Jan 2018 03:05:03 +0000
Subject: [issue32578] x86-64 Sierra 3.6: test_asyncio fails with timeout after
 15 minutes
In-Reply-To: <1516185126.6.0.467229070634.issue32578@psf.upfronthosting.co.za>
Message-ID: <1516331103.96.0.467229070634.issue32578@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

Think I am also seeing this, MacOS 10.13.2, making 3.6.4 from source test_asyncio hangs indefinitely.

I killed it after 2 hours this morning, last output was: `running: test_asyncio (9481 sec)`

----------
nosy: +n8henrie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32578>
_______________________________________

From report at bugs.python.org  Fri Jan 19 02:18:03 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 19 Jan 2018 07:18:03 +0000
Subject: [issue31848] "aifc" module does not always initialize
 "Aifc_read._ssnd_chunk"
In-Reply-To: <1508765581.06.0.213398074469.issue31848@psf.upfronthosting.co.za>
Message-ID: <1516346283.62.0.467229070634.issue31848@psf.upfronthosting.co.za>


Change by Zackery Spytz <Osmunda46 at gmail.com>:


----------
keywords: +patch
pull_requests: +5086
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31848>
_______________________________________

From report at bugs.python.org  Fri Jan 19 02:55:42 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 19 Jan 2018 07:55:42 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516348542.56.0.467229070634.issue32591@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> I'm not sure how exactly the warning print logic will work with a list of tuples in cr_origin, I propose to start working on the implementation and figure that out during the review process.

I think the simplest thing is probably to write the warning code in Python and stash it in Lib/_corohelper.py or something. Warnings already go through warnings.py (in particular, the warning printing code is still warnings.showwarning, it's never been rewritten in C), so we're already transitioning to Python at this stage anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 19 04:08:46 2018
From: report at bugs.python.org (Jonathan)
Date: Fri, 19 Jan 2018 09:08:46 +0000
Subject: [issue32595] Deque with iterable object as one object
In-Reply-To: <1516307269.36.0.467229070634.issue32595@psf.upfronthosting.co.za>
Message-ID: <CA+imcT--Za3VdLc9s+=Bxcdkf6waHuDW79MQ6tjdCxfU1hJA-A@mail.gmail.com>


Jonathan <qjonathandaniel at gmail.com> added the comment:

Hello,

I dont know why but yesterday when i appended it behaved like extend.
I should sleep more.

2018-01-18 20:27 GMT+00:00 Raymond Hettinger <report at bugs.python.org>:

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> Sorry Jonathan, this is the way the python containers work if they take an
> iterable input.  In the case of a str, it is not possible for us to know
> whether you mean for deque('abc') to go it as three arguments or as one.
>
> FWIW, if you don't what to put the single element in a list, the API
> provides the append() method for adding scalars and extend() method for
> adding iterables:
>
>    d = deque()
>    d.append('abc')
>    d.extend('abc')
>
> Note that lists behave the same way.
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32595>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32595>
_______________________________________

From report at bugs.python.org  Fri Jan 19 04:21:03 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 19 Jan 2018 09:21:03 +0000
Subject: [issue32551] Zipfile & directory execution in 3.5.4 also adds the
 parent directory to sys.path
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516353663.5.0.467229070634.issue32551@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

If you're certain it isn't a security bug, then please downgrade it from release blocker.

I might permit a fix for it in 3.5.5 anyway, depending on how small it is, because nobody likes regressions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Fri Jan 19 05:29:08 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 19 Jan 2018 10:29:08 +0000
Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__
In-Reply-To: <1512866356.6.0.213398074469.issue32225@psf.upfronthosting.co.za>
Message-ID: <1516357748.87.0.467229070634.issue32225@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I didn't notice this is implemented.
Congrats, Ivan!

BTW, would you update the PEP status to Final?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32225>
_______________________________________

From report at bugs.python.org  Fri Jan 19 05:54:10 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 19 Jan 2018 10:54:10 +0000
Subject: [issue32596] Lazy import concurrent.futures.process and thread
Message-ID: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

Since PEP 562 is implemented, we can use lazy imports easily.

Asyncio uses concurrent.futures.Future and concurrent.futures.ThreadPoolExecutor,
but not concurrent.futures.ProcessPoolExecutor by default.

Since importing concurrent.futures.process is slow, I want to import it lazily.
And it make sense to import concurrent.futures.thread too, because it's very
easy when we start to use __getattr__ once.

Here is quick benchmark:


$ ./python -m perf command ./python -c 'import asyncio'  # patched
.....................
command: Mean +- std dev: 60.5 ms +- 0.1 ms
$ git stash
$ ./python -m perf command ./python -c 'import asyncio'  # original
.....................
command: Mean +- std dev: 74.3 ms +- 0.2 ms

----------
components: Library (Lib)
messages: 310272
nosy: inada.naoki, levkivskyi, yselivanov
priority: normal
severity: normal
status: open
title: Lazy import concurrent.futures.process and thread
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Fri Jan 19 06:00:48 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 19 Jan 2018 11:00:48 +0000
Subject: [issue32596] Lazy import concurrent.futures.process and thread
In-Reply-To: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>
Message-ID: <1516359648.16.0.467229070634.issue32596@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +5087
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Fri Jan 19 06:03:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Jan 2018 11:03:20 +0000
Subject: [issue32578] x86-64 Sierra 3.6: test_asyncio fails with timeout after
 15 minutes
In-Reply-To: <1516185126.6.0.467229070634.issue32578@psf.upfronthosting.co.za>
Message-ID: <1516359800.14.0.467229070634.issue32578@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh wait, this issue is just a duplicate of bpo-32517.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32578>
_______________________________________

From report at bugs.python.org  Fri Jan 19 06:03:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Jan 2018 11:03:36 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on macOS
 10.13.2 (darwin 17.3.0)
In-Reply-To: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>
Message-ID: <1516359816.88.0.467229070634.issue32517@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

bpo-32578 has been marked as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Fri Jan 19 07:37:54 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 19 Jan 2018 12:37:54 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516365474.8.0.467229070634.issue32410@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +5088

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:10:15 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 19 Jan 2018 13:10:15 +0000
Subject: [issue32311] Implement asyncio.create_task() shortcut
In-Reply-To: <1513273884.42.0.213398074469.issue32311@psf.upfronthosting.co.za>
Message-ID: <1516367415.36.0.467229070634.issue32311@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +5089

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32311>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:15:32 2018
From: report at bugs.python.org (bapt)
Date: Fri, 19 Jan 2018 13:15:32 +0000
Subject: [issue32597] Bad detection of clang
Message-ID: <1516367732.86.0.467229070634.issue32597@psf.upfronthosting.co.za>


New submission from bapt <bapt at FreeBSD.org>:

When building modules and trying to set the proper linker flags for the library runtime path, the detection of the compiler is wrong. the issue: 
https://bugs.python.org/issue20767 was showing the issue and imho badly fixed.

Clang behave like gcc regarding how it passes flags to the linker: -Wl,... so clang and gcc should be treated exactly the same way and no specific code should be added for FreeBSD

Here https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L237, it should accept both clang and gcc,

This block https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L230 should be removed

The issue is not only on FreeBSD but on any system which compiler is clang. side note, the detection of gcc looks at first glance wrong, as on many system gcc is installed as cc sometime.

----------
components: Distutils
messages: 310275
nosy: bapt, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Bad detection of clang
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32597>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:16:33 2018
From: report at bugs.python.org (bapt)
Date: Fri, 19 Jan 2018 13:16:33 +0000
Subject: [issue32597] Bad detection of clang
In-Reply-To: <1516367732.86.0.467229070634.issue32597@psf.upfronthosting.co.za>
Message-ID: <1516367793.58.0.467229070634.issue32597@psf.upfronthosting.co.za>


Change by bapt <bapt at FreeBSD.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32597>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:45:57 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Fri, 19 Jan 2018 13:45:57 +0000
Subject: [issue32517] test_read_pty_output() of test_asyncio hangs on macOS
 10.13.2 (darwin 17.3.0)
In-Reply-To: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>
Message-ID: <1516369557.95.0.467229070634.issue32517@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

I can reproduce on my local machine.

MacOS 10.13.2, trying to build 3.6.4. Waited for up to 6 hours for it to fail or finish, never does, just hangs at `test_asyncio`.

----------
nosy: +n8henrie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:48:26 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Jan 2018 13:48:26 +0000
Subject: [issue32598] Use autoconf to detect OpenSSL and libssl features
Message-ID: <1516369706.4.0.467229070634.issue32598@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Starting with #31399 Python will require some OpenSSL 1.0.2 features. The features are not available in LibreSSL yet. There is no easy way to detect the feature from setup.py. The inc_dir variable in setup.py does not reflect CPPFLAG. I tried "self.compiler.preprocess()" but run into more issues. For example prints to stderr in error cases.

https://www.gnu.org/software/autoconf-archive/ax_check_openssl.html makes it easy to check for working OpenSSL. It uses either pkg-config or falls back to manual detection in common locations.

Based on the M4 macro it is easy to check for features like working X509_VERIFY_PARAM_set1_host() function.

----------
components: Extension Modules, Installation
messages: 310277
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Use autoconf to detect OpenSSL and libssl features
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32598>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:52:19 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Jan 2018 13:52:19 +0000
Subject: [issue32598] Use autoconf to detect OpenSSL and libssl features
In-Reply-To: <1516369706.4.0.467229070634.issue32598@psf.upfronthosting.co.za>
Message-ID: <1516369939.46.0.467229070634.issue32598@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +5090
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32598>
_______________________________________

From report at bugs.python.org  Fri Jan 19 09:07:11 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 19 Jan 2018 14:07:11 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516370831.63.0.467229070634.issue32410@psf.upfronthosting.co.za>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Fri Jan 19 12:39:36 2018
From: report at bugs.python.org (Frank Ch. Eigler)
Date: Fri, 19 Jan 2018 17:39:36 +0000
Subject: [issue32599] Add dtrace hook for PyCFunction_Call
Message-ID: <1516383576.04.0.467229070634.issue32599@psf.upfronthosting.co.za>


New submission from Frank Ch. Eigler <fche at elastic.org>:

Similar to https://bugs.python.org/issue31574, it would be useful the the interpreter allowed a tracing tool to hook the PyCFunction_Call() site, maybe via the C_TRACE() macro, kind of how it already does in  _PyEval_EvalFrameDefault().  This would help diagnose problems in the C upcalls.

----------
components: Interpreter Core
messages: 310278
nosy: fche
priority: normal
severity: normal
status: open
title: Add dtrace hook for PyCFunction_Call
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32599>
_______________________________________

From report at bugs.python.org  Fri Jan 19 13:04:31 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 19 Jan 2018 18:04:31 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516385071.18.0.467229070634.issue32410@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 7464e87a6511d3626b04c9833a262a77b1f21e23 by Andrew Svetlov in branch 'master':
bpo-32410: Make SendfileNotAvailableError exception public (#5243)
https://github.com/python/cpython/commit/7464e87a6511d3626b04c9833a262a77b1f21e23


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Fri Jan 19 13:06:38 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 19 Jan 2018 18:06:38 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516385198.8.0.467229070634.issue32410@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Fri Jan 19 13:12:22 2018
From: report at bugs.python.org (Sylvain Marie)
Date: Fri, 19 Jan 2018 18:12:22 +0000
Subject: [issue32590] Proposal: add an "ensure(arg)" builtin for parameter
 validation
In-Reply-To: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>
Message-ID: <1516385542.88.0.467229070634.issue32590@psf.upfronthosting.co.za>


Sylvain Marie <sylvain.marie at schneider-electric.com> added the comment:

Very much interested by the topic.

For reference I tried to summarize the status of inline type and value validation here: https://smarie.github.io/python-valid8/why_validation/

And I proposed a solution with a library here https://smarie.github.io/python-valid8 (with a somewhat smart handling of the ValueError / TypeError inheritance dilemma, for what's worth)

----------
nosy: +smarie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Fri Jan 19 13:31:53 2018
From: report at bugs.python.org (Greg Matous)
Date: Fri, 19 Jan 2018 18:31:53 +0000
Subject: [issue32600] SpooledTemporaryFile should implement IOBase
Message-ID: <1516386713.77.0.467229070634.issue32600@psf.upfronthosting.co.za>


New submission from Greg Matous <gregory.matous at gmail.com>:

SpooledTemporaryFile returns alternately a buffer or a TemporaryFile().

In either case it should behave like a file-thing.
However it doesn't implement certain properties in IOBase like readable, seekable which seems like should be available.

for example, on Ubuntu Linux with Python 3.6.2, 

reader = csv.reader(TextIOWrapper(csvfile), *args, **kwargs)

gives error AttributeError: 'SpooledTemporaryFile' object has no attribute 'readable'
when csvfile is a werkzeug.datastructures.FileStorage object

see also:
https://stackoverflow.com/questions/47160211/why-doesnt-tempfile-spooledtemporaryfile-implement-readable-writable-seekable

----------
components: Library (Lib)
messages: 310281
nosy: dutchmo
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile should implement IOBase
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32600>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:31:36 2018
From: report at bugs.python.org (Anders Kaseorg)
Date: Fri, 19 Jan 2018 19:31:36 +0000
Subject: [issue32601] PosixPathTest.test_expanduser fails in NixOS build
 sandbox
Message-ID: <1516390296.8.0.467229070634.issue32601@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

PosixPathTest.test_expanduser fails in the NixOS build sandbox, where every user has home directory /, so it falls off the end of the for pwdent in pwd.getpwall() loop.

nixbld:x:30001:30000:Nix build user:/:/noshell
nobody:x:65534:65534:Nobody:/:/noshell

======================================================================
FAIL: test_expanduser (__main__.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nix/store/mdak9gcy16dc536ws08rshyakd1l7srj-test_pathlib.py", line 2162, in test_expanduser
    self.assertEqual(p3.expanduser(), P(otherhome) / 'Documents')
AssertionError: PosixPath('/Documents') != PosixPath('Documents')

----------
components: Tests
messages: 310282
nosy: andersk
priority: normal
pull_requests: 5091
severity: normal
status: open
title: PosixPathTest.test_expanduser fails in NixOS build sandbox
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32601>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:36:45 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Jan 2018 19:36:45 +0000
Subject: [issue32601] PosixPathTest.test_expanduser fails in NixOS build
 sandbox
In-Reply-To: <1516390296.8.0.467229070634.issue32601@psf.upfronthosting.co.za>
Message-ID: <1516390605.31.0.467229070634.issue32601@psf.upfronthosting.co.za>


Change by R. David Murray <rdmurray at bitdance.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32601>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:45:40 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 19:45:40 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1516391140.73.0.467229070634.issue32545@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"Other installers work without issue?"  Is this a comment about other installers for other versions on your machine?  Or a question about other people using the same binary on other machines?

Using the same python-3.7.0a4-amd64.exe binary, I successfully upgraded an existing 3.7.0a3 all-users installation in a custom C: directory on Win-10/64.  If I read the log correctly, you tried a single user installation in the standard location.

The first error indication I see in the log is this line:
MSI (s) (BC:04) [20:15:48:208]: Note: 1: 2205 2:  3: Error 

'Error 0x80070643' is a generic installation failure that can occur either during Windows update or 3rd party program installation.  I searched and one of the top hits was
  https://www.drivereasy.com/knowledge/fix-error-0x80070643-on-windows/
You could try the 3 generic suggestions under
  2) Fix the 0x80070643 error during a program installation
(The first is restart your machine, if you have not already.)
You could also run the system scan described in section '1)'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:46:32 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Jan 2018 19:46:32 +0000
Subject: [issue32602] Test ECDSA and dual mode context
Message-ID: <1516391192.37.0.467229070634.issue32602@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

OpenSSL supports ECDSA certs and dual EC/RSA mode context, e.g. a context a RSA and an ECDSA key/cert pair loaded at the same time. Python shoulkd verify that ECDSA certs are working properly.

----------
assignee: christian.heimes
components: SSL, Tests
messages: 310284
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Test ECDSA and dual mode context
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32602>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:49:23 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Jan 2018 19:49:23 +0000
Subject: [issue32602] Test ECDSA and dual mode context
In-Reply-To: <1516391192.37.0.467229070634.issue32602@psf.upfronthosting.co.za>
Message-ID: <1516391363.39.0.467229070634.issue32602@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +5092
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32602>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:56:08 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 19:56:08 +0000
Subject: [issue32553] venv says to use python3 which does not exist in 3.6.4
In-Reply-To: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>
Message-ID: <1516391768.79.0.467229070634.issue32553@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As far as I know, Windows binaries have only been named python.exe or pythonw.exe.  Before 3.5, I believe, "C:\Pythonxy", where x,y were major,minor, *was* the default Windows installation directory.  'Python35' must have been the result of a mechanical update.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Fri Jan 19 15:04:41 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 20:04:41 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1516392281.29.0.467229070634.issue32557@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Seems sensible to me.

----------
nosy: +terry.reedy
title: allow shutil.disk_usage to take a file path -> allow shutil.disk_usage to take a file path on Windows also

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Fri Jan 19 15:18:51 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 20:18:51 +0000
Subject: [issue32566] Not able to run Python 3.6 on Windows
In-Reply-To: <1516095028.12.0.467229070634.issue32566@psf.upfronthosting.co.za>
Message-ID: <1516393131.67.0.467229070634.issue32566@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Not able to open Python IDLE -> Not able to run Python 3.6 on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32566>
_______________________________________

From report at bugs.python.org  Fri Jan 19 15:25:12 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 20:25:12 +0000
Subject: =?utf-8?q?=5Bissue32567=5D_Venv=E2=80=99s_config_file_=28pyvenv=2Ecfg=29_?=
 =?utf-8?q?should_be_compatible_with_ConfigParser?=
In-Reply-To: <1516099456.9.0.467229070634.issue32567@psf.upfronthosting.co.za>
Message-ID: <1516393512.7.0.467229070634.issue32567@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +vinay.sajip
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32567>
_______________________________________

From report at bugs.python.org  Fri Jan 19 15:29:37 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 20:29:37 +0000
Subject: [issue32572] Add the ftplib option, overrides the IP address.
In-Reply-To: <1516128378.06.0.467229070634.issue32572@psf.upfronthosting.co.za>
Message-ID: <1516393777.75.0.467229070634.issue32572@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +giampaolo.rodola
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32572>
_______________________________________

From report at bugs.python.org  Fri Jan 19 15:51:37 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 20:51:37 +0000
Subject: [issue32573] All sys attributes (.argv,
 ...) should exist in embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516395097.76.0.467229070634.issue32573@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Pedro: David and Nick are proposing initializing sys.argv to [] rather than [''] for embedded interpreters.  This would say 'running embedded'.  The .argv entry would need an additional sentence.

I like Nick's proposal, except that _xoptions should be {}.  Documenting absence should only be a fallback is there is no sensible default.

----------
components: +Library (Lib) -Documentation
nosy: +terry.reedy
title: sys.argv documentation should include caveat for embedded environments -> All sys attributes (.argv, ...) should exist in embedded environments
versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Fri Jan 19 16:10:11 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 21:10:11 +0000
Subject: [issue32582] chr raises OverflowError
In-Reply-To: <1516199526.4.0.467229070634.issue32582@psf.upfronthosting.co.za>
Message-ID: <1516396211.16.0.467229070634.issue32582@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The message I get on Windows is 
OverflowError: Python int too large to convert to C long

Given that the exception type is documented, making this a clear bug, I would be tempted to fix in 3.6 also.  But your decision.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32582>
_______________________________________

From report at bugs.python.org  Fri Jan 19 16:37:09 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 21:37:09 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1516397829.59.0.467229070634.issue32583@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As written, decode_crash.py crashes on Windows also.  Passing 'replace' instead of 'w3lib_replace' results in no crash and lots of boxes and blanks.

----------
nosy: +benjamin.peterson, ezio.melotti, lemburg, terry.reedy, vstinner
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Fri Jan 19 16:45:34 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Jan 2018 21:45:34 +0000
Subject: [issue32600] SpooledTemporaryFile should implement IOBase
In-Reply-To: <1516386713.77.0.467229070634.issue32600@psf.upfronthosting.co.za>
Message-ID: <1516398334.54.0.467229070634.issue32600@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

There is apparently some work done on this already in Issue 26175.

----------
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Fully implement IOBase abstract on SpooledTemporaryFile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32600>
_______________________________________

From report at bugs.python.org  Fri Jan 19 16:50:02 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 19 Jan 2018 21:50:02 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1516398602.65.0.467229070634.issue32550@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I won't object. It makes sense that the implementation of __annotations__ should be low-key.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:08:26 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 19 Jan 2018 22:08:26 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516399706.71.0.467229070634.issue29708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Since Barry chose an option that wasn't listed, I'm planning on accepting Bernhard's https://github.com/python/cpython/pull/5200 at some point next week barring any new, unique objections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:08:55 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 22:08:55 +0000
Subject: [issue32585] Add ttk::spinbox to tkinter.ttk
In-Reply-To: <1516209431.55.0.467229070634.issue32585@psf.upfronthosting.co.za>
Message-ID: <1516399734.99.0.467229070634.issue32585@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As said in review, I would like to see this added unless there is a good reason for the omission. Still needed are patches for doc and tests.

----------
nosy: +serhiy.storchaka, terry.reedy
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32585>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:18:05 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 22:18:05 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516400285.98.0.467229070634.issue32589@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am also skeptical that this will do more good than harm (by adding time and fostering mis-impressions).  (This might better have started as a discussion on python-ideas list.)

----------
nosy: +terry.reedy, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:25:49 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 22:25:49 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516400749.33.0.467229070634.issue32592@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe that PEP 11 originally said, or should have said "3.6 supports Windows Vista and newer."  I believe 3.5 supports XP, so it should be "please install Python 3.4".

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:26:15 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 22:26:15 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516400775.03.0.467229070634.issue32592@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: https://bugs.python.org/msg310295

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:26:28 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jan 2018 22:26:28 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516400788.66.0.467229070634.issue32592@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe that PEP 11 originally said, or should have said "3.6 supports Windows Vista and newer."  I believe 3.5 supports XP, so it should be "please install Python 3.5".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:29:19 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 19 Jan 2018 22:29:19 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516400959.59.0.467229070634.issue32592@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

3.4 was the last version to support XP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Fri Jan 19 17:59:40 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Jan 2018 22:59:40 +0000
Subject: [issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
In-Reply-To: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>
Message-ID: <1516402780.63.0.467229070634.issue26175@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

It may also be worth implementing BufferedIOBase and TextIOBase. (It seems buffering=0 isn?t reliable, e.g. rollover with limited disk space, so it may not be worth implementing RawIOBase.)

To implement BufferedIOBase, ?read1? and ?readinto1? should be added.

To implement TextIOBase, ?errors? should be added, and ?newlines? should only list translated newlines, not the ?newline? constructor argument.

Technically, ?detach? should also be implemented, although it doesn?t have to do anything useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26175>
_______________________________________

From report at bugs.python.org  Fri Jan 19 18:05:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 19 Jan 2018 23:05:59 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516403159.03.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I think the simplest thing is probably to write the warning code in Python and stash it in Lib/_corohelper.py or something.

I'd put the helper that accepts a list of traceback-like tuples and emits a warning in warnings.py and a C function to call it in warnings.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 19 18:19:24 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 19 Jan 2018 23:19:24 +0000
Subject: [issue32599] Add dtrace hook for PyCFunction_Call
In-Reply-To: <1516383576.04.0.467229070634.issue32599@psf.upfronthosting.co.za>
Message-ID: <1516403964.88.0.467229070634.issue32599@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32599>
_______________________________________

From report at bugs.python.org  Fri Jan 19 18:20:51 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 19 Jan 2018 23:20:51 +0000
Subject: [issue32603] Deprecation warning on strings used in re module
Message-ID: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

I apologize if this is a duplicate question, but I couldn't find another issue about this.  It's hard to search on 're'.

In 3.7, I get a deprecation warning when using a regular string with re escape characters:
>>> s = '123abcd'
>>> re.findall('\d', s)
<stdin>:1: DeprecationWarning: invalid escape sequence \d
['1', '2', '3']

Of course, this works:
>>> s = '123abcd'
>>> re.findall(r'\d', s)
['1', '2', '3']


I know that the documentation strongly suggests using raw strings with re, but I didn't see anywhere mentioning that it would be a requirement.  I would think this would break a lot of 're' code.

----------
assignee: docs at python
components: Documentation
messages: 310300
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Deprecation warning on strings used in re module
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Fri Jan 19 18:29:30 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 19 Jan 2018 23:29:30 +0000
Subject: [issue32603] Deprecation warning on strings used in re module
In-Reply-To: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>
Message-ID: <1516404570.65.0.467229070634.issue32603@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This is actually combination of a deprecation in in 3.6's string literals (not related to the re module), documented here: https://docs.python.org/dev/whatsnew/3.6.html#deprecated-python-behavior (see issue27364) and showing DeprecationWarning in the REPL by default in 3.7 (PEP 565).

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Fri Jan 19 18:48:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Jan 2018 23:48:46 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516405726.27.0.467229070634.issue32589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I suggest you to take a look at my perf project which has a timeit function and command. perf has a different design: it stores all values, and so many statisticals functions can be used. By the way, it does include most common statistical functions in its API, and provide a few more in the CLI.

The timeit module of the stdlib computes 5 values by default... I'm not sure that it's revelant to compute the standard deviation only on 5 values. perf computes 60 values and computes then in 20 different processes (run sequentially). With 60 values, I expect that the computing statistics makes more sense.

About the PR itself, I dislike providing a fixed list of statistical functions. For example, what if someone needs the geometric mean? What if you want to count outliers? etc.

If someone really wants timeit to evolve, I suggest to return all values rather than only the minimum: as repeat() does.

By the way, using the minimum is IMHO a bad idea, but I already proposed to change timeit, and my change was rejected because of the backward compatibility.

I decided to stop trying to convince other core developers and leave the timeit module unchanged, with all its bugs. And instead, I suggest to everyone to stop using it (PyPy also warns users and asks to use perf instead), and use perf timeit instead...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Fri Jan 19 18:50:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Jan 2018 23:50:30 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516405830.34.0.467229070634.issue32592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Terry: see my notes about platforms suported by Python.
http://vstinner.readthedocs.io/cpython.html#supported-platforms

The PEP 11 doesn't want to have an explicit list of supported Windows versions, but I'm unable to *guess* which Windows version is supported by which Python version, so I wrote my own doc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:06:06 2018
From: report at bugs.python.org (Pedro)
Date: Sat, 20 Jan 2018 00:06:06 +0000
Subject: [issue32573] All sys attributes (.argv,
 ...) should exist in embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516406766.27.0.467229070634.issue32573@psf.upfronthosting.co.za>


Pedro <pgacv2+pythonbugs at gmail.com> added the comment:

I agree that an empty list, instead of a list with an empty string, makes more sense. Leaving _xoptions as {} would be the same as when it runs non-embedded without any -X arguments, but I guess there's no way of making {} any more empty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:11:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 00:11:57 +0000
Subject: [issue32573] All sys attributes (.argv,
 ...) should exist in embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516407117.8.0.467229070634.issue32573@psf.upfronthosting.co.za>


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


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:22:24 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 20 Jan 2018 00:22:24 +0000
Subject: [issue32603] Deprecation warning on strings used in re module
In-Reply-To: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>
Message-ID: <1516407744.09.0.467229070634.issue32603@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Thank you, Zach.

There was some mention of regular expressions in #27364, but I'm still wondering if the DeprecationWarning should be mentioned on the re doc page and if there should be stronger language about using raw strings.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:25:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 00:25:39 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516407939.68.0.467229070634.issue25910@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 338cd83c5dceaed785f5bf613e2122f871908e2a by Victor Stinner (Sanyam Khurana) in branch 'master':
bpo-25910: Link redirections in docs (#1933)
https://github.com/python/cpython/commit/338cd83c5dceaed785f5bf613e2122f871908e2a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:29:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 00:29:37 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516408177.16.0.467229070634.issue25910@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Can we now close this old issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:35:15 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 20 Jan 2018 00:35:15 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516408515.16.0.467229070634.issue32248@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
pull_requests: +5093

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:45:54 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Jan 2018 00:45:54 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1516409154.44.0.467229070634.issue32592@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I personally think it was a mistake to stop being explicit about Windows support in PEP 11.  The rationale was to avoid having to update it.  But it is updated for other systems; an explicit list is needed somewhere (as illustrated by my memory lapse; and PEP 11 is the most obvious and discoverable place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:49:28 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Jan 2018 00:49:28 +0000
Subject: [issue32573] All sys attributes (.argv,
 ...) should exist in embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1516409368.62.0.467229070634.issue32573@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For detecting 'embedded', it is enough that only one documented attribute value be unique to embedded situations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Fri Jan 19 19:54:44 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 20 Jan 2018 00:54:44 +0000
Subject: [issue32596] Lazy import concurrent.futures.process and thread
In-Reply-To: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>
Message-ID: <1516409684.34.0.467229070634.issue32596@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 6690bb9f17d34eb3dec0aca8919d8d27d6c3c452 by INADA Naoki in branch 'master':
bpo-32596: Lazy import concurrent.futures.process and thread (GH-5241)
https://github.com/python/cpython/commit/6690bb9f17d34eb3dec0aca8919d8d27d6c3c452


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Fri Jan 19 20:00:49 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 01:00:49 +0000
Subject: [issue32429] Outdated Modules/Setup warning is invisible
In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za>
Message-ID: <1516410049.84.0.467229070634.issue32429@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I'm ok with turning the warning into an error. Does anyone object here?

Please don't convert the warning to an error. Usually, I ignore the warning and "make" produces a working ./python binary anyway.

It's common that I get the warning when using git bisect, since it updates Modules/Setup.dist.

If you want to make it an error, I would prefer to have an option to "ignore the warning", like always copy Modules/Setup.dist to Modules/Setup (if it's detected as outdated).

I like Xavier's proposal (msg309078): only create Modules/Setup if you want to customize it, otherwise use Modules/Setup.dist. I *never* modified Modules/Setup, I don't even know its purpose, whereas it bugs me frequently with it's annoying warning...

It seems like I would prefer to see bpo-32430 fixed.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32429>
_______________________________________

From report at bugs.python.org  Fri Jan 19 20:07:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 01:07:18 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1516410438.52.0.467229070634.issue32430@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I like the idea of removing the Modules/Setup.dist => Modules/Setup copy which removes immediately the annoying warning (bpo-32429).

> ... that one can modify and commit

I'm not sure about the "commit" part. I see Modules/Setup as a configuration file. Python provides a default configuration, fine.

Why not adding an option in Makefile or configure to allow to specify a different path to a custom Setup file?

./configure --setup-file=google_uber_cool_setup_file && make

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Fri Jan 19 20:07:47 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 20 Jan 2018 01:07:47 +0000
Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__
In-Reply-To: <1512866356.6.0.213398074469.issue32225@psf.upfronthosting.co.za>
Message-ID: <1516410467.08.0.467229070634.issue32225@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> BTW, would you update the PEP status to Final?

Good point, here is the PR https://github.com/python/peps/pull/554

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32225>
_______________________________________

From report at bugs.python.org  Fri Jan 19 20:58:02 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 20 Jan 2018 01:58:02 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
Message-ID: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In the interest of getting something landed for 3.7, so we can start using it in tests, I'm putting up a patch for a low-level interpreters module.  In some ways this is a precursor for issue #30439, which will add a proper public stdlib module in 3.8.

The module I'm adding draws from the ideas in PEP 554 (particularly for channels).  Consequently, this will also give us an opportunity to try out some of the semantics from the PEP to give us better ideas for 3.8.

I expect to have some follow-on patches to facilitate simpler use in tests.  This patch is big enough already. :)

----------
assignee: eric.snow
components: Interpreter Core
messages: 310314
nosy: eric.snow, ncoghlan, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose the subinterpreters C-API in Python for testing use.
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Fri Jan 19 20:59:30 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 20 Jan 2018 01:59:30 +0000
Subject: [issue30439] Expose the subinterpreters C-API in the stdlib.
In-Reply-To: <1495517065.49.0.193361600538.issue30439@psf.upfronthosting.co.za>
Message-ID: <1516413570.59.0.467229070634.issue30439@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, I'm working on a low-level patch for use in the test suite for 3.7.  See issue #32604.

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30439>
_______________________________________

From report at bugs.python.org  Fri Jan 19 21:03:42 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 20 Jan 2018 02:03:42 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1516413822.5.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@Ned, it may be a little tight to land this given the time left before beta 1.  However, this is meant as a tool for us to use in the test suite (particularly to test the subinterpreter C-API).  So I'm arguing that, if necessary, it would still be okay to land this after the feature freeze.  (I'm still hoping to get this in before the cutoff.)  What do you think?

----------
nosy: +ned.deily, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Fri Jan 19 21:04:36 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 20 Jan 2018 02:04:36 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1516413876.56.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@Nick, I may make the name change you suggested in issue #30439 ("_subinterpreters").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Fri Jan 19 21:06:25 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 20 Jan 2018 02:06:25 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1516413985.06.0.467229070634.issue32604@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +5094
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Fri Jan 19 21:10:10 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 20 Jan 2018 02:10:10 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1516414210.92.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, there are a few things I need to clean up in the PR.  However, I expect that those changes will be minor relative to the the whole patch, so I wanted to get the ball rolling on a review. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Fri Jan 19 21:47:43 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Jan 2018 02:47:43 +0000
Subject: [issue32551] Zipfile & directory execution in 3.5.4 also adds the
 parent directory to sys.path
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516416463.36.0.467229070634.issue32551@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks Larry - I've reduced the priority accordingly.

While the NEWS entry sounds a bit complicated, the actual fix is nicely self-contained: it's all within Modules/main.c, and relates to how that manipulates sys.argv[0] during startup.

Historically, the code would put a potentially incorrect entry into sys.path[0], then amend it later (and that amendment step could sometimes do the wrong thing), but after this patch, it stores the candidate entry in a local C variable and adds it to the path only after it knows it's correct to do so.

The backport also comes with test cases to ensure everything's working as we expect, and this is the code that 3.6 has been using since its release.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Fri Jan 19 22:00:36 2018
From: report at bugs.python.org (Schmehl Bastian)
Date: Sat, 20 Jan 2018 03:00:36 +0000
Subject: [issue25910] How many "critical"-level open issues are there?
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516417236.43.0.467229070634.issue25910@psf.upfronthosting.co.za>


Change by Schmehl Bastian <Bastian.schmehl at web.de>:


----------
title: Fixing links in documentation -> How many "critical"-level open issues are there?
versions: +Python 2.7 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Fri Jan 19 22:12:24 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Jan 2018 03:12:24 +0000
Subject: [issue32028] Syntactically wrong suggestions by the new custom print
 statement error message
In-Reply-To: <1510681370.22.0.213398074469.issue32028@psf.upfronthosting.co.za>
Message-ID: <1516417944.89.0.467229070634.issue32028@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset d57f26c753dce61f72b52b96db3a3253d9f2fc3e by Nick Coghlan (Sanyam Khurana) in branch 'master':
bpo-32028: Fix suggestions for indented print statements (GH-4688)
https://github.com/python/cpython/commit/d57f26c753dce61f72b52b96db3a3253d9f2fc3e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32028>
_______________________________________

From report at bugs.python.org  Fri Jan 19 22:12:32 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Jan 2018 03:12:32 +0000
Subject: [issue32028] Syntactically wrong suggestions by the new custom print
 statement error message
In-Reply-To: <1510681370.22.0.213398074469.issue32028@psf.upfronthosting.co.za>
Message-ID: <1516417952.67.0.467229070634.issue32028@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5096

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32028>
_______________________________________

From report at bugs.python.org  Fri Jan 19 22:47:37 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 20 Jan 2018 03:47:37 +0000
Subject: [issue32596] Lazy import concurrent.futures.process and thread
In-Reply-To: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>
Message-ID: <1516420057.86.0.467229070634.issue32596@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Fri Jan 19 22:56:33 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Jan 2018 03:56:33 +0000
Subject: [issue32028] Syntactically wrong suggestions by the new custom print
 statement error message
In-Reply-To: <1510681370.22.0.213398074469.issue32028@psf.upfronthosting.co.za>
Message-ID: <1516420593.93.0.467229070634.issue32028@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 4002d5dbf4c058bbf2462f9f5dea057956d1caff by Nick Coghlan (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-32028: Fix suggestions for indented print statements (GH-5249)
https://github.com/python/cpython/commit/4002d5dbf4c058bbf2462f9f5dea057956d1caff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32028>
_______________________________________

From report at bugs.python.org  Fri Jan 19 22:57:45 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Jan 2018 03:57:45 +0000
Subject: [issue32028] Syntactically wrong suggestions by the new custom print
 statement error message
In-Reply-To: <1510681370.22.0.213398074469.issue32028@psf.upfronthosting.co.za>
Message-ID: <1516420665.65.0.467229070634.issue32028@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks CuriousLearner for the PR and mdraw for the original issue report!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32028>
_______________________________________

From report at bugs.python.org  Sat Jan 20 00:04:49 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 20 Jan 2018 05:04:49 +0000
Subject: [issue25910] How many "critical"-level open issues are there?
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516424689.72.0.467229070634.issue25910@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Who is Basti5611 (Schmehl Bastian), why do they have permission to change issue titles, and why did they change this issue title?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Jan 20 00:05:23 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 20 Jan 2018 05:05:23 +0000
Subject: [issue32603] Deprecation warning on strings used in re module
In-Reply-To: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>
Message-ID: <1516424723.04.0.467229070634.issue32603@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I agree with Cheryl that it would be a good idea to mention this change in the re docs, since regexes are especially likely to run into this issue.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Sat Jan 20 00:30:50 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 20 Jan 2018 05:30:50 +0000
Subject: [issue32605] Should we really hide unawaited coroutine warnings when
 an exception is pending?
Message-ID: <1516426250.01.0.467229070634.issue32605@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

There's a curious bit of code in genobject.c:_PyGen_Finalize:

        if (!error_value) {
            PyErr_WarnFormat(PyExc_RuntimeWarning, 1,
                             "coroutine '%.50S' was never awaited",
                             gen->gi_qualname);
        }

Obviously this is the code that issues "coroutine ... was never awaited" warnings. That's not so curious. What's curious is the 'if' statement: what it does is suppress this warning if -- at the moment the coroutine object was GCed -- there is an active exception propagating.

This was added by bpo-27968, apparently as a way to hide some warnings in test_coroutine.py. This justification seems dubious to me, though, and there doesn't seem to have been much/any scrutiny of this at the time. We can certainly write those tests more carefully, so that they don't issue warnings -- e.g. by using 'with closing(corofn()) as coro: ...'. And this has a much broader effect than on just those tests. For example, say we accidentally write:

   def foo():
       len(corofn())  # should be len(await corofn())

we'll get an error that was caused by the coroutine not being awaited -- and we *won't* get the usual warning message explaining this, because the coroutine object is GCed while the exception propagates. Or, if an unawaited coroutine happens to get stuck in a reference cycle, then it's a matter of luck whether the message gets printed, depending on when exactly the cycle collector happens to trigger.

I guess in most cases where someone forgets an await and it causes errors, the coroutine happens to get stashed into a local variable, so it can't be GCed until after the exception is no longer active. And if another exception becomes active in the mean time, probably it will capture the first one as __context__, so that also keeps the coroutine alive past the time when the warning would be suppressed. So maybe this isn't a huge issue in practice? But this all feels very finicky and accidental, so I wanted to raise the issue for discussion.

----------
components: asyncio
messages: 310325
nosy: asvetlov, benjamin.peterson, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: Should we really hide unawaited coroutine warnings when an exception is pending?
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32605>
_______________________________________

From report at bugs.python.org  Sat Jan 20 02:16:30 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Sat, 20 Jan 2018 07:16:30 +0000
Subject: [issue25910] How many "critical"-level open issues are there?
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516432590.47.0.467229070634.issue25910@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Victor, there is just one last thing to do in here.

All the links pointing to Github (that are build automatically) are permanently redirected from https://github.com/python/cpython/tree/master/* to https://github.com/python/cpython/blob/master/*

I will issue a separate PR for it, and then we're good to close this issue.

PS: Guido, I'm not sure about the title change either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Jan 20 02:20:47 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 20 Jan 2018 07:20:47 +0000
Subject: =?utf-8?q?=5Bissue32567=5D_Venv=E2=80=99s_config_file_=28pyvenv=2Ecfg=29_?=
 =?utf-8?q?should_be_compatible_with_ConfigParser?=
In-Reply-To: <1516099456.9.0.467229070634.issue32567@psf.upfronthosting.co.za>
Message-ID: <1516432847.71.0.467229070634.issue32567@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

"Seems wrong to me" is not a sufficient reason for changing things in this area. The pyvenv.cfg file is intended to be parsed by the interpreter's C code as well as by Python code, so its format needs to be kept as simple as possible.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32567>
_______________________________________

From report at bugs.python.org  Sat Jan 20 02:39:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 07:39:30 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516433970.7.0.467229070634.issue25910@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: How many "critical"-level open issues are there? -> Fixing links in documentation
versions: +Python 3.7 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Jan 20 02:42:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 07:42:13 +0000
Subject: [issue32585] Add ttk::spinbox to tkinter.ttk
In-Reply-To: <1516209431.55.0.467229070634.issue32585@psf.upfronthosting.co.za>
Message-ID: <1516434133.41.0.467229070634.issue32585@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Needed tests, documentation, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32585>
_______________________________________

From report at bugs.python.org  Sat Jan 20 02:49:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 07:49:50 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1516434590.8.0.467229070634.issue32550@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> This PR moves the constant for the name from `co_names` to `co_consts`. There is no duplication.

But if there is an initializer, the name is left in `co_names` too.

I don't think this (as well as possible performance difference) is important. My only concerns are about subtle behavior differences.

For example, is the name always interned (even if long or non-ASCII)? Does any code depend on interning keys in __annotations__? (There is a code that depends on interning keys in type.__dict__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sat Jan 20 03:04:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 08:04:04 +0000
Subject: [issue32582] chr raises OverflowError
In-Reply-To: <1516199526.4.0.467229070634.issue32582@psf.upfronthosting.co.za>
Message-ID: <1516435444.81.0.467229070634.issue32582@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Perhaps this issue should be raised on Python-Dev, since it changes the old and well-known behavior of buildins. I think that ValueError is more appropriate, but in past we decided to keep OverflowError for compatibility.

If change chr(), other code needs to be changed. "%c", PyUnicode_FromOrdinal(), PyUnicode_Format(), and possible the same for bytes.

See also issue29833 and issue15988.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32582>
_______________________________________

From report at bugs.python.org  Sat Jan 20 03:07:00 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 20 Jan 2018 08:07:00 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516405726.27.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <20180120080653.GN22500@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Fri, Jan 19, 2018 at 11:48:46PM +0000, STINNER Victor wrote:

> The timeit module of the stdlib computes 5 values by default... I'm 
> not sure that it's revelant to compute the standard deviation only on 
> 5 values.

I made the same mistake as that: I too thought Matthias was talking 
about calculating the statistics based on timer.repeat(), but after 
looking more closely at the PR, I see that the statistics gathered 
are from the (default) 1000000 runs of each call to timer.timeit().

(Matthias: in future, please don't just dump a PR into the bug tracker 
with barely a word of explanation. We shouldn't have to read the source 
to understand what it does, let alone why it is done. Thank you.)

Given that Mattias is calculating the stats of each call to timeit(), 
I'm not sure whether that makes more or less sense than what I thought.

His patch effectively converts timeit() to calculate the time for one 
run a million times, instead of the total time for one million runs. 
That is one of the traps that Tim Peters warns about in the O'Reilly 
book: timing *one* run may give unrealistic results due to the timer's 
quantization. So I think this will be much less accurate.

(Is this still true now that timeit() uses perf_counter() as the default 
timer, instead of clock() or time()? I don't know.)

> About the PR itself, I dislike providing a fixed list of statistical 
> functions. For example, what if someone needs the geometric mean? What 
> if you want to count outliers? etc.

I'm not sure that the geometric mean would be physically meaningful. But 
your point is well taken. For example, I think the median might be a 
better choice than mean -- but if some user disagrees, that's okay.

> If someone really wants timeit to evolve, I suggest to return all 
> values rather than only the minimum: as repeat() does.

timeit() doesn't return the minimum.

timeit() calculates the total time for `number` (default is 1000000) 
runs, and returns that total; repeat() calls timeit() `repeat` (default 
is 3, not 5) times and returns them as a list.

> By the way, using the minimum is IMHO a bad idea, but I already 
> proposed to change timeit, and my change was rejected because of the 
> backward compatibility.

I am interested in why you think it is a bad idea to use the minimum as 
the best estimate of the actual execution time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Sat Jan 20 03:48:50 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 20 Jan 2018 08:48:50 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516438130.71.0.467229070634.issue29708@psf.upfronthosting.co.za>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy:  -yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Sat Jan 20 03:57:26 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 20 Jan 2018 08:57:26 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516438646.56.0.467229070634.issue32591@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
keywords: +patch
pull_requests: +5097
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Sat Jan 20 04:01:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 09:01:58 +0000
Subject: [issue25910] How many "critical"-level open issues are there?
In-Reply-To: <1516432590.47.0.467229070634.issue25910@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbjT_C6jyCBcVKoFkLGGSoOvAe-+3+ubJvP-HLCKCPfcg@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

"I will issue a separate PR for it, and then we're good to close this
issue."

Ok.

----------
title: Fixing links in documentation -> How many "critical"-level open issues are there?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Jan 20 04:07:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 09:07:39 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <CAMpsgwYBYSWjMx=Af--gQX6vTNaV7fqoHpXqfqG6NUf8JVa68A@mail.gmail.com>
Message-ID: <CAMpsgwZ+rOQOG8fJwqD7ZvC0nYNtrsmgQnSe8QiDcL_B+fGVrg@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

For minimum vs average, see: https://bugs.python.org/issue28240

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Sat Jan 20 04:09:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 09:09:13 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <20180120080653.GN22500@ando.pearwood.info>
Message-ID: <CAMpsgwYmHEVJq8cyPESXJiRwWeUVLmtfcV-08VLBEyVvLnkYDA@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

"but after
looking more closely at the PR, I see that the statistics gathered
are from the (default) 1000000 runs of each call to timer.timeit()."

Ah, don't do that. Timeit runs the same code multiple times and computes
the average to compute one value on purpose. Reading a timer takes time,
and measures smaller than 1 ms are unstable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Sat Jan 20 04:21:10 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 20 Jan 2018 09:21:10 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516440070.33.0.467229070634.issue30491@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

I have a patch for this, but it will be simplest if we can merge https://github.com/python/cpython/pull/5250 (for bpo-32591) first, because they touch a lot of overlapping code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Sat Jan 20 06:21:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 11:21:44 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516447304.15.0.467229070634.issue25910@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: How many "critical"-level open issues are there? -> Fixing links in documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Jan 20 06:24:03 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 20 Jan 2018 11:24:03 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1516447443.4.0.467229070634.issue32226@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset d911e40e788fb679723d78b6ea11cabf46caed5a by Ivan Levkivskyi in branch 'master':
bpo-32226: PEP 560: improve typing module (#4906)
https://github.com/python/cpython/commit/d911e40e788fb679723d78b6ea11cabf46caed5a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Sat Jan 20 06:32:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 11:32:41 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516447961.1.0.467229070634.issue30693@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If make this change you need to make similar changes in other places that recursively add files to archives: shutil, zipapp, distutils, and maybe more.

----------
versions:  -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Sat Jan 20 07:19:23 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Jan 2018 12:19:23 +0000
Subject: [issue32598] Use autoconf to detect OpenSSL and libssl features
In-Reply-To: <1516369706.4.0.467229070634.issue32598@psf.upfronthosting.co.za>
Message-ID: <1516450763.72.0.467229070634.issue32598@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset ff5be6e8100276647e0077e80869fc022d1bb53f by Christian Heimes in branch 'master':
bpo-32598: Use autoconf to detect usable OpenSSL (#5242)
https://github.com/python/cpython/commit/ff5be6e8100276647e0077e80869fc022d1bb53f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32598>
_______________________________________

From report at bugs.python.org  Sat Jan 20 07:21:53 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Jan 2018 12:21:53 +0000
Subject: [issue32598] Use autoconf to detect OpenSSL and libssl features
In-Reply-To: <1516369706.4.0.467229070634.issue32598@psf.upfronthosting.co.za>
Message-ID: <1516450913.2.0.467229070634.issue32598@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks, Andrew

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32598>
_______________________________________

From report at bugs.python.org  Sat Jan 20 07:32:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 12:32:21 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516451541.84.0.467229070634.issue32589@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Victor. This will defeat the purpose of timeit. And making the type of the result depending on arguments usually means a bad design.

For you particular need it is easy to write an explicit loop and gather the statistics that your need.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:06:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 13:06:19 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516453579.24.0.467229070634.issue32589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> For you particular need it is easy to write an explicit loop and gather the statistics that your need.

I concur with Serhiy:

>>> loops=2**15; values = [value/loops for value in t.repeat(10, loops)]
>>> import statistics
>>> statistics.mean(values)
3.439414190675727e-06
>>> statistics.stdev(values)
1.444941323254124e-07


Matthias Gilch: "I think it's inconvenient to write those stubs every time when we have a method for this in the standard library that could be easily used with a few changes in it."

Hum, maybe a module on PyPI which uses timeit.Timer internally would be more appropriate, than extending the timeit module.

(Or use my existing perf module, it's up to you ;-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:17:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 13:17:40 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1516454260.64.0.467229070634.issue30693@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I now agree to leave Python 2.7 and 3.6 unchanged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:17:50 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Jan 2018 13:17:50 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1516454270.06.0.467229070634.issue32430@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Why not adding an option in Makefile or configure to allow to specify a different path to a custom Setup file?

Because we don't want to maintain more config options?  Really, I don't to want to further complicate our build process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:20:50 2018
From: report at bugs.python.org (TestUserEWDurbin)
Date: Sat, 20 Jan 2018 13:20:50 +0000
Subject: [issue32295] User friendly message when invoking bdist_wheel sans
 wheel package.
In-Reply-To: <1513118394.49.0.213398074469.issue32295@psf.upfronthosting.co.za>
Message-ID: <1516454450.24.0.467229070634.issue32295@psf.upfronthosting.co.za>


Change by TestUserEWDurbin <testuser-bugs at ernest.ly>:


----------
status: pending -> open
title: User friendly message when invoking bdist_wheel sans wheel package -> User friendly message when invoking bdist_wheel sans wheel package.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32295>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:20:59 2018
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Jan 2018 13:20:59 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1516454459.6.0.467229070634.issue25910@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@guido: in roundup, by default anyone can change the issue title.  I imagine he is a new user who just didn't understand that he was doing so.  (And indeed, the account was created on 1/19).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:22:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 13:22:44 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1516454564.8.0.467229070634.issue32430@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Because we don't want to maintain more config options?  Really, I don't to want to further complicate our build process.

I don't see how adding an option to make one path configurable would make the build process more complicated.

It seems like Xavier and Thomas do use Modules/Setup for their need, and for me it's strange to have to modify Modules/Setup (or Modules/Setup.dist) if it's tracked by Git. If I modify it, IMHO it's a configuration file, and it shouldn't be part of Python code base. It's fine to have a default configuration, but if you don't want to  use the default, just pass the path to your own config. No?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:25:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Jan 2018 13:25:19 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1516454564.8.0.467229070634.issue32430@psf.upfronthosting.co.za>
Message-ID: <fee5ac0d-c647-e8dd-bcc3-5c4dae39464d@free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le 20/01/2018 ? 14:22, STINNER Victor a ?crit?:
> 
> I don't see how adding an option to make one path configurable would make the build process more complicated.

Do you think implementing and maintaing an option has no cost?

> It seems like Xavier and Thomas do use Modules/Setup for their need, and for me it's strange to have to modify Modules/Setup (or Modules/Setup.dist) if it's tracked by Git.

Distributors routinely modify files that are tracked by git.
Modules/Setup doesn't have to be an exception.

See Anaconda example I posted above.  Also you can look up packaging by
RedHat or any other distro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sat Jan 20 08:32:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 13:32:40 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1516455160.08.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Interpreter Core
nosy: +serhiy.storchaka
stage: test needed -> patch review
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Sat Jan 20 09:16:32 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Jan 2018 14:16:32 +0000
Subject: [issue32602] Test ECDSA and dual mode context
In-Reply-To: <1516391192.37.0.467229070634.issue32602@psf.upfronthosting.co.za>
Message-ID: <1516457792.7.0.467229070634.issue32602@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset bd5c7d238c01b90fbfae8ea45b47bd601900abaf by Christian Heimes in branch 'master':
bpo-32602: Test ECDSA certs (#5247)
https://github.com/python/cpython/commit/bd5c7d238c01b90fbfae8ea45b47bd601900abaf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32602>
_______________________________________

From report at bugs.python.org  Sat Jan 20 09:19:28 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Jan 2018 14:19:28 +0000
Subject: [issue32602] Test ECDSA and dual mode context
In-Reply-To: <1516391192.37.0.467229070634.issue32602@psf.upfronthosting.co.za>
Message-ID: <1516457968.97.0.467229070634.issue32602@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32602>
_______________________________________

From report at bugs.python.org  Sat Jan 20 09:28:25 2018
From: report at bugs.python.org (Julien Palard)
Date: Sat, 20 Jan 2018 14:28:25 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1516458505.06.0.467229070634.issue32430@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

I don't see a use case where one want to edit a file without having his work being tracked by git, can someone shed a light to me on this?

I understand that to modify a single configuration point (a path, whatever) a configure option is the right way and is not versioned by git, but Modules/Setup is a file, not a flag.

But, I assumed the whole time Modules/Setup modifications are not trivial, but the result of some work worth versioning, unlike a single configure option, am I wrong?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sat Jan 20 09:42:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 14:42:46 +0000
Subject: [issue32503] Avoid creating small frames in pickle protocol 4
In-Reply-To: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>
Message-ID: <1516459366.74.0.467229070634.issue32503@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1211c9a9897a174b7261ca258cabf289815a40d8 by Serhiy Storchaka in branch 'master':
bpo-32503: Avoid creating too small frames in pickles. (#5127)
https://github.com/python/cpython/commit/1211c9a9897a174b7261ca258cabf289815a40d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Sat Jan 20 09:52:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 14:52:22 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516459942.62.0.467229070634.issue32594@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Isn't this a duplicate of issue18534?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Sat Jan 20 09:53:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 14:53:49 +0000
Subject: [issue32503] Avoid creating small frames in pickle protocol 4
In-Reply-To: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>
Message-ID: <1516460029.65.0.467229070634.issue32503@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Sat Jan 20 10:08:05 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Jan 2018 15:08:05 +0000
Subject: [issue31429] TLS cipher suite compile time option for downstream
In-Reply-To: <1505222565.12.0.626881844442.issue31429@psf.upfronthosting.co.za>
Message-ID: <1516460885.88.0.467229070634.issue31429@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

My PR is ready for review.

----------
nosy: +alex, dstufft, janssen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31429>
_______________________________________

From report at bugs.python.org  Sat Jan 20 10:09:21 2018
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Jan 2018 15:09:21 +0000
Subject: [issue32594] File object 'name' attribute inconsistent type and not
 obviously documented
In-Reply-To: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
Message-ID: <1516460961.05.0.467229070634.issue32594@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, yes.  When I said "this has been discussed previously", that's the issue I was thinking of but couldn't find.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> State clearly that open() 'file' param is "name" attr of the result

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Sat Jan 20 10:43:42 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Jan 2018 15:43:42 +0000
Subject: [issue29302] add contextlib.AsyncExitStack
In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za>
Message-ID: <1516463022.2.0.467229070634.issue29302@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Explicitly noting some API design decisions from the review of https://github.com/python/cpython/pull/4790:

1. AsyncExitStack will define __aenter__ and __aexit__ but *not* __enter__ and __exit. This makes it unambiguous which form of with statement you need to be using for a given stack.
2. AsyncExitStack will use the same methods to add synchronous context managers as ExitStack does
3. The only common method with clearly distinct external behaviour will be stack.close(), which will be a coroutine in the AsyncExitStack case (the other common methods will all still be synchronous in AsyncExitStack)
4. AsyncExitStack will gain 3 new methods for working with async context managers:

- enter_async_context(cm): coroutine to enter an async context manager and adds its __aexit__ to the context stack if __aenter__ succeeds
- push_async_exit(cm_or_exit): push an exit callback directly onto the stack. The argument must either be an object implementing __aexit__, or else a callback with the same signature as __aexit__ (use stack.push() to register a synchronous CM or exit callback)
- push_async_callback(callback): push the given callback onto the stack. The callback should return an awaitable (use stack.callback() to register synchronous callbacks)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29302>
_______________________________________

From report at bugs.python.org  Sat Jan 20 10:54:30 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 20 Jan 2018 15:54:30 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1516434590.8.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLjrf-PmsMZLoeWsb0zThiAJHTKZAhQM-v5rEGNZ0_1qw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

There is very little code that depends on __annotations__ at all, and none
of it is very subtle. All actual type checking is done by separate tools
(mypy, pytype, PyCharm) that don't import the code and don't care about
__annotations__. The __annotations__ variable exists so that other people
*may* do useful stuff with it, e.g. design run-time type-checking
decorators. So please don't worry about interning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sat Jan 20 11:11:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 20 Jan 2018 16:11:59 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516464719.99.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Guido,

I'd like to go forward with this and merge Nathaniel's PR.

Quick summary:

* This issue adds new APIs: a sys.set_coroutine_origin_tracking_depth(depth) function and a 'cr_origin' property to native coroutine objects.

* By using this APIs, users can opt-in to save traceback (serialized as tuples of `(funcname, filename, line)`) of where native coroutines are created.

* This allows us to deprecate the sys.set_coroutine_wrapper function, which I never liked.  It's too powerful as it allows anyone to intercept/override native coroutine construction logic.

* In turn, we are removing a lot of complexity from asyncio code: starting with 3.7 we'll use CoroWrapper only for generator-based corotuines; at some point (Python 3.9?) when we remove @asyncio.coroutine we'll be able to remove CoroWrapper.  This will also make asyncio debug mode quite a bit faster, allowing people to use it in production.

* Finally, sys.set_coroutine_wrapper was always documented as a debug-only API that might disappear in future CPython releases.  We'll deprecate it in 3.7 and remove it in 3.8.

Are you OK with this?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Sat Jan 20 12:53:34 2018
From: report at bugs.python.org (John Jolly)
Date: Sat, 20 Jan 2018 17:53:34 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1516470814.26.0.467229070634.issue32476@psf.upfronthosting.co.za>


Change by John Jolly <jjolly at suse.com>:


----------
pull_requests: +5098
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Sat Jan 20 12:57:52 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Jan 2018 17:57:52 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516471072.49.0.467229070634.issue32589@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If we agree that the patch is wrong, we should reject it and close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Sat Jan 20 13:12:50 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 20 Jan 2018 18:12:50 +0000
Subject: [issue32472] Mention of __await__ missing in Coroutine Abstract
 Methods
In-Reply-To: <1514786801.71.0.467229070634.issue32472@psf.upfronthosting.co.za>
Message-ID: <1516471970.79.0.467229070634.issue32472@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32472>
_______________________________________

From report at bugs.python.org  Sat Jan 20 13:44:10 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Jan 2018 18:44:10 +0000
Subject: [issue24334] SSLSocket extra level of indirection
In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za>
Message-ID: <1516473850.28.0.467229070634.issue24334@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5099
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24334>
_______________________________________

From report at bugs.python.org  Sat Jan 20 14:11:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 20 Jan 2018 19:11:20 +0000
Subject: [issue29833] Avoid raising OverflowError if possible
In-Reply-To: <1489739461.89.0.615647789001.issue29833@psf.upfronthosting.co.za>
Message-ID: <1516475480.65.0.467229070634.issue29833@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +chr raises OverflowError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29833>
_______________________________________

From report at bugs.python.org  Sat Jan 20 14:28:21 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 20 Jan 2018 19:28:21 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1516476501.49.0.467229070634.issue32583@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

The problem is utf16 decoder almost always assumes that two bytes decodes to one unicode character, so when allocating memory, it assumes (bytes_number+1)/2 unicode slots is enough, there is even a comment in the code. And in unicode_decode_call_errorhandler_writer, it only allocates more memory when the error handler returns a unicode longer than 1, but doesn't take care pace by one, in which case one byte to one unicode character. So it's possible for the decoder to write out of bound.

This example could steadily crash on my Mac with debug version, it writes across the bound of the internal unicode buffer:

>>> import codecs
>>> def pace_by_one(exc):
...     return ('\ufffd', exc.start+1)
...
>>> codecs.register_error('pace_by_one', pace_by_one)
>>> b'\xd8\xd8\xd8\xd8\xd8\xd8\x00\x00\x00'.decode('utf-16-le', 'pace_by_one')
Debug memory block at address p=0x10210c260: API 'o'
    100 bytes originally requested
    The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected.
    The 8 pad bytes at tail=0x10210c2c4 are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x00 *** OUCH
        at tail+1: 0x00 *** OUCH
        at tail+2: 0xfb
        at tail+3: 0xfb
        at tail+4: 0xfb
        at tail+5: 0xfb
        at tail+6: 0xfb
        at tail+7: 0xfb
    The block was made by call #30672 to debug malloc/realloc.
    Data at p: 00 00 00 00 00 00 00 00 ... fd ff fd ff fd ff d8 00

Fatal Python error: bad trailing pad byte

Current thread 0x00007fffab9b4340 (most recent call first):
  File "/Users/angwer/Repositories/cpython/Lib/encodings/utf_16_le.py", line 16 in decode
  File "<stdin>", line 1 in <module>
[1]    63997 abort      ~/Repositories/cpython/python.exe

I'll try to make a fix tomorrow.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Sat Jan 20 14:28:42 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 20 Jan 2018 19:28:42 +0000
Subject: [issue32597] Bad detection of clang
In-Reply-To: <1516367732.86.0.467229070634.issue32597@psf.upfronthosting.co.za>
Message-ID: <1516476522.46.0.467229070634.issue32597@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

> https://bugs.python.org/issue20767 was showing the issue and imho badly fixed.

You do realize that the fix was proposed by FreeBSD people and that the upstream Clang issue is still open?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32597>
_______________________________________

From report at bugs.python.org  Sat Jan 20 14:28:46 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 20 Jan 2018 19:28:46 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1516476526.29.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Sat Jan 20 14:55:51 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 20 Jan 2018 19:55:51 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1516478151.72.0.467229070634.issue32583@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Another way to crash:

>>> import codecs
>>> def replace_with_longer(exc):
...     exc.object = b'\xa0\x00' * 100
...     return ('\ufffd', exc.end)
...
>>> codecs.register
codecs.register(       codecs.register_error(
>>> codecs.register_error('replace_with_longer', rep
replace_with_longer( repr(
>>> codecs.register_error('replace_with_longer', replace_with_longer)
>>> b'\xd8\xd8'.decode('utf-16-le', 'replace_with_longer')
Debug memory block at address p=0x10b3b8c40: API 'o'
    92 bytes originally requested
    The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected.
    The 8 pad bytes at tail=0x10b3b8c9c are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0xa0 *** OUCH
        at tail+1: 0x00 *** OUCH
        at tail+2: 0xa0 *** OUCH
        at tail+3: 0x00 *** OUCH
        at tail+4: 0xa0 *** OUCH
        at tail+5: 0x00 *** OUCH
        at tail+6: 0xa0 *** OUCH
        at tail+7: 0x00 *** OUCH
    The block was made by call #11529390970613309440 to debug malloc/realloc.
    Data at p: 00 00 00 00 00 00 00 00 ... 00 00 00 00 fd ff a0 00

Fatal Python error: bad trailing pad byte

Current thread 0x00007fffab9b4340 (most recent call first):
  File "/Users/angwer/Repositories/cpython/Lib/encodings/utf_16_le.py", line 16 in decode
  File "<stdin>", line 1 in <module>
[1]    64081 abort      ~/Repositories/cpython/python.exe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Sat Jan 20 16:20:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Jan 2018 21:20:10 +0000
Subject: [issue31687] test_semaphore_tracker() of test_multiprocessing_spawn
 fails randomly (race condition?)
In-Reply-To: <1507109795.91.0.213398074469.issue31687@psf.upfronthosting.co.za>
Message-ID: <1516483210.46.0.467229070634.issue31687@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

To reproduce the issue, someone should increase the system load to make the system slower and make timeouts more likely, and change the order in which processes are run. I'm using the "stress" utility on Linux for that. But sometimes, the best stress tool... is the Python test suite, since running the full test suite in multiple processes in parallel (./python -m test -j0 -r) runs various workloads, and so sometimes trigger bugs which would be very hard to trigger othewise.

Terminal 1: run "./python -m test -j0 -r", stress or anything else to make the system slower

Terminal 2: run "./python -m test test_multiprocessing_fork -m test_semaphore_tracker -F -v" which runs the test in a loop until it fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31687>
_______________________________________

From report at bugs.python.org  Sat Jan 20 16:37:09 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 20 Jan 2018 21:37:09 +0000
Subject: [issue32603] Deprecation warning on strings used in re module
In-Reply-To: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>
Message-ID: <1516484229.59.0.467229070634.issue32603@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

+1 to this. I have seen a lot of regular expressions not using raw strings that makes use of "\d" and friends. I will work on a patch to the docs if that's ok.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Sat Jan 20 17:20:29 2018
From: report at bugs.python.org (Gordon P. Hemsley)
Date: Sat, 20 Jan 2018 22:20:29 +0000
Subject: [issue32424] Synchronize copy methods between Python and C
 implementations of xml.etree.ElementTree.Element
In-Reply-To: <1516003950.96.0.467229070634.issue32424@psf.upfronthosting.co.za>
Message-ID: <a1aebec2-7601-5112-8ab2-5fcfed30ed2c@gphemsley.org>


Gordon P. Hemsley <gphemsley at gphemsley.org> added the comment:

>> As discussed above, starting with msg309074, __deepcopy__() is being added to the Python implementation because it already exists in the C implementation.
> 
> Python implementation shouldn't copy all implementation details of the C implementation. This is cumbersome and often impossible. Both implementation should have the same behavior, and they do have.

As it stands, calling Element.__deepcopy__() will succeed with the C
implementation and fail with the Python implementation. That seems
problematic to me, and making that *not* be the case is trivial, so I
don't understand the generalization to "all implementation details".

Additionally, if copy.deepcopy() already works well with the Python
implementation, why would it not work on the C implementation? What is
different about the C implementation that requires the definition of
__deepcopy__() in the first place?

>> And additional tests have in fact uncovered further discrepancies between the Python and C implementations with regard to copying behavior.
> 
> What are these discrepancies?

As I mentioned in the PR, the C implementation does not make use of
Element.__init__() when it creates new instances of the class, opting
instead to use create_new_element() (which is not used in the C
implementation of Element.__init__()). However, create_new_element()
does not make a copy of the attrib dict that is passed in, meaning that
the internal attrib dict of an Element instance is mutable by changing
the dict that was passed in.

I have modified the C implementation to fix this problem by adding a
copy line in create_new_element(). Without this change, some of the new
tests in the PR will fail in the C implementation.

The Python implementation does not have this problem because it
inherently always goes through Element.__init__().

> In any case it is better to extend existing tests by adding missed checks than duplicate tests.

As I mentioned in the PR:

I have added the unit tests in the way that I have because the existing
checks are generally integration tests, and most of the test coverage
for this module comes as a side effect of pickle tests. It is my goal to
expand the unit tests later to test each method individually, so
starting that work here makes it easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32424>
_______________________________________

From report at bugs.python.org  Sat Jan 20 17:24:13 2018
From: report at bugs.python.org (William Hingston)
Date: Sat, 20 Jan 2018 22:24:13 +0000
Subject: [issue27682] wsgiref: Windows Error 10053,
 ConnectionAbortedError: [WinError 10053] An established connection
 was aborted by the software in your host machine
In-Reply-To: <1470313993.65.0.630797703267.issue27682@psf.upfronthosting.co.za>
Message-ID: <1516487053.31.0.467229070634.issue27682@psf.upfronthosting.co.za>


William Hingston <will.hingston at gmail.com> added the comment:

I'm still seeing this with

Python 3.6.3
Django 2.0.1
Windows 10 Pro Version 1709

Was this determined to be a Django bug?

----------
nosy: +William Hingston

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27682>
_______________________________________

From report at bugs.python.org  Sat Jan 20 18:12:32 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Jan 2018 23:12:32 +0000
Subject: [issue32378] test_npn_protocols broken with LibreSSL 2.6.1+
In-Reply-To: <1513709944.02.0.213398074469.issue32378@psf.upfronthosting.co.za>
Message-ID: <1516489952.51.0.467229070634.issue32378@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5100

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32378>
_______________________________________

From report at bugs.python.org  Sat Jan 20 18:47:26 2018
From: report at bugs.python.org (bbayles)
Date: Sat, 20 Jan 2018 23:47:26 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1516492046.31.0.467229070634.issue32502@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
keywords: +patch
pull_requests: +5101
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Sat Jan 20 19:07:20 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 21 Jan 2018 00:07:20 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516464719.99.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+b7Y+okjUPEGeZFUkOYcmmRECdGM5UhV7U4yrrGkTepw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yes, I'm OK with this plan. Note that I've only read Nathaniel's original
message and Yury's last message, and I've not reviewed the PR, but getting
rid of that eyesore sounds good, and it seems you two have reached
agreement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Sat Jan 20 20:34:53 2018
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Melero_Fern=C3=A1ndez?=)
Date: Sun, 21 Jan 2018 01:34:53 +0000
Subject: [issue32574] asyncio.Queue, put() leaks memory if the queue is full
In-Reply-To: <1516132419.05.0.467229070634.issue32574@psf.upfronthosting.co.za>
Message-ID: <1516498493.04.0.467229070634.issue32574@psf.upfronthosting.co.za>


Change by Jos? Melero Fern?ndez <jmelerofernandez at gmail.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32574>
_______________________________________

From report at bugs.python.org  Sat Jan 20 21:23:50 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 21 Jan 2018 02:23:50 +0000
Subject: [issue32603] Deprecation warning on strings used in re module
In-Reply-To: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>
Message-ID: <1516501430.4.0.467229070634.issue32603@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +5102
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Sat Jan 20 22:41:37 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 21 Jan 2018 03:41:37 +0000
Subject: [issue32232] building extensions as builtins is broken in 3.7
In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za>
Message-ID: <1516506097.07.0.467229070634.issue32232@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +5103
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32232>
_______________________________________

From report at bugs.python.org  Sat Jan 20 22:43:32 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 21 Jan 2018 03:43:32 +0000
Subject: [issue32232] building extensions as builtins is broken in 3.7
In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za>
Message-ID: <1516506212.9.0.467229070634.issue32232@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have put together a PR with Matthias' patch and a test.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32232>
_______________________________________

From report at bugs.python.org  Sat Jan 20 23:26:27 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 21 Jan 2018 04:26:27 +0000
Subject: [issue32232] building extensions as builtins is broken in 3.7
In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za>
Message-ID: <1516508787.67.0.467229070634.issue32232@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

It seems that Microsoft compiler does not handle well the circular dependencies between Include/pystate.h and Include/internal/pystate.h so I have included guards for Windows in the new include for Include/pystate.h and deactivated the test in that case. Some better ideas on how to handle that case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32232>
_______________________________________

From report at bugs.python.org  Sun Jan 21 00:40:52 2018
From: report at bugs.python.org (Dalton Campbell)
Date: Sun, 21 Jan 2018 05:40:52 +0000
Subject: [issue32606] Email Header Injection Protection Bypass
Message-ID: <1516513252.62.0.467229070634.issue32606@psf.upfronthosting.co.za>


New submission from Dalton Campbell <drcampbell13 at gmail.com>:

The protection's implemented in https://github.com/python/cpython/blob/master/Lib/email/header.py to prevent Email Header injection can be bypassed by specifying an injected additional header in the following format:
example at python.org\ncc :injected at python.org

The white space bypasses the current regex protection (_embedded_header = re.compile(r'\n[^ \t]+:')) and is still accepted by the smtp server. 

Attached is a proof of concept script

----------
components: Library (Lib)
files: PythonEmailHeaderInjectionPOC.py
messages: 310367
nosy: r.david.murray, thedoctorsoup
priority: normal
severity: normal
status: open
title: Email Header Injection Protection Bypass
type: security
Added file: https://bugs.python.org/file47396/PythonEmailHeaderInjectionPOC.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32606>
_______________________________________

From report at bugs.python.org  Sun Jan 21 00:43:51 2018
From: report at bugs.python.org (Dalton Campbell)
Date: Sun, 21 Jan 2018 05:43:51 +0000
Subject: [issue32606] Email Header Injection Protection Bypass
In-Reply-To: <1516513252.62.0.467229070634.issue32606@psf.upfronthosting.co.za>
Message-ID: <1516513431.74.0.467229070634.issue32606@psf.upfronthosting.co.za>


Change by Dalton Campbell <drcampbell13 at gmail.com>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32606>
_______________________________________

From report at bugs.python.org  Sun Jan 21 04:44:54 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 21 Jan 2018 09:44:54 +0000
Subject: [issue32391] Add StreamWriter.wait_closed()
In-Reply-To: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za>
Message-ID: <1516527894.6.0.467229070634.issue32391@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32391>
_______________________________________

From report at bugs.python.org  Sun Jan 21 05:08:13 2018
From: report at bugs.python.org (Shrivatsa Hosabettu)
Date: Sun, 21 Jan 2018 10:08:13 +0000
Subject: [issue32607] After Python Installation Error
Message-ID: <1516529293.34.0.467229070634.issue32607@psf.upfronthosting.co.za>


New submission from Shrivatsa Hosabettu <shrivatsa555 at gmail.com>:

Please let me know the below error is ok to have or how to resolve it?

3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)]
Traceback (most recent call last):
  Python Shell, prompt 0, line 21
  File "<string>", line 1, in <module>
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\__init__.py", line 19, in setup
    configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\conf\__init__.py", line 56, in __getattr__
    self._setup(name)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\conf\__init__.py", line 43, in _setup
    self._wrapped = Settings(settings_module)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\conf\__init__.py", line 106, in __init__
    mod = importlib.import_module(self.SETTINGS_MODULE)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 994, in _gcd_import
    return _find_and_load(name, _gcd_import)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 971, in _find_and_load
    return _find_and_load_unlocked(name, import_)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 941, in _find_and_load_unlocked
    _call_with_frames_removed(import_, parent)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 219, in _call_with_frames_removed
    return f(*args, **kwds)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 994, in _gcd_import
    return _find_and_load(name, _gcd_import)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 971, in _find_and_load
    return _find_and_load_unlocked(name, import_)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 953, in _find_and_load_unlocked
    raise ModuleNotFoundError(_ERR_MSG.format(name), name=name)
builtins.ModuleNotFoundError: No module named 'simplesocial'

----------
messages: 310368
nosy: shri_vatsa
priority: normal
severity: normal
status: open
title: After Python Installation Error
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32607>
_______________________________________

From report at bugs.python.org  Sun Jan 21 05:49:33 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 21 Jan 2018 10:49:33 +0000
Subject: [issue32607] After Python Installation Error
In-Reply-To: <1516529293.34.0.467229070634.issue32607@psf.upfronthosting.co.za>
Message-ID: <1516531773.98.0.467229070634.issue32607@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This looks like a broken or incorrectly configured Django installation.

What happens when you run this from your operating system shell?

python3.6 -E -S

If you are on Windows, you might need to use this instead:

py -E -S

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32607>
_______________________________________

From report at bugs.python.org  Sun Jan 21 07:32:20 2018
From: report at bugs.python.org (stein-k)
Date: Sun, 21 Jan 2018 12:32:20 +0000
Subject: [issue32498] urllib.parse.unquote raises incorrect errormessage when
 string parameter is bytes
In-Reply-To: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>
Message-ID: <1516537940.32.0.467229070634.issue32498@psf.upfronthosting.co.za>


stein-k <karlsen.stein at gmail.com> added the comment:

Patch for tests.

Added test for calling unquote with bytes input and removed Exception raised in original test.

----------
Added file: https://bugs.python.org/file47397/urllib_parse_unquote_handle_bytes_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Sun Jan 21 07:55:27 2018
From: report at bugs.python.org (Michael Durso)
Date: Sun, 21 Jan 2018 12:55:27 +0000
Subject: [issue32608] Incompatibilities with the socketserver and
 multiprocessing packages
Message-ID: <1516539327.3.0.467229070634.issue32608@psf.upfronthosting.co.za>


New submission from Michael Durso <rbprogrammer at gmail.com>:

This is more of an issue with socketserver rather than multiprocessing.  I could not find socketserver experts to add to the nosy list, but I've included the multiprocessing experts for completeness.

Under specific conditions, multiprocessing queues cease to work when modules like socketserver is used, more specifically when fork() is used.  This makes sense that things can break when fork() is used since a simple forked process has things like file descriptors and threads invalidated.  The socketserver.ForkingMixIn class, which has very reasonable use-cases, causes multiprocessing queues and threads to break.  A script that replicates and simulates the issue is attached.

The attached script sets up a multiprocessing queue used for logging across all sub-processes, then uses a socketserver.ForkingTCPServer to handle new client connection.  What's happening is the fork() is invalidating the thread in the QueueHandler in each new sub-process (for each new client conncetion).  It turns the QueueHandler into a dead object.

In this scenario, the only indication the problem exists is the fact that log messages are not actually logged.  But I think it's plausible that more than just log data could be lost.

When a non-modified version of CPython, the script should run and produce a log file.  However, logs from the client connection handler (MyClientHandler) will be lost and never sent to the logging handler that performs the actual file writing.  To exercise the proposed fix to CPython, build the changes to socketserver.py and then change the script's "USE_FIX" flag to "True" and run the script.

----------
components: Library (Lib)
files: multiprocessing_socketserver.py
messages: 310371
nosy: davin, pitrou, rbprogrammer
priority: normal
severity: normal
status: open
title: Incompatibilities with the socketserver and multiprocessing packages
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47398/multiprocessing_socketserver.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32608>
_______________________________________

From report at bugs.python.org  Sun Jan 21 07:56:29 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 21 Jan 2018 12:56:29 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1516539389.92.0.467229070634.issue32430@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

I fully concur with all points in Victor msg310345.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sun Jan 21 08:01:56 2018
From: report at bugs.python.org (Michael Durso)
Date: Sun, 21 Jan 2018 13:01:56 +0000
Subject: [issue32608] Incompatibilities with the socketserver and
 multiprocessing packages
In-Reply-To: <1516539327.3.0.467229070634.issue32608@psf.upfronthosting.co.za>
Message-ID: <1516539716.8.0.467229070634.issue32608@psf.upfronthosting.co.za>


Change by Michael Durso <rbprogrammer at gmail.com>:


----------
keywords: +patch
pull_requests: +5104
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32608>
_______________________________________

From report at bugs.python.org  Sun Jan 21 08:49:52 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 21 Jan 2018 13:49:52 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1516542592.46.0.467229070634.issue32430@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

A solution to this issue must deal with the following use case:

A developer has made changes to Modules/Setup and is tracking these changes in a VCS, for example with mercurial or with a git submodule through a symlink. By the time he is about to pull the commit that is fixing this issue from the Python repository, he is also experimenting with a new modification in Modules/Setup that he has not commited or staged yet in his own mercurial or git submodule repository or whatever.

IMO a solution to this issue that overwrites the current user changes when he is merging the corresponding commit is not acceptable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32430>
_______________________________________

From report at bugs.python.org  Sun Jan 21 09:00:24 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Jan 2018 14:00:24 +0000
Subject: [issue32609] Add setter and getter for min/max protocol ersion
Message-ID: <1516543224.12.0.467229070634.issue32609@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

OpenSSL 1.1 has introduced a new API to set the minimum and maximum supported protocol version. The API is easier to use than the old OP_NO_TLSv1 option flags, too

https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_min_proto_version.html

Debian used the new setters to disable TLS 1.0 and 1.1 in testing, #31453. The old TLS versions have been enabled again for now. Python must expose the new API in case Debian decides to disable them again.

I also like to deprecate the old OP_NO_TLSv1 et al. flags in favor of the new API. The option flags are awkward to use and easy to get wrong. For example applications must not leave holes in the OP_NO range (e.g. allow TLS 1.0 and 1.2 but disable 1.1).

----------
assignee: christian.heimes
components: SSL
messages: 310374
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add setter and getter for min/max protocol ersion
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32609>
_______________________________________

From report at bugs.python.org  Sun Jan 21 09:02:47 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Jan 2018 14:02:47 +0000
Subject: [issue32609] Add setter and getter for min/max protocol ersion
In-Reply-To: <1516543224.12.0.467229070634.issue32609@psf.upfronthosting.co.za>
Message-ID: <1516543367.05.0.467229070634.issue32609@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +5106
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32609>
_______________________________________

From report at bugs.python.org  Sun Jan 21 09:44:42 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 21 Jan 2018 14:44:42 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516545882.89.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Merged!  Thank you, Nathaniel!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Sun Jan 21 10:56:38 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 21 Jan 2018 15:56:38 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1516550198.83.0.467229070634.issue32583@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I write a draft patch, without tests yet. I'll add them later. Reviews are appreciated. I also check the Windows codepage equivalent and encoders, look to me they don't suffer the problem.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: https://bugs.python.org/file47399/issue32583.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Sun Jan 21 11:20:25 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 21 Jan 2018 16:20:25 +0000
Subject: [issue32532] improve sys.settrace and sys.setprofile documentation
In-Reply-To: <1515651956.68.0.467229070634.issue32532@psf.upfronthosting.co.za>
Message-ID: <1516551625.28.0.467229070634.issue32532@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Hi Pablo, it would be nice. But for #17799, I don't know actually which part should be fixed, doc or code? I think it's better to consult gurus on python-dev mail list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32532>
_______________________________________

From report at bugs.python.org  Sun Jan 21 11:45:25 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 21 Jan 2018 16:45:25 +0000
Subject: [issue32610] asyncio.all_tasks() should return only non-finished
 tasks.
Message-ID: <1516553125.63.0.467229070634.issue32610@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Current behavior has a subtle pitfall.
The function returns a list of *existing* tasks (not removed by decref or explicit call).
If user's code has a strong reference to some task the task will be in return list for unpredictable amount of time, even if the task was done.

Returning only *alive* tasks can make a function result more predictable (`not task.done()`).

Opinions?

----------
components: asyncio
messages: 310378
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.all_tasks() should return only non-finished tasks.
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32610>
_______________________________________

From report at bugs.python.org  Sun Jan 21 11:49:12 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 21 Jan 2018 16:49:12 +0000
Subject: [issue32610] asyncio.all_tasks() should return only non-finished
 tasks.
In-Reply-To: <1516553125.63.0.467229070634.issue32610@psf.upfronthosting.co.za>
Message-ID: <1516553352.44.0.467229070634.issue32610@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I agree, returning done tasks is pretty useless.

This is a new function so let's fix its behavour.  We need to:

1. Document this difference between new asyncio.all_tasks() and now deprecated Task.all_tasks().

2. Make sure that Task.all_tasks() works in 3.7 in the same way it was working before 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32610>
_______________________________________

From report at bugs.python.org  Sun Jan 21 13:18:29 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 21 Jan 2018 18:18:29 +0000
Subject: [issue32314] Implement asyncio.run()
In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za>
Message-ID: <1516558709.8.0.467229070634.issue32314@psf.upfronthosting.co.za>


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


----------
pull_requests: +5107

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32314>
_______________________________________

From report at bugs.python.org  Sun Jan 21 14:56:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 21 Jan 2018 19:56:47 +0000
Subject: [issue31179] Speed-up dict.copy() up to 5.5 times.
In-Reply-To: <1502400693.03.0.6389481443.issue31179@psf.upfronthosting.co.za>
Message-ID: <1516564607.09.0.467229070634.issue31179@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I've pushed a new version of the patch that I intend to merge tomorrow.

The last version has only one minor change: it uses fast-path for "slightly" non-compact dicts too (dicts don't use *at most* 3 entries).  This protects us from pathological cases when a huge dict being almost emptied with pop/del and then gets copied -- we indeed want the copy to be compact.

Although I believe that the real issue is that del and pop don't compact dicts from time to time, but I don't want that issue to hold off this patch in any way.

> If you will make dict copying removing holes and extend your patch to dict constructor, it could be more useful.

It's already useful -- I'm supporting a large code base (>0.5M LOC) which uses dict.copy() extensively, and it shows up in profile.  I've seen it in many other places (particularly ORMs love to store information in dicts and use dict.copy() to track dirty state/changes).  Please don't say that dict.copy() is not a common operation or that dict(other_dict) is more common than other_dict.copy() -- that's simply incorrect.

> The side effect of this patch is making dict.copy() atomic. This is a worthy feature if extent it to dict constructor.

I agree.  I'll work on that later in a follow-up PR.  Let's move in small steps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31179>
_______________________________________

From report at bugs.python.org  Sun Jan 21 14:57:01 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 21 Jan 2018 19:57:01 +0000
Subject: [issue32314] Implement asyncio.run()
In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za>
Message-ID: <1516564621.71.0.467229070634.issue32314@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset a4afcdfa55ddffa4b9ae3b0cf101628c7bff4102 by Yury Selivanov in branch 'master':
bpo-32314: Fix asyncio.run() to cancel runinng tasks on shutdown (#5262)
https://github.com/python/cpython/commit/a4afcdfa55ddffa4b9ae3b0cf101628c7bff4102


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32314>
_______________________________________

From report at bugs.python.org  Sun Jan 21 15:11:32 2018
From: report at bugs.python.org (Minion Jim)
Date: Sun, 21 Jan 2018 20:11:32 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
Message-ID: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>


New submission from Minion Jim <epaine13 at ranelagh.bracknell-forest.sch.uk>:

When using Python version 3.6.4, Tkinter shows a blank icon on the taskbar. This means any Tkinter window including IDLE and a blank one. Unfortunately, I don't have a screenshot to show this as I reinstalled version 3.6.3 which works perfectly.

----------
components: Windows
messages: 310382
nosy: Minion Jim, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Tkinter taskbar icon (Windows)
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Sun Jan 21 15:34:14 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Jan 2018 20:34:14 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516566854.6.0.467229070634.issue32513@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5108
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sun Jan 21 16:01:31 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 21 Jan 2018 21:01:31 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516568491.57.0.467229070634.issue17799@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The reason not to pass C calls to the tracing function is that tracing exists to support pdb and other debuggers, and pdb only cares about tracing through Python code. So the docs should be updated.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Sun Jan 21 16:04:41 2018
From: report at bugs.python.org (benrg)
Date: Sun, 21 Jan 2018 21:04:41 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
Message-ID: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>


New submission from benrg <benrudiak at gmail.com>:

(Pure)WindowsPath uses str.lower to fold paths for comparison and hashing. This doesn't match the case folding of actual Windows file systems. There exist WindowsPath objects that compare and hash equal, but refer to different files. For example, the strings

  '\xdf' (sharp S) and '\u1e9e' (capital sharp S)
  '\u01c7' (LJ) and '\u01c8' (Lj)
  '\u0130' (I with dot) and 'i\u0307' (i followed by combining dot)
  'K' and '\u212a' (Kelvin sign)

are equal under str.lower folding but are distinct file names on NTFS volumes on my Windows 7 machine. There are hundreds of other such pairs.

I think this is very bad. The reverse (paths that compare unequal but refer to the same file) is probably unavoidable and is expected by programmers. But paths that compare equal should never be unequal to the OS.

How to fix this:

Unfortunately, there is no correct way to case fold Windows paths. The FAT, NTFS, and exFAT drivers on my machine all have different behavior. (The examples above work on all three, except for 'K' and '\u212a', which are equivalent on FAT volumes.) NTFS stores its case-folding map on each volume in the hidden $UpCase file, so even different NTFS volumes on the same machine can have different behavior. The contents of $UpCase have changed over time as Windows is updated to support new Unicode versions. NTFS and NFS (and possibly WebDAV) also support full case sensitivity when used with Interix/SUA and Cygwin, though this requires disabling system-wide case insensitivity via the registry.

I think that pathlib should either give up on case folding entirely, or should fold very conservatively, treating WCHARs as equivalent only if they're equivalent on all standard file systems on all supported Windows versions.

If pathlib folds case at all, there should be a solution for people who need to interoperate with Cygwin or SUA tools on a case-sensitive machine, but I suppose they can just use PosixPath.

----------
components: Library (Lib), Windows
messages: 310384
nosy: benrg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.(Pure)WindowsPaths can compare equal but refer to different files
type: security
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Sun Jan 21 16:08:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 21 Jan 2018 21:08:20 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516568900.56.0.467229070634.issue32591@psf.upfronthosting.co.za>


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


----------
pull_requests: +5109

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Sun Jan 21 17:07:09 2018
From: report at bugs.python.org (Julien Palard)
Date: Sun, 21 Jan 2018 22:07:09 +0000
Subject: [issue32613] Use PEP 397 py launcher in windows faq
Message-ID: <1516572429.98.0.467229070634.issue32613@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

The windows FAQ (https://docs.python.org/3.6/faq/windows.html) uses `python` to launch python, I think it should use the `py` python launcher from pep 397.

----------
assignee: mdk
components: Documentation
keywords: easy
messages: 310385
nosy: mdk
priority: low
severity: normal
stage: needs patch
status: open
title: Use PEP 397 py launcher in windows faq
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32613>
_______________________________________

From report at bugs.python.org  Sun Jan 21 17:42:57 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 21 Jan 2018 22:42:57 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1516574577.5.0.467229070634.issue32304@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
keywords: +patch
pull_requests: +5110
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Sun Jan 21 17:47:38 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 21 Jan 2018 22:47:38 +0000
Subject: [issue32614] Fix documentation examples of using re with escape
 sequences
Message-ID: <1516574858.82.0.467229070634.issue32614@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

If a documentation example would produce a DeprecationWarning for an invalid escape sequence, change the example to use a raw string.

----------
assignee: docs at python
components: Documentation
messages: 310386
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Fix documentation examples of using re with escape sequences
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32614>
_______________________________________

From report at bugs.python.org  Sun Jan 21 17:51:16 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 21 Jan 2018 22:51:16 +0000
Subject: [issue32614] Fix documentation examples of using re with escape
 sequences
In-Reply-To: <1516574858.82.0.467229070634.issue32614@psf.upfronthosting.co.za>
Message-ID: <1516575076.11.0.467229070634.issue32614@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5111
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32614>
_______________________________________

From report at bugs.python.org  Sun Jan 21 18:12:25 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 21 Jan 2018 23:12:25 +0000
Subject: [issue31787] various refleaks when calling the __init__() method of
 an object more than once
In-Reply-To: <1507972588.41.0.213398074469.issue31787@psf.upfronthosting.co.za>
Message-ID: <1516576345.31.0.467229070634.issue31787@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Raymond,

You approved this PR pending some test cases.  Would you have the chance to take another look?

Thanks!


Oren, it looks like you'll need to rebase before this could be merged.

----------
nosy: +csabella, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31787>
_______________________________________

From report at bugs.python.org  Sun Jan 21 18:46:26 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 21 Jan 2018 23:46:26 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
Message-ID: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

Take the following code:

    import builtins
    class K(dict):
	def __getitem__(self, k):
		if k not in builtins.__dict__:
			print("get %s" % k)
		return dict.__getitem__(self, k)
	def __setitem__(self, k, v):
		print("set %s" % k)
		dict.__setitem__(self, k, v)
    exec("""
        foo = "bar"
        foo
        try:
            qyz
        except NameError:
	    pass
        class K:
	    baz = foo
	    def f(ggg=foo): pass
        def g(ggg=foo):
	    global f
	    f = 87
            f
        g()
    """,K())

This should consitently either call or not call the overridden methods on the dictionary, producing either no output or:

    set foo
    get foo
    get qyz
    get foo
    get foo
    set K
    get foo
    set g
    get g
    set f
    get f
    
Instead, only sometime the override gets called, producing

    set foo
    get foo
    get qyz
    set K
    get foo
    set g
    get g
    get f

meaning that 
    (a) modifications of global variables via global statements
    (b) code at class-level

ignore overridden methods, whereas everything else follows them

----------
components: Interpreter Core
messages: 310388
nosy: ppperry
priority: normal
severity: normal
status: open
title: Inconsistent behavior if globals is a dict subclass
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Sun Jan 21 18:50:00 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 21 Jan 2018 23:50:00 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516578600.18.0.467229070634.issue27815@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I converted the patch to a PR.  

It wouldn't merge which means I did it manually, so please check it for errors.  Some issues I ran into:
1. The patch had a change to __slots__, but that line no longer existed and I didn't know if I needed to make a different change to accommodate it.
2. I converted the 'What's New' to a blurb.

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Sun Jan 21 20:43:01 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 22 Jan 2018 01:43:01 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516585381.18.0.467229070634.issue27815@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

The current default is hard to defend -- it's a clear violation of the TLS specs. But I suspect that changing it will be pretty disruptive, because suppress_ragged_eof=True is the de facto standard for HTTP-over-TLS (generally justified on the grounds that HTTP has its own framing, so the TLS-level close-notify stuff is redundant), and that means that if we flip it cases that used to work correctly will start raising errors. We could avoid some of these issues by making http.client explicitly use suppress_ragged_eof=True, but then that won't fix Martin's problems...

A discussion about changing it should also consider what to do on sslsock.close(), since right now Python always gives the other side a "ragged eof" unless you call "sslsock.unwrap()", and I've never seen any code that does this. So flipping the suppress_ragged_eof default by itself will make Python's ssl module fail at interoperating with itself.

> 1. Truncate Set-Cookie field, with no terminating newline. [...] Python (unpatched) treats the Set-Cookie field as valid. It appears in the HTTPResponse object, with no clue that it was truncated.

This sounds like a bug in http.client ? the lack of terminating newline should cause a parse failure regardless of what the SSL layer does (and regardless of whether we're even using SSL).

> 2. Content-Length response with truncated text/html. [...] In most cases, Python raised an IncompleteRead exception, but it depended on the pattern of read calls

Also a bug in http.client.

> 3. ?Connection: close? response with truncated HTML:

This one's a little more interesting... First, "Connection: close" doesn't affect the framing of the HTTP body, it just says that this connection can't be reused for another request afterwards. The way HTTP works, if you have a response with neither a Content-Length header *nor* a Transfer-Encoding: chunked header, then it's assumed that the framing is determined by the connection being closed -- I assume that this is what you generated here. Now, this is a hack for backwards compatibility with HTTP/1.0; in theory, no modern server should ever generate such a response. In practice, who knows, people do all kinds of nonsense.

But... do we really think that servers who can't be bothered to implement HTTP/1.1, are also going to take the trouble to make sure their SSL/TLS handling is correct to the spec? If the server decides to use connection-close framing, that's their decision, and the client is kind of at their mercy.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Sun Jan 21 20:47:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 01:47:10 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516585630.79.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 3510334361d6d39aad89e4e0d9bccd0695668583 by Yury Selivanov in branch 'master':
bpo-32591: Fix PyExc_WarnFormat call (follow-up commit) (#5263)
https://github.com/python/cpython/commit/3510334361d6d39aad89e4e0d9bccd0695668583


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Sun Jan 21 21:41:21 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Jan 2018 02:41:21 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516588881.05.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Here is my proposal for making it easier for the user to supply dunder methods that dataclasses would otherwise automatically add to the class.

For all of these cases, when I talk about init=, repr=, eq=, order=, hash=, or frozen=, I'm referring to the parameters to the dataclass decorator.

When checking if a dunder method already exists, I mean check for an entry in the class's __dict__. I never check to see if a member is defined in a base class.

Let's get the easy ones out of the way first.

__init__
If __init__ exists or init=False, don't generate __init__.

__repr__
If __repr__ exists or repr=False, don't generate __repr__.

__setattr__
__delattr__
If frozen=True and either of these methods exist, raise a TypeError. These methods are needed for the "frozen-ness" of the class to be implemented, and if they're already set then that behavior can't be enforced.

__eq__
If __eq__ exists or eq=False, don't generate __eq__.

And now the harder ones:

__ne__
I propose to never generate a __ne__ method. Python will call __eq__ and negate the result for you. If you feel you really need a non-matching __ne__, then you can write it yourself without interference from dataclasses.

__lt__
__le__
__gt__
__ge__
I propose to treat each of these individually, but for each of them using the value of the order= parameter. So:
If __lt__ exists or order=False, don't generate __lt__.
If __le__ exists or order=False, don't generate __le__.
If __gt__ exists or order=False, don't generate __gt__.
If __ge__ exists or order=False, don't generate __ge__.
If for some crazy reason you want to define some of these but not others, then set order=False and write your desired methods.

__hash__
Whether dataclasses might generate __hash__ depends on the values of hash=, eq=, and frozen=. Note that the default value of hash= is None. See below for an explanation.

If hash=False, never generate __hash__. If hash=True, generate __hash__ unless it already exists.

If hash=None (the default), then use this table to decide whether and how to generate __hash__:
eq=?	frozen=?	__hash__
False	False		do not generate __hash__
False	True		do not generate __hash__
True	False		set __hash__ to None unless it already exists
True	True		generate __hash__ unless it already exists
                         and is None

Note that it's almost always a bad idea to specify hash=True or hash=False. The action based on the above table (where hash=None, the default), is usually the correct behavior.

One special case to recognize is if the class defines a __eq__. In this case, Python will assign __hash__=None before the dataclass decorator is called. The decorator cannot distinguish between these two cases (except possibly by using the order of __dict__ keys, but that seems overly fragile):

@dataclass
class A:
    def __eq__(self, other): pass

@dataclass
class B:
    def __eq__(self, other): pass
    __hash__ = None

This is the source of the last line in the above table: for a dataclass where eq=True, frozen=True, and hash=None, if __hash__ is None it will still be overwritten. The assumption is that this is what the user wants, but it's a tricky corner case. It also occurs if setting hash=True and defining __eq__. Again, it's not expected to come up in normal usage.

----------
keywords:  -patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sun Jan 21 22:06:04 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 22 Jan 2018 03:06:04 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516590364.75.0.467229070634.issue17799@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Hi Guido. Looking at the implementation, it seems pdb ignores c_call not by relying on the interpreter, but bdb takes no action when encountering C events. Yeah, even bdb wrongly expects C events will be triggered for settrace. [1]

And what if some debuggers want not only to trace Python events but also C events, then it has to mix the power of trace and profile but can't only rely on trace.

[1] https://github.com/python/cpython/blob/master/Lib/bdb.py#L59

----------
versions: +Python 3.6, Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Sun Jan 21 22:08:41 2018
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 22 Jan 2018 03:08:41 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516590521.02.0.467229070634.issue32513@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Do all the parameters to the decorator take a default value of "None", so that you can differentiate between explicit True, explicit False, and did-not-specify?

Is this the complete list of these dunder-method-generation-control parameters? init repr eq order hash

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sun Jan 21 23:34:14 2018
From: report at bugs.python.org (Zhiming Wang)
Date: Mon, 22 Jan 2018 04:34:14 +0000
Subject: [issue32616] Significant performance problems with Python 2.7 built
 with clang 3.x or 4.x
Message-ID: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>


New submission from Zhiming Wang <zmwangx at gmail.com>:

Python 2.7 could be significantly slower (5x in some cases) when compiled with clang 3.x or 4.x, compared to clang 5.x. This is quite a problem on macOS, since the latest clang from Apple (which comes with Xcode 9.2) is based on LLVM 4.x. This issue was first noticed by Bart Skowron and reported to the Homebrew project.[1]

I ran some preliminary benchmarks (here[2] are the exact setup scripts) with just a simple loop:

    import time

    def f(n):
        while n > 0:
            n -= 1

    start = time.time()
    f(50000000)
    stop = time.time()
    print('%.6f' % (stop - start))

and here are my results:

- macOS 10.13.2 on a MacBook Pro:

    2.082144	/usr/bin/python2.7
    7.964049	/usr/local/bin/python2.7
    8.750652	dist/python27-apple-clang-900/bin/python2.7
    8.476405	dist/python27-clang-3.9/bin/python2.7
    8.625660	dist/python27-clang-4.0/bin/python2.7
    1.760096	dist/python27-clang-5.0/bin/python2.7
    3.254814	/usr/local/bin/python3.6
    2.864716	dist/python-master-apple-clang-900/bin/python3
    3.071757	dist/python-master-clang-3.9/bin/python3
    2.925192	dist/python-master-clang-4.0/bin/python3
    2.908782	dist/python-master-clang-5.0/bin/python3

- Ubuntu 17.10 in VirtualBox:

    1.475095	/usr/bin/python2.7
    8.576817	dist/python27-clang-3.9/bin/python2.7
    8.165588	dist/python27-clang-4.0/bin/python2.7
    1.779193	dist/python27-clang-5.0/bin/python2.7
    1.728321	dist/python27-gcc-5/bin/python2.7
    1.570040	dist/python27-gcc-6/bin/python2.7
    1.604617	dist/python27-gcc-7/bin/python2.7
    2.323037	/usr/bin/python3.6
    2.964338	dist/python-master-clang-3.9/bin/python3
    3.054277	dist/python-master-clang-4.0/bin/python3
    2.734908	dist/python-master-clang-5.0/bin/python3
    2.490278	dist/python-master-gcc-5/bin/python3
    2.494691	dist/python-master-gcc-6/bin/python3
    2.642277	dist/python-master-gcc-7/bin/python3

I haven't got time to run more rigorous benchmark suites (e.g., the performance[3] package). I did try the floating point benchmark from performance, and again saw a 2x difference in performance.

[1] https://github.com/Homebrew/homebrew-core/issues/22743
[2] https://gist.github.com/zmwangx/f8151ba8907ba8159a07fdd1528fc2b5
[3] https://pypi.python.org/pypi/performance

----------
messages: 310395
nosy: zmwangx
priority: normal
severity: normal
status: open
title: Significant performance problems with Python 2.7 built with clang 3.x or 4.x
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Mon Jan 22 00:10:04 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 22 Jan 2018 05:10:04 +0000
Subject: [issue32616] Significant performance problems with Python 2.7 built
 with clang 3.x or 4.x
In-Reply-To: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>
Message-ID: <1516597804.97.0.467229070634.issue32616@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:03:10 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Jan 2018 06:03:10 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1516590364.75.0.467229070634.issue17799@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLGv1gSuMQjw6xac7YX=tni91xXEZyQg9Bq2Ccs51X78A@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Too bad, it's been like this since the feature was first created. It would
most likely break other code that uses the tracing hooks, so you'd have to
propose it as a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:07:26 2018
From: report at bugs.python.org (Greg Lindahl)
Date: Mon, 22 Jan 2018 06:07:26 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1516601246.36.0.467229070634.issue4356@psf.upfronthosting.co.za>


Change by Greg Lindahl <lindahl at pbm.com>:


----------
nosy: +wumpus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:22:13 2018
From: report at bugs.python.org (Avnish Midha)
Date: Mon, 22 Jan 2018 06:22:13 +0000
Subject: [issue32617] dict.update does not concat/replace if same key
Message-ID: <1516602133.05.0.467229070634.issue32617@psf.upfronthosting.co.za>


New submission from Avnish Midha <avnishbm10 at gmail.com>:

The dict does not seem to work as one would expect a dictionary or a hashtable to work. 

dict.update(otherdict) just replaces the entries as per otherdict, removing items which were extra in dict too and just keeping items as per new data in otherdict only. Shouldn't this be actually about updating the dict with new/updated entries and not touching those entries which pre-existed?

Sample program below:
import pandas as pd

x = {'name': ['A', 'B', 'C'], 'col2': [3, 4,6]}
y = {'name': ['B', 'C', 'D', 'E'], 'col2': [1,2, 9, 10]}


print ("X = \n" + str(x))

print ("Y = \n" + str(y))

x.update(y)

print ("updated dict = \n"  + str(x) + "\n")

#####

Output:

X = 
{'name': ['A', 'B', 'C'], 'col2': [3, 4, 6]}
Y = 
{'name': ['B', 'C', 'D', 'E'], 'col2': [1, 2, 9, 10]}
updated dict = 
{'name': ['B', 'C', 'D', 'E'], 'col2': [1, 2, 9, 10]}


Expected value:
updated dict = 
{'name': ['A','B', 'C', 'D', 'E'], 'col2': [3, 1, 2, 9, 10]}


Somehow to do this basic hashtable or dictionary update kind of operation is too complex in python and update() should have actually functioned as expected above IMO.

----------
components: Interpreter Core
files: dict_try.py
messages: 310397
nosy: Avnish Midha
priority: normal
severity: normal
status: open
title: dict.update does not concat/replace if same key
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47400/dict_try.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32617>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:28:29 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 22 Jan 2018 06:28:29 +0000
Subject: [issue32618] fix test_codeccallbacks.test_mutatingdecodehandler
Message-ID: <1516602509.19.0.467229070634.issue32618@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

test_codeccallbacks.test_mutatingdecodehandler is introduced in e78178e2c05ec2bb628b70a8b5422bb4dae63343. Obviously it should test against both test.replacing and test.mutating but it tests test.replacing twice.

----------
components: Tests
keywords: easy
messages: 310398
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: fix test_codeccallbacks.test_mutatingdecodehandler
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32618>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:36:07 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 22 Jan 2018 06:36:07 +0000
Subject: [issue32618] fix test_codeccallbacks.test_mutatingdecodehandler
In-Reply-To: <1516602509.19.0.467229070634.issue32618@psf.upfronthosting.co.za>
Message-ID: <1516602967.15.0.467229070634.issue32618@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +patch
pull_requests: +5112
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32618>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:44:45 2018
From: report at bugs.python.org (Greg Lindahl)
Date: Mon, 22 Jan 2018 06:44:45 +0000
Subject: [issue12735] request full Unicode collation support in std python
 library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1516603485.38.0.467229070634.issue12735@psf.upfronthosting.co.za>


Change by Greg Lindahl <lindahl at pbm.com>:


----------
nosy: +wumpus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Mon Jan 22 02:37:56 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Jan 2018 07:37:56 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516606676.54.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Only hash has the tri-state True/False/None behavior, defaulting to None. It's this way because None is the "do what's rational, based on eq and frozen" behavior. None of the other parameters work this way. 

There's a long issue in the attrs repo that describes how they came to this conclusion: https://github.com/python-attrs/attrs/issues/136. I think it makes sense.

None of the dataclass parameters have a sentinel that would let me detect if the user provided a value or not. In the case of hash, I can't detect if they explicitly passed hash=None or just didn't provide a value. I've given this some thought, and couldn't come up with a use case for knowing this. For example, if init had a sentinel value of MISSING, what would the code ever do except start with:
if init is sentinel:
    init = True
?

In addition to your list of dunder-control-parameters, there's frozen. It determines if instances are immutable (to the extent that they can be made immutable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 22 02:46:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Jan 2018 07:46:05 +0000
Subject: [issue32617] dict.update does not concat/replace if same key
In-Reply-To: <1516602133.05.0.467229070634.issue32617@psf.upfronthosting.co.za>
Message-ID: <1516607165.75.0.467229070634.issue32617@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm sorry the name is confusing to you, but this behavior is correct, and how dict.update is defined:

https://docs.python.org/3.6/library/stdtypes.html#dict.update

As such, it cannot be changed.

If you want a function that merges values, you'll need to write it yourself.

Eric.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32617>
_______________________________________

From report at bugs.python.org  Mon Jan 22 02:47:09 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 22 Jan 2018 07:47:09 +0000
Subject: [issue29752] Enum._missing_ not called for __getitem__ failures
In-Reply-To: <1488925792.17.0.971645599389.issue29752@psf.upfronthosting.co.za>
Message-ID: <1516607229.39.0.467229070634.issue29752@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I'm not convinced this piece needs to be in the stdlib.  Unlike other bits that need extensive metaclass support this is trivial to add:

  class DerivedEnumMeta(EnumMeta):
    def __getitem__(cls, name):
        try:
            return cls._member_map_[name]
        except KeyError:
            result = cls._missing_name_(name)
            if isinstance(result, cls):
                return result
            raise

----------
resolution:  -> rejected
stage: test needed -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29752>
_______________________________________

From report at bugs.python.org  Mon Jan 22 02:55:52 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Jan 2018 07:55:52 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516607752.45.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Oops, that should have been:

if init is MISSING:
    init = True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 22 03:49:15 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Jan 2018 08:49:15 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516610955.19.0.467229070634.issue27815@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Before we can disable ragged EOF handling, we first have to fix ssl.SSLSocket()'s shutdown behavior. It should support at least a proper unidirectional shutdown besides the slow bidirectional shutdown. It might even be a good idea to default to unidirectional shutdown. Curl does it, https://github.com/curl/curl/blob/9e4ad1e2af22f00eeca533b745b67956f57319cb/lib/vtls/openssl.c#L1155-L1168


I wrote this in a mail to Cory about PEP 543 two weeks ago:

Now to the nasty session and shutdown issue. I discovered it just a
couple of weeks ago.

We have to revisit TLS socket shutdown in order to make TLS session
resumption work. OpenSSL discards and invalidates sessions when a SSL
socket isn't properly shut down, e.g. hard-close I/O layer. Simply
speaking OpenSSL has four shutdown modes: bidirectional, unidirection,
quiet, and hard. Python's ssl module supports slow bidirectional mode
and hard mode.

* In bidirectional mode, both parties send a "close notify" alert and
wait for confirmation.
* Unidirectional means that one party just sends a "close notify" alert
and then closes the connection. It doesn't wait for ACK.
* Quiet shutdown doesn't send anything. It merely sets some internal
flags to mark the connection as closed and session as valid
* What I call 'hard mode' just kills the I/O layer and frees the SSL*.
Sessions are marked as invalid because OpenSSL rightly assumes that
something went wrong and the session cannot be reused safely.

https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_quiet_shutdown(3)
https://wiki.openssl.org/index.php/Manual:SSL_shutdown(3)

We need an API to perform some sort of shutdown on __exit__(None, None,
None) / close().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 03:58:14 2018
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 22 Jan 2018 08:58:14 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516611494.91.0.467229070634.issue32513@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

So if I understand correctly: the default value of the "repr" parameter is True.


Decision matrix: does dataclass insert a __repr__ into the class?

  +-- row: argument passed in to decorator's repr parameter
  |
  |
  v    | yes     | no      |  <--- columns: does the class have a __repr__?
-------+---------+---------+
 True  | ???     | yes     |
-------+---------+---------+
 False | no      | no      |
-------+---------+---------+

If the user specifies "repr=True", and also specifies their own __repr__ in the class, does dataclasses stomp on their __repr__ with its own?  Does it throw an exception?


I still prefer the tri-state value here.  In this version, the default value of the "repr" parameter would be None, and the decision matrix for inserting a __repr__ looks like this:

  +-- row: argument passed in to decorator's repr parameter
  |
  |
  v    | yes     | no      |  <--- columns: does the class have a __repr__?
-------+---------+---------+
 True  | raise   | yes     |
-------+---------+---------+
 None  | no      | yes     |
-------+---------+---------+
 False | no      | no      |
-------+---------+---------+

But we've talked about using the tri-state default for all of these parameters before, and clearly you weren't swayed then, so I guess I've said my peace and I'll stop suggesting it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 22 04:08:46 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 22 Jan 2018 09:08:46 +0000
Subject: [issue32458] test_asyncio failures on Windows
In-Reply-To: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za>
Message-ID: <1516612126.95.0.467229070634.issue32458@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Hmm, the scheduled call was executed sooner than expected.
Actually we had 0.1 sec delay, checked for at least 0.08 but actual call time was 0.078

BTW I recall an issue with Windows when call_later() was executed sooner already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32458>
_______________________________________

From report at bugs.python.org  Mon Jan 22 04:29:42 2018
From: report at bugs.python.org (Mukhit)
Date: Mon, 22 Jan 2018 09:29:42 +0000
Subject: [issue32619] multiplication error
Message-ID: <1516613382.08.0.467229070634.issue32619@psf.upfronthosting.co.za>


New submission from Mukhit <mukhit at mail.ru>:

print (10*3.14)

31.400000000000002

----------
components: ctypes
messages: 310406
nosy: mukhit
priority: normal
severity: normal
status: open
title: multiplication error
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32619>
_______________________________________

From report at bugs.python.org  Mon Jan 22 04:41:50 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 22 Jan 2018 09:41:50 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516614110.87.0.467229070634.issue27815@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

@Christian: I'm surprised and somewhat dismayed to hear that OpenSSL invalidates sessions on hard close -- that hasn't been part of the spec since 2006 when TLS 1.1 came out. I'm not a cryptographer, but the spec explicitly allows keeping the session, and I can't think of any particular reason why a network closure should imply that the secret material associated with the session has been compromised.

FWIW trio currently implements bidirectional mode (await ssl_stream.unwrap()),  unidirectional mode (default for await ssl_stream.aclose()), and what-I-thought-was-quiet-but-apparently-is-hard (await ssl_stream.aclose() if the stream has the https_compatible=True flag set, or if a call to aclose() times out) [1]. I guess I should make that last one soft [2]. You actually can do all these things with the current ssl module, but it's extremely tricky and confusing. In particular, the way you do 'unidirectional' is to put the socket in non-blocking mode or use SSLObject and then call unwrap(), and when you get SSLWantReadError you're done, you can close the socket.

You might also by amused by this comment I left Cory in June and only just managed to track down again: https://github.com/python-hyper/pep543/issues/2#issuecomment-308900931 (and the rest of the thread too, but that comment specifically gets into shutdown semantics)

[1] https://github.com/python-trio/trio/blob/317020537ecefa9d6c6214c3caf4011ca4cfb564/trio/_ssl.py#L708-L791
[2] https://github.com/python-trio/trio/issues/415

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 04:45:00 2018
From: report at bugs.python.org (Matthias Gilch)
Date: Mon, 22 Jan 2018 09:45:00 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516614300.18.0.467229070634.issue32589@psf.upfronthosting.co.za>


Matthias Gilch <matthias.gilch.mg+py at gmail.com> added the comment:

Steven: Thanks for the advice. Next time I'll follow it
Victor: I'll look into perf 

I see that there are maybe problems and agree that we can close the issue and the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Mon Jan 22 04:45:16 2018
From: report at bugs.python.org (Matthias Gilch)
Date: Mon, 22 Jan 2018 09:45:16 +0000
Subject: [issue32589] Statistics as a result from timeit
In-Reply-To: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>
Message-ID: <1516614316.02.0.467229070634.issue32589@psf.upfronthosting.co.za>


Change by Matthias Gilch <matthias.gilch.mg+py at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status:  -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:17:13 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Jan 2018 10:17:13 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516616233.24.0.467229070634.issue27815@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

You have to tell OpenSSL that a hard-close is expected and fine. If you just SSL_free() the SSL connection, then OpenSSL removes the session from the SSL_CTX's session cache. It assumes that something went wrong and defaults to secure defaults. "Wrong" doesn't necessarily mean that an attacker has compromised a connection.

In order to flag a session as valid, you have to SSL_set_quiet_shutdown(ssl, 1), SSL_shutdown(ssl), SSL_free(ss). With quiet shutdown set, SSL_shutdown() neither sends nor waits for any data.

One-way shutdown with non-blocking trick is evil. Cool hack :)

 SSLSocket and SSLObject should really support different shutdown modes, e.g. s.shutdown(mode=0) for quiet, mode=1 for unidirectional and mode=2 for bidirectional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:18:07 2018
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 22 Jan 2018 10:18:07 +0000
Subject: [issue32072] Issues with binary plists
In-Reply-To: <1511031976.48.0.213398074469.issue32072@psf.upfronthosting.co.za>
Message-ID: <1516616287.67.0.467229070634.issue32072@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset c59731d92dc73111d224876f1caa064097aad786 by larryhastings (Serhiy Storchaka) in branch '3.4':
[3.4] bpo-32072: Fix issues with binary plists. (GH-4455) (#4658)
https://github.com/python/cpython/commit/c59731d92dc73111d224876f1caa064097aad786


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32072>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:22:48 2018
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 22 Jan 2018 10:22:48 +0000
Subject: [issue32266] test_pathlib fails if current path has junctions
In-Reply-To: <1512894567.77.0.213398074469.issue32266@psf.upfronthosting.co.za>
Message-ID: <1516616568.96.0.467229070634.issue32266@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Python 3.4 and 3.5 are in "security fixes only" mode.  This is a minor bugfix, so it's too late to accept it into 3.4 and 3.5.

----------
nosy: +larry
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32266>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:25:07 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 22 Jan 2018 10:25:07 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516616707.51.0.467229070634.issue27815@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

It doesn't help that Python spells SSL_shutdown as "unwrap".

I think in practice basically the only two things you want are unidirectional shutdown, or "soft" shutdown. Bidirectional shutdown has some extremely theoretical uses, and we have to provide it anyway because it's in the API already. I don't know of any reason to ever use "hard" shutdown, though I'd be interested to hear of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:36:53 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 22 Jan 2018 10:36:53 +0000
Subject: [issue32619] multiplication error
In-Reply-To: <1516613382.08.0.467229070634.issue32619@psf.upfronthosting.co.za>
Message-ID: <1516617413.09.0.467229070634.issue32619@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is not a bug, it is a FAQ to do with the properties of binary floating point numbers.


https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32619>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:46:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 10:46:18 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516617978.82.0.467229070634.issue27815@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I don't know well, Cheryl's PR wasn't added to this issue: https://github.com/python/cpython/pull/5266

----------
pull_requests: +5113
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:56:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 10:56:53 +0000
Subject: [issue32620] [3.5] Travis CI fails on Python 3.5 with "pyenv: version
 `3.5' not installed"
Message-ID: <1516618613.48.0.467229070634.issue32620@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

My workaround for bpo-31568 is causing new issues on Python 3.5.

Output:
---
0.03s$ pyenv global system 3.5
pyenv: version `3.5' not installed
---

Extract of Python 3.5 .travis.yml:
---
      before_install:
        # work around https://github.com/travis-ci/travis-ci/issues/8363
        - pyenv global system 3.5
---

=> https://github.com/travis-ci/travis-ci/issues/8363

This workaround was added by me:
---
commit 70c630a7316f9f6063557786442e3c56502fe8ea
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Sun Sep 24 15:45:00 2017 -0700

    bpo-31568, Travis CI: Fix python3.5 (#3737)
    
    Works around Travis CI bug about the python3.5 binary:
    https://github.com/travis-ci/travis-ci/issues/8363
---

Without the workaround, running "python3.5" on Travis CI failed with "pyenv: python3.5: command not found".

Extract of Larry Hastings's email:
---

I have three PRs for Python 3.5.5rc1:

    https://github.com/python/cpython/pull/4656
    https://github.com/python/cpython/pull/5197
    https://github.com/python/cpython/pull/5201

I can't merge them because Travis CI is unhappy.  All three CI tests fail in the same way, reporting this error:

    The command "pyenv global system 3.5" failed and exited with 1 during .
---
https://mail.python.org/pipermail/python-committers/2018-January/005135.html

----------
components: Tests
messages: 310416
nosy: vstinner
priority: normal
severity: normal
status: open
title: [3.5] Travis CI fails on Python 3.5 with "pyenv: version `3.5' not installed"
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32620>
_______________________________________

From report at bugs.python.org  Mon Jan 22 06:02:11 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 22 Jan 2018 11:02:11 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516618931.77.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

The discussion on python-dev was that your ??? box would be "no": if the user supplied __repr__, they obviously meant for dataclass() to not provide one.

I can't see why the user would say repr=True ("I want dataclass() to add __repr__"), but then provide a __repr__ and get an exception. That looks like the only functionality added by your repr=True row over the proposal. Where your proposal uses repr=None for the "no", "yes" row, mine uses repr=True.

It's not like there's action at a distance here: the user is writing the class. Especially since base classes are ignored. 

I'm ignoring make_dataclasses(), where the user is dynamically creating a class and maybe a __repr__ snuck in. But I don't care so much about that case.

I do think your ascii tables are a good way of explaining this. Thanks! (Now I need a 3D version for eq, frozen, hash!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 22 06:38:31 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Jan 2018 11:38:31 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516621111.24.0.467229070634.issue27815@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Perhaps a hard close is the right thing when SSLSocket.__exit__ encounters an exception?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 06:42:10 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 22 Jan 2018 11:42:10 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516621330.78.0.467229070634.issue27815@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Why would an exception inside 'with ssl_sock' have anything to do with the validity of the session shared secret?

I mean, maybe it does, but I *really* don't think we should be waving our hands and guessing about this stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 07:06:35 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Jan 2018 12:06:35 +0000
Subject: [issue27815] Make SSL suppress_ragged_eofs default more secure
In-Reply-To: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>
Message-ID: <1516622795.53.0.467229070634.issue27815@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

For example an invalid host name should invalidate the session until #31399 is resolved. Any TLS protocol violation should also invalidate the session. If somebody messes with the connection or the TLS protocol encounters a problem during MAC validation, the connection must be considered as tainted.

Some exception may be fine. IMO it's still safer hard-close the connection on any exceptions.

I agree with you. Let's not guess and ask some experts. I'm having meetings with security engineers from GnuTLS and NSS next week. I'll ask them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27815>
_______________________________________

From report at bugs.python.org  Mon Jan 22 08:42:38 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 22 Jan 2018 13:42:38 +0000
Subject: [issue32472] Mention of __await__ missing in Coroutine Abstract
 Methods
In-Reply-To: <1514786801.71.0.467229070634.issue32472@psf.upfronthosting.co.za>
Message-ID: <1516628558.27.0.467229070634.issue32472@psf.upfronthosting.co.za>


Change by Yahya Abou Imran <yahya-abou-imran at protonmail.com>:


----------
keywords: +patch
pull_requests: +5114
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32472>
_______________________________________

From report at bugs.python.org  Mon Jan 22 08:54:43 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 13:54:43 +0000
Subject: [issue32472] Mention of __await__ missing in Coroutine Abstract
 Methods
In-Reply-To: <1514786801.71.0.467229070634.issue32472@psf.upfronthosting.co.za>
Message-ID: <1516629283.44.0.467229070634.issue32472@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

+1 to what Andres said.

----------
nosy: +yselivanov
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32472>
_______________________________________

From report at bugs.python.org  Mon Jan 22 09:19:28 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 22 Jan 2018 14:19:28 +0000
Subject: [issue32616] Significant performance problems with Python 2.7 built
 with clang 3.x or 4.x
In-Reply-To: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>
Message-ID: <1516630768.85.0.467229070634.issue32616@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
components: +Interpreter Core
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Mon Jan 22 09:28:36 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 22 Jan 2018 14:28:36 +0000
Subject: [issue32621] Problem of consistence in collection.abc documentation
Message-ID: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

Opened after https://github.com/python/cpython/pull/5270 was closed.

Here:

https://docs.python.org/3/library/collections.abc.html

Some abstract methods are inherited from a superclass.
Most of the time the name of the method is mentioned in the subclass.

For example:

Collection inherit from Sized, Iterable and Contains.
But __len__, __iter__ and __contains__ are mentioned, even if they are inherited.

Mapping inherits from Collection, but __len__ and __iter__ appears in the table

There is one exception: Coroutine.
It inherits from Awaitable but we don't see __await__.

What would we do? Let all appear or not?

----------
messages: 310422
nosy: yahya-abou-imran
priority: normal
severity: normal
status: open
title: Problem of consistence in collection.abc documentation
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32621>
_______________________________________

From report at bugs.python.org  Mon Jan 22 10:21:57 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 22 Jan 2018 15:21:57 +0000
Subject: [issue32622] Implement loop.sendfile
Message-ID: <1516634517.98.0.467229070634.issue32622@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement loop.sendfile
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Mon Jan 22 10:22:52 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 22 Jan 2018 15:22:52 +0000
Subject: [issue32622] Implement loop.sendfile
Message-ID: <1516634572.8.0.467229070634.issue32622@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +5115
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Mon Jan 22 10:36:30 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Jan 2018 15:36:30 +0000
Subject: [issue32616] Significant performance problems with Python 2.7 built
 with clang 3.x or 4.x
In-Reply-To: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>
Message-ID: <1516635390.09.0.467229070634.issue32616@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Has anyone done the same analysis with Python 3.6 or 3.7?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Mon Jan 22 10:37:47 2018
From: report at bugs.python.org (Zhiming Wang)
Date: Mon, 22 Jan 2018 15:37:47 +0000
Subject: [issue32616] Significant performance problems with Python 2.7 built
 with clang 3.x or 4.x
In-Reply-To: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>
Message-ID: <1516635467.02.0.467229070634.issue32616@psf.upfronthosting.co.za>


Zhiming Wang <zmwangx at gmail.com> added the comment:

My benchmarks above do contain py37 (master) stats.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Mon Jan 22 10:56:39 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 22 Jan 2018 15:56:39 +0000
Subject: [issue31801] vars() manipulation encounters problems with Enum
In-Reply-To: <1508199715.37.0.213398074469.issue31801@psf.upfronthosting.co.za>
Message-ID: <1516636599.41.0.467229070634.issue31801@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset a4b1bb4801f7a941ff9e86b96da539be1c288833 by Ethan Furman in branch 'master':
bpo-31801:  Enum:  add _ignore_ as class option (#5237)
https://github.com/python/cpython/commit/a4b1bb4801f7a941ff9e86b96da539be1c288833


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31801>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:02:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 16:02:07 +0000
Subject: [issue31179] Speed-up dict.copy() up to 5.5 times.
In-Reply-To: <1502400693.03.0.6389481443.issue31179@psf.upfronthosting.co.za>
Message-ID: <1516636927.24.0.467229070634.issue31179@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Yury: Would you mind to open an issue to investigate why dict are not compatected automatically?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31179>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:37:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 16:37:38 +0000
Subject: [issue32623] Resize dict on del/pop
Message-ID: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

We should investigate whether we want dicts to compact themselves on del/pop operations.  Currently we have to rely on workarounds to have compactable dict.copy (see issue 31179) etc.

----------
components: Interpreter Core
messages: 310427
nosy: inada.naoki, serhiy.storchaka, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Resize dict on del/pop
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:37:55 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 16:37:55 +0000
Subject: [issue31179] Speed-up dict.copy() up to 5.5 times.
In-Reply-To: <1502400693.03.0.6389481443.issue31179@psf.upfronthosting.co.za>
Message-ID: <1516639075.69.0.467229070634.issue31179@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Victor: done; https://bugs.python.org/issue32623

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31179>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:38:53 2018
From: report at bugs.python.org (Shrivatsa Hosabettu)
Date: Mon, 22 Jan 2018 16:38:53 +0000
Subject: [issue32607] After Python Installation Error
In-Reply-To: <1516529293.34.0.467229070634.issue32607@psf.upfronthosting.co.za>
Message-ID: <1516639133.53.0.467229070634.issue32607@psf.upfronthosting.co.za>


Shrivatsa Hosabettu <shrivatsa555 at gmail.com> added the comment:

Hi,

 Thanks for the information. I re-installed Python and Django again and the problem is resolved.

Now when I run the command py -E -S I got the below message and python is running fine.

3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)]

you can mark this as closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32607>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:48:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 16:48:36 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516639716.67.0.467229070634.issue29240@psf.upfronthosting.co.za>


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


----------
pull_requests: +5116

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:41:02 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 22 Jan 2018 16:41:02 +0000
Subject: [issue29344] sock_recv not detected a coroutine
In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za>
Message-ID: <1516639262.56.0.467229070634.issue29344@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Andrew, shouldn't we fix 3.6 documentation? sock_* methods still documented as coroutines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29344>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:49:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 16:49:02 +0000
Subject: [issue29344] sock_recv not detected a coroutine
In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za>
Message-ID: <1516639742.1.0.467229070634.issue29344@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Andrew, shouldn't we fix 3.6 documentation? sock_* methods still documented as coroutines.

We only fixed it in 3.7 and the doc was updated.  3.6 stays as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29344>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:54:45 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 16:54:45 +0000
Subject: [issue31179] Speed-up dict.copy() up to 5.5 times.
In-Reply-To: <1502400693.03.0.6389481443.issue31179@psf.upfronthosting.co.za>
Message-ID: <1516640085.37.0.467229070634.issue31179@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b0a7a037b8fde56b62f886d5188bced7776777b4 by Yury Selivanov in branch 'master':
bpo-31179: Make dict.copy() up to 5.5 times faster. (#3067)
https://github.com/python/cpython/commit/b0a7a037b8fde56b62f886d5188bced7776777b4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31179>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:55:17 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 16:55:17 +0000
Subject: [issue31179] Speed-up dict.copy() up to 5.5 times.
In-Reply-To: <1502400693.03.0.6389481443.issue31179@psf.upfronthosting.co.za>
Message-ID: <1516640117.23.0.467229070634.issue31179@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31179>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:57:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 16:57:06 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516640226.91.0.467229070634.issue32623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Note: It was recently discussed if "del dict[key]" should keep the insertion order. If I understood correctly: yes, the order must be preserved on deletion.

https://mail.python.org/pipermail/python-dev/2017-November/150142.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:10:13 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 22 Jan 2018 17:10:13 +0000
Subject: [issue29344] sock_recv not detected a coroutine
In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za>
Message-ID: <1516641013.95.0.467229070634.issue29344@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> We only fixed it in 3.7 and the doc was updated.  3.6 stays as is.

I'm not talking about fixing code in 3.6. In 3.6, sock_* methods still documented as coroutines but they are normal functions:

* https://docs.python.org/3.6/library/asyncio-eventloop.html#low-level-socket-operations
* https://github.com/python/cpython/blob/4002d5dbf4c058bbf2462f9f5dea057956d1caff/Doc/library/asyncio-eventloop.rst#low-level-socket-operations
* https://github.com/python/cpython/blob/4002d5dbf4c058bbf2462f9f5dea057956d1caff/Lib/asyncio/selector_events.py#L354

3.6 documentation still needs to be fixed. See my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29344>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:16:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 17:16:32 +0000
Subject: [issue29344] sock_recv not detected a coroutine
In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za>
Message-ID: <1516641392.45.0.467229070634.issue29344@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Since we made them coroutines in 3.7, I'd prefer to keep the 3.6 documentation as is (so that people don't write code that expects them to be not coroutines in 3.6).

Please let's keep the current status quo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29344>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:32:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 17:32:55 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516642375.04.0.467229070634.issue32593@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 13ff24582c99dfb439b1af7295b401415e7eb05b by Victor Stinner in branch 'master':
bpo-32593: Drop FreeBSD 9 and older support (#5232)
https://github.com/python/cpython/commit/13ff24582c99dfb439b1af7295b401415e7eb05b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:33:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 17:33:53 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516642433.57.0.467229070634.issue32593@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:35:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 17:35:02 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1516642502.44.0.467229070634.issue20767@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I guess the FreeBSD people are happy with the solution.

According to the discussion on https://github.com/python/cpython/pull/5233 : some FreeBSD people are unhappy :-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:35:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 17:35:48 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516642548.26.0.467229070634.issue32593@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

For the PR 5233 : I suggest to continue the discussion on bpo-20767. This PR is unrelated to this issue (drop support for old FreeBSDs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:35:52 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Jan 2018 17:35:52 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1516642552.63.0.467229070634.issue26647@psf.upfronthosting.co.za>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
components: +Interpreter Core -Documentation
stage: needs patch -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:39:55 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 22 Jan 2018 17:39:55 +0000
Subject: [issue32624] Implement WriteTransport.is_protocol_paused()
Message-ID: <1516642795.12.0.467229070634.issue32624@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

The method should return True is write is suspended

----------
components: asyncio
messages: 310439
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement WriteTransport.is_protocol_paused()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32624>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:41:42 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Jan 2018 17:41:42 +0000
Subject: [issue32625] Update the dis module documentation to reflect switch to
 wordcode
Message-ID: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

A switch to wordcode is implemented in Python 3.6, but the documentation in the dis module was mostly left unchanged.  See issue 26647, msg266388 and issue 27095, msg268389.

----------
assignee: docs at python
components: Documentation
messages: 310440
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Update the dis module documentation to reflect switch to wordcode
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32625>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:45:16 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Jan 2018 17:45:16 +0000
Subject: [issue32625] Update the dis module documentation to reflect switch to
 wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1516643116.33.0.467229070634.issue32625@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

There is an uncommitted update for the EXTENDED_ARG opcode documentation attached to issue 27095 as mkfu4.patch by Demur Rumed.

----------
nosy: +Demur Rumed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32625>
_______________________________________

From report at bugs.python.org  Mon Jan 22 13:00:30 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 22 Jan 2018 18:00:30 +0000
Subject: [issue29344] sock_recv not detected a coroutine
In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za>
Message-ID: <1516644030.53.0.467229070634.issue29344@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Well, the current status quo has already confused a user (see msg286011)

> (so that people don't write code that expects them to be not coroutines in 3.6)

Even if people expect these methods to be coroutines, two functions of the asyncio public API (iscoroutinefunction() and iscoroutine()) disagree with them as described in msg286011.

In similar scenarios, we've always keep the code as is and clarified the docs in stable releases, then changed the code behave as documented in master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29344>
_______________________________________

From report at bugs.python.org  Mon Jan 22 13:07:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 18:07:35 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516644455.18.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 9089a265918754d95e105a7c4c409ac9352c87bb by Victor Stinner in branch 'master':
bpo-29240: PyUnicode_DecodeLocale() uses UTF-8 on Android (#5272)
https://github.com/python/cpython/commit/9089a265918754d95e105a7c4c409ac9352c87bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Mon Jan 22 13:09:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 18:09:52 +0000
Subject: [issue29240] PEP 540: Add a new UTF-8 mode
In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za>
Message-ID: <1516644592.22.0.467229070634.issue29240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I partially reverted the commit 7ed7aead9503102d2ed316175f198104e0cd674c: on Android, UTF-8 is now always used, again. Paul Peny (aka pmpp) confirmed me that my commit broke Python on Android, at least with API 19 (locales don't work properly before API 21).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29240>
_______________________________________

From report at bugs.python.org  Mon Jan 22 13:17:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 18:17:06 +0000
Subject: [issue29344] sock_recv not detected a coroutine
In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za>
Message-ID: <1516645026.14.0.467229070634.issue29344@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

They have been documented as coroutines and were returning futures since Python 3.4. I believe we can keep the status quo especially if only one user complained about it during the last 5 years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29344>
_______________________________________

From report at bugs.python.org  Mon Jan 22 13:25:54 2018
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Jan 2018 18:25:54 +0000
Subject: [issue32597] Bad detection of clang
In-Reply-To: <1516367732.86.0.467229070634.issue32597@psf.upfronthosting.co.za>
Message-ID: <1516645554.1.0.467229070634.issue32597@psf.upfronthosting.co.za>


Change by Stefan Krah <stefan at bytereef.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32597>
_______________________________________

From report at bugs.python.org  Mon Jan 22 13:27:28 2018
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Jan 2018 18:27:28 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1516645648.22.0.467229070634.issue20767@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Well, they had ample time to articulate themselves. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Mon Jan 22 14:01:34 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Jan 2018 19:01:34 +0000
Subject: [issue32625] Update the dis module documentation to reflect switch to
 wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1516647694.18.0.467229070634.issue32625@psf.upfronthosting.co.za>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32625>
_______________________________________

From report at bugs.python.org  Mon Jan 22 15:19:49 2018
From: report at bugs.python.org (Xavier G. Domingo)
Date: Mon, 22 Jan 2018 20:19:49 +0000
Subject: [issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
In-Reply-To: <1501874201.48.0.0126792321555.issue31122@psf.upfronthosting.co.za>
Message-ID: <1516652389.61.0.467229070634.issue31122@psf.upfronthosting.co.za>


Change by Xavier G. Domingo <xgdomingo at gmail.com>:


----------
nosy: +xgdomingo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31122>
_______________________________________

From report at bugs.python.org  Mon Jan 22 15:25:10 2018
From: report at bugs.python.org (Xavier G. Domingo)
Date: Mon, 22 Jan 2018 20:25:10 +0000
Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636
In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za>
Message-ID: <1516652710.06.0.467229070634.issue22499@psf.upfronthosting.co.za>


Change by Xavier G. Domingo <xgdomingo at gmail.com>:


----------
nosy: +xgdomingo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22499>
_______________________________________

From report at bugs.python.org  Mon Jan 22 15:33:07 2018
From: report at bugs.python.org (ppperry)
Date: Mon, 22 Jan 2018 20:33:07 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1516653187.49.0.467229070634.issue32615@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Jan 22 16:16:13 2018
From: report at bugs.python.org (Jason Qian)
Date: Mon, 22 Jan 2018 21:16:13 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1516655773.75.0.467229070634.issue22872@psf.upfronthosting.co.za>


Change by Jason Qian <jqian at tibco.com>:


----------
components: +ctypes -Library (Lib)
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan 22 17:39:59 2018
From: report at bugs.python.org (Ben Burrill)
Date: Mon, 22 Jan 2018 22:39:59 +0000
Subject: [issue32626] Subscript unpacking raises SyntaxError
Message-ID: <1516660799.03.0.467229070634.issue32626@psf.upfronthosting.co.za>


New submission from Ben Burrill <bburrill98 at gmail.com>:

PEP 448 defines unpacking generalizations for tuples.  However, this does not currently work for subscripted tuples that are not delimited by parentheses.

Current behavior (Tested on 3.6/3.7a4):
>>> class Subscriptable:
...     def __getitem__(self, item):
...         return item
...
>>> ss = Subscriptable()
>>> 
>>> 1, 2, 3
(1, 2, 3)
>>> ss[1, 2, 3]
(1, 2, 3)
>>> *range(5), 42
(0, 1, 2, 3, 4, 42)
>>> ss[*range(5), 42]  # This should be the same as above
  File "<stdin>", line 1
    ss[*range(5), 42]
       ^
SyntaxError: invalid syntax
>>> ss[(*range(5), 42)]  # Workaround
(0, 1, 2, 3, 4, 42)

----------
components: Interpreter Core
messages: 310447
nosy: Ben Burrill
priority: normal
severity: normal
status: open
title: Subscript unpacking raises SyntaxError
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32626>
_______________________________________

From report at bugs.python.org  Mon Jan 22 17:46:19 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Jan 2018 22:46:19 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1516661179.2.0.467229070634.issue32604@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

@Eric, given the breadth of change introduced in the PR (including adding a new extension), I think it would be best if at all possible to get it in for beta 1 if we can resolve the review comments in time.  If necessary and if there are no objections from other core developers, I would be willing to consider making an exception and allowing it into beta 2 as long as it remains a private interface. If it looks like it won't be in releasable shape by then, I think you should hold off for 3.8; doing otherwise would be unfair to others and to our downstream beta users / testers, for example, even if it is private, adding a new extension and setup.py changes potentially affect downstream packagers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 22 18:41:55 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 22 Jan 2018 23:41:55 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1516184213.8.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <e2c0c9c9-a210-1879-cf45-484a04618dac@felt.demon.nl>


Michael Felt <michael at felt.demon.nl> added the comment:

On 1/17/2018 11:16 AM, David CARLIER wrote:
> David CARLIER <devnexen at gmail.com> added the comment:
>
> Might comes from uuid1 function itself ... e.g. line 704 not setting version "field".
IMHO: for uuid1 - the version number should be in the 16 bytes filled by 
uuid_create. The implementation of uuid4() in uuid.py "has to" specify 
the attribute by setting the UUID version attribute to 4, so that when 
an uuid4 instance gets asked it's version it says 4. A random number 
gives no such guarantee.

Taking a hint from the FreeBSD man page for uuid_create() - that says it 
provides a DCE 1.1 RPC implementation - I found this link:
http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm

Therein:

The timestamp is a 60 bit value. For UUID version 1, this is represented 
by Coordinated Universal Time (UTC) as a count of 100-nanosecond 
intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian 
reform to the Christian calendar).

The version number is multiplexed in the 4 most significant bits of the 
*time_hi_and_version* field. UUID version Field 
<http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm#tagtcjh_35> 
lists currently defined versions of the UUID.

Again - a random number is not likely to correctly set the 4 most significant bits - so another way is needed to make an instance it is version 4.
IMHO - the output of uuid_create should satisfy the needs of uuid version 1.

>
> ----------
> nosy: +David CARLIER2
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32493>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Mon Jan 22 19:06:24 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 23 Jan 2018 00:06:24 +0000
Subject: [issue28980] ResourceWarning when imorting antigravity in 3.6
In-Reply-To: <1481814216.83.0.890338512389.issue28980@psf.upfronthosting.co.za>
Message-ID: <1516665984.14.0.467229070634.issue28980@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I have not seen this for quite some time so I'm closing this as fixed.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28980>
_______________________________________

From report at bugs.python.org  Mon Jan 22 19:11:21 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 00:11:21 +0000
Subject: [issue32436] Implement PEP 567
Message-ID: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:


New changeset f23746a934177c48eff754411aba54c31d6be2f0 by Yury Selivanov in branch 'master':
bpo-32436: Implement PEP 567 (#5027)
https://github.com/python/cpython/commit/f23746a934177c48eff754411aba54c31d6be2f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Mon Jan 22 19:12:14 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 00:12:14 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516666334.49.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'll keep the issue open -- a documentation for the new APIs will be merged in a separate PR in a couple of months.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Mon Jan 22 19:18:31 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 23 Jan 2018 00:18:31 +0000
Subject: [issue32607] After Python Installation Error
In-Reply-To: <1516529293.34.0.467229070634.issue32607@psf.upfronthosting.co.za>
Message-ID: <1516666711.92.0.467229070634.issue32607@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32607>
_______________________________________

From report at bugs.python.org  Mon Jan 22 19:19:44 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 00:19:44 +0000
Subject: [issue32590] Proposal: add an "ensure(arg)" builtin for parameter
 validation
In-Reply-To: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>
Message-ID: <1516666784.91.0.467229070634.issue32590@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I agreed that this idea isn't really baked enough for an RFE yet, so I'm marking this as "postponed" for now.

The main requirement for getting it back out of "postponed" state would be having someone that's sufficiently interested to write a PEP and wrangle some related python-ideas threads.

----------
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Mon Jan 22 19:36:15 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 23 Jan 2018 00:36:15 +0000
Subject: [issue31333] Implement ABCMeta in C
In-Reply-To: <1504472061.83.0.294667499276.issue31333@psf.upfronthosting.co.za>
Message-ID: <1516667775.3.0.467229070634.issue31333@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch
pull_requests: +5117
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31333>
_______________________________________

From report at bugs.python.org  Mon Jan 22 19:53:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 00:53:31 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1516668811.91.0.467229070634.issue31368@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Explanation for myself.

https://kernelnewbies.org/Linux_4.14#Asynchronous_buffered_I.2FO_support

"In this release, the preadv2(2) syscall with RWF_NONBLOCK will let userspace applications bypass enqueuing operation in the threadpool if it's already available in the pagecache."

For applications using a thread pool, like the aiofiles does for asyncio, preadv2() allows to bypass the thread pool which is obviously faster. If the read block, just uses thread pool as currently done.

Same rationale for pwritev2().

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Mon Jan 22 20:05:34 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 23 Jan 2018 01:05:34 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666334.49.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJfJ6Qu3NVAYm1=1u-b=_7_e1aCnCGZgNAS5zmzq-z4uw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Hopefully sooner?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Mon Jan 22 20:07:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 01:07:20 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516669640.06.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'll try to find some time after beta-1.  Right now have a few other issues that I have to finish (and also create a PR to make decimal use PEP 567).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Mon Jan 22 20:15:34 2018
From: report at bugs.python.org (Tim Smith)
Date: Tue, 23 Jan 2018 01:15:34 +0000
Subject: [issue32616] Significant performance problems with Python 2.7 built
 with clang 3.x or 4.x
In-Reply-To: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>
Message-ID: <1516670134.39.0.467229070634.issue32616@psf.upfronthosting.co.za>


Change by Tim Smith <pythonbugs at tim-smith.us>:


----------
nosy: +tdsmith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Mon Jan 22 20:32:09 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 23 Jan 2018 01:32:09 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516669640.06.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKczcSEZ_hwycP+AgeBmXjh3foe--K7hYNJ6p-drpMWEg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

While you're waiting for code review maybe you can review some other PR?
(Lukasz mentioned that Serhiy seems very busy.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Mon Jan 22 20:36:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 01:36:59 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516671419.79.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This one: https://github.com/python/cpython/pull/5273? I've left a comment with some questions there. Are there any other urgent PRs?

The main PEP 567 PR has been merged already, btw.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Mon Jan 22 20:54:03 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 01:54:03 +0000
Subject: [issue32627] Header dependent _uuid build failure on Fedora 27
Message-ID: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I'm hitting a build failure relating to the new _uuid module on Fedora 27:

==============
building '_uuid' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include -I. -I/usr/local/include -I/home/ncoghlan/devel/cpython/Include -I/home/ncoghlan/devel/cpython -c /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c -o build/temp.linux-x86_64-3.7/home/ncoghlan/devel/cpython/Modules/_uuidmodule.o
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:8:0:
/usr/include/uuid.h:94:24: error: conflicting types for ?uuid_t?
 typedef struct uuid_st uuid_t;
                        ^~~~~~
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:5:0:
/usr/include/uuid/uuid.h:44:23: note: previous declaration of ?uuid_t? was here
 typedef unsigned char uuid_t[16];
                       ^~~~~~
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:8:0:
/usr/include/uuid.h:107:22: error: conflicting types for ?uuid_compare?
 extern uuid_rc_t     uuid_compare  (const uuid_t  *_uuid, const uuid_t *_uuid2, int *_result);
                      ^~~~~~~~~~~~
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:5:0:
/usr/include/uuid/uuid.h:73:12: note: previous declaration of ?uuid_compare? was here
 extern int uuid_compare(const uuid_t uu1, const uuid_t uu2);
            ^~~~~~~~~~~~
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c: In function ?py_uuid_generate_time_safe?:
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:15:12: error: storage size of ?uuid? isn?t known
     uuid_t uuid;
            ^~~~
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:15:12: warning: unused variable ?uuid? [-Wunused-variable]
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:29:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
==============

>From my initial investigation, I think the issue may be related to my previous attempt to fix this in https://github.com/python/cpython/commit/53efbf3977a44e382397e7994a2524b4f8c9d053#diff-2eeaed663bd0d25b7e608891384b7298 and the fact that there are *two* "uuid.h" headers available in the Fedora repos:

* /usr/include/uuid.h (provided by uuid-devel)
* /usr/include/uuid/uuid.h (provided by libuuid-devel)

Right now, the build works if you have "libuuid-devel" installed, but do *not* have "uuid-devel" installed.

With both installed, neither installed, or only uuid-devel installed, the build will fail, but the exact errors reported will vary. (There's also a distinct set of compile errors you can get if you forget to rerun configure after installing the additional headers)

Reverting my previous commit (and replacing it with a comment saying we're specifically looking for "uuid/uuid.h", not "uuid.h") may be enough to handle the case where both are installed.

----------
messages: 310459
nosy: christian.heimes, ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Header dependent _uuid build failure on Fedora 27
type: compile error
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32627>
_______________________________________

From report at bugs.python.org  Mon Jan 22 21:03:13 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 02:03:13 +0000
Subject: [issue32627] Header dependent _uuid build failure on Fedora 27
In-Reply-To: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za>
Message-ID: <1516672993.18.0.467229070634.issue32627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reverting my previous commit doesn't fix the problem: if both uuid-devel and libuuid-devel are installed, then it reports that the necessary bits to build _uuid weren't found, without even attempting to compile it at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32627>
_______________________________________

From report at bugs.python.org  Mon Jan 22 21:11:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 02:11:27 +0000
Subject: [issue32620] [3.5] Travis CI fails on Python 3.5 with "pyenv: version
 `3.5' not installed"
In-Reply-To: <1516618613.48.0.467229070634.issue32620@psf.upfronthosting.co.za>
Message-ID: <1516673487.9.0.467229070634.issue32620@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I removed the snippet entirely from https://github.com/python/cpython/pull/5201, and while Travis didn't pass, it failed due to test suite failures, not anything environmental.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32620>
_______________________________________

From report at bugs.python.org  Mon Jan 22 21:14:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 02:14:51 +0000
Subject: [issue32620] [3.5] Travis CI fails on Python 3.5 with "pyenv: version
 `3.5' not installed"
In-Reply-To: <1516618613.48.0.467229070634.issue32620@psf.upfronthosting.co.za>
Message-ID: <1516673691.41.0.467229070634.issue32620@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch
pull_requests: +5118
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32620>
_______________________________________

From report at bugs.python.org  Mon Jan 22 21:14:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 02:14:51 +0000
Subject: [issue31568] Configure thinks it finds python3.5 but doesn't
In-Reply-To: <1506244521.37.0.0318133466802.issue31568@psf.upfronthosting.co.za>
Message-ID: <1516673691.49.0.574204596225.issue31568@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +5119

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31568>
_______________________________________

From report at bugs.python.org  Mon Jan 22 21:36:18 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 02:36:18 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516674978.31.0.467229070634.issue32513@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the ordering operators, my only question would be whether or not I can rely on them to act like functools.total_ordering: if I supply __eq__ and one of the ordering operators (e.g. __lt__), will dataclasses make sure the other three ordering operators are consistent with those base methods? Or will it bypass them and act directly on the underlying fields?

My suggestion would be to say that if any of __lt__, __le__, __gt__ or __ge__ are defined, then data classes will implicitly generate the other methods based on functools.total_ordering semantics, and will only reference the underlying fields directly if *none* of them are defined. Otherwise I can see folks defining a single method like "__lt__", and being surprised when they end up with inconsistent comparison behaviour.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 22 21:51:08 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 23 Jan 2018 02:51:08 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516675868.49.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Rather than re-implementing (and maintaining) functools.total_ordering semantics, I'd rather advise them to specify order=False and just use functools.total_ordering. It's an odd use case for dataclasses, anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 22 21:57:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 02:57:51 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516676271.96.0.467229070634.issue32513@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd be fine with that recommendation (since `@dataclass(order=False)` and `@total_ordering` will compose without any problems), but in that case I'd suggest having "order=True" + any of the ordering methods result in an exception (as you've proposed for frozen=True and the methods that it needs to override).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 22 22:01:12 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 23 Jan 2018 03:01:12 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1516676472.15.0.467229070634.issue32304@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Mon Jan 22 22:01:45 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 23 Jan 2018 03:01:45 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1516676505.19.0.467229070634.issue32502@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Mon Jan 22 22:02:15 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 23 Jan 2018 03:02:15 +0000
Subject: [issue32102] Add "capture_output=True" option to subprocess.run
In-Reply-To: <1511244827.04.0.213398074469.issue32102@psf.upfronthosting.co.za>
Message-ID: <1516676535.84.0.467229070634.issue32102@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32102>
_______________________________________

From report at bugs.python.org  Mon Jan 22 22:09:14 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 03:09:14 +0000
Subject: [issue32627] Header dependent _uuid build failure on Fedora 27
In-Reply-To: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za>
Message-ID: <1516676954.29.0.467229070634.issue32627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Reducing priority since "sudo dnf remove uuid-devel" is a straightforward workaround)

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32627>
_______________________________________

From report at bugs.python.org  Mon Jan 22 22:36:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 03:36:38 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516678598.2.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
pull_requests: +5120

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Mon Jan 22 23:10:39 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jan 2018 04:10:39 +0000
Subject: [issue27099] IDLE: turn built-in extensions into regular modules
In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za>
Message-ID: <1516680639.79.0.467229070634.issue27099@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think this should have been backported to 3.6.

This week, I'm teaching a class in Python3.6 and tab completion seems to be broken for everyone from a fresh install of 3.6.4 directly from www.python.org.  Also, the extension tab now shows ZzDummy.

----------
nosy: +rhettinger
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27099>
_______________________________________

From report at bugs.python.org  Mon Jan 22 23:14:42 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jan 2018 04:14:42 +0000
Subject: [issue27099] IDLE: turn built-in extensions into regular modules
In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za>
Message-ID: <1516680882.63.0.467229070634.issue27099@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Leaving this as closed.  Just wanted to note that it was a rough upgrade to 3.6.4 because of this backport.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27099>
_______________________________________

From report at bugs.python.org  Mon Jan 22 23:16:45 2018
From: report at bugs.python.org (Erik Paulson)
Date: Tue, 23 Jan 2018 04:16:45 +0000
Subject: [issue32628] Add configurable DirectoryIndex to http.server
Message-ID: <1516681005.05.0.467229070634.issue32628@psf.upfronthosting.co.za>


New submission from Erik Paulson <epaulson at unit1127.com>:

In http.server and SimpleHTTPRequestHandler - the send_head function is hard-coded to treat index.html and index.htm as files to return in a directory - if neither of those files are present, it lists the directory. 

It would be very nice to be able to specify other files to use as a directory index, similar to the DirectoryIndex directive from Apache.

I think it'd be straight forward to add some kind of list you could set, just like you can modify extensions_map to include other types of MIME types. 

Would it be OK to just add a directory_index list with index.html and index.htm on by default that people could do like
Handler.directory_index.append("index.htmlx") in their setup? Or would such an API be better with some kind of helper?

----------
components: Library (Lib)
messages: 310468
nosy: epaulson
priority: normal
severity: normal
status: open
title: Add configurable DirectoryIndex to http.server
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32628>
_______________________________________

From report at bugs.python.org  Mon Jan 22 23:32:07 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Jan 2018 04:32:07 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1516681927.87.0.467229070634.issue31860@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Postscript: I read a week or so ago that a new Windows 10 font chooser will have this feature.  There was not much detail and I believe it is currently only part of the Preview package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Tue Jan 23 00:42:17 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 05:42:17 +0000
Subject: [issue32296] Implement asyncio._get_running_loop() and
 get_event_loop() in C
In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za>
Message-ID: <1516686137.25.0.467229070634.issue32296@psf.upfronthosting.co.za>


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


----------
pull_requests: +5121

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32296>
_______________________________________

From report at bugs.python.org  Tue Jan 23 00:55:12 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 23 Jan 2018 05:55:12 +0000
Subject: [issue28716] Fractions instantiation revisited
In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za>
Message-ID: <1516686912.01.0.467229070634.issue28716@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Not sure if it's relevant for this specific change, but here's a benchmark that you could use for Fractions: issue22458

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28716>
_______________________________________

From report at bugs.python.org  Tue Jan 23 01:36:29 2018
From: report at bugs.python.org (Jack Branson)
Date: Tue, 23 Jan 2018 06:36:29 +0000
Subject: [issue32629] PyImport_ImportModule occasionally cause access violation
Message-ID: <1516689389.11.0.467229070634.issue32629@psf.upfronthosting.co.za>


New submission from Jack Branson <a1q123456 at gmail.com>:

I found that calling PyImport_ImportModule frequently may cause access violation error.

here is call stack:

00 0354f610 67d01605 00000001 00000020 0000007f python36!_PyObject_Alloc+0x5e [c:\build\cpython36\objects\obmalloc.c @ 1258]
01 (Inline) -------- -------- -------- -------- python36!PyObject_Malloc+0x18 [c:\build\cpython36\objects\obmalloc.c @ 479]
02 0354f638 67d18070 00000008 0000007f 67e541e0 python36!PyUnicode_New+0xf5 [c:\build\cpython36\objects\unicodeobject.c @ 1281]
03 0354f654 67d0963a 0354f69c 00000008 0000007f python36!_PyUnicodeWriter_PrepareInternal+0x60 [c:\build\cpython36\objects\unicodeobject.c @ 13534]
04 0354f6c0 67d02a66 67e541e0 00000008 00000000 python36!PyUnicode_DecodeUTF8Stateful+0xca [c:\build\cpython36\objects\unicodeobject.c @ 5034]
05 0354f6e4 67d59183 67e541e0 02a09db8 02a09de0 python36!PyUnicode_FromString+0x46 [c:\build\cpython36\objects\unicodeobject.c @ 2077]
06 (Inline) -------- -------- -------- -------- python36!PyImport_ImportModuleLevel+0xa [c:\build\cpython36\python\import.c @ 1652]
07 0354f704 67d5878f 02a09de0 02a09db8 02a09dd0 python36!PyImport_Import+0xe3 [c:\build\cpython36\python\import.c @ 1732]
08 0354f718 00478639 02a09dd0 7651129a 00000000 python36!PyImport_ImportModule+0x1f [c:\build\cpython36\python\import.c @ 1257]

pointer bp's value is 0x00000001, which is NULL + 1. In this case, `assert(bp != NULL)` will not let application crash for assert failure, and application will continue run until the line `pool->freeblock = *(block **)bp` which is defrencing bp, causes access violation.

0:009> .frame 0
00 0354f610 67d01605 python36!_PyObject_Alloc+0x5e [c:\build\cpython36\objects\obmalloc.c @ 1258]
0:009> r
eax=67ecfeb8 ebx=00000021 ecx=02a09000 edx=00000000 esi=00000001 edi=00000001
eip=67cdda4e esp=0354f5f8 ebp=0354f610 iopl=0         nv up ei pl nz na pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010207
python36!_PyObject_Alloc+0x5e:
67cdda4e 8b06            mov     eax,dword ptr [esi]  ds:002b:00000001=????????
0:009> dv
     use_calloc = 0n0
          nelem = 1
         elsize = <value unavailable>
         nbytes = 0x21
           pool = 0x02a09000
           size = 4
           next = 0x67ecfeb8
             bp = 0x00000001 "--- memory read error at address 0x00000001 ---"
         result = <value unavailable>
  usable_arenas = <value unavailable>


/*
             * There is a used pool for this size class.
             * Pick up the head block of its free list.
             */
            ++pool->ref.count;
            bp = pool->freeblock;
            assert(bp != NULL);
            if ((pool->freeblock = *(block **)bp) != NULL) {
                UNLOCK();
                if (use_calloc)
                    memset(bp, 0, nbytes);
                return (void *)bp;
            }
            /*

----------
components: ctypes
messages: 310471
nosy: Jack Branson
priority: normal
severity: normal
status: open
title: PyImport_ImportModule occasionally cause access violation
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32629>
_______________________________________

From report at bugs.python.org  Tue Jan 23 01:56:55 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 06:56:55 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
Message-ID: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

PEP 567 allows decimal to be safely used in async/await code.

I couldn't observe any performance impact by the proposed PR.  The PR doesn't modify decimal context behaviour: instead of using a thread-local storage it now uses a context variable.

----------
components: Library (Lib)
messages: 310472
nosy: gvanrossum, inada.naoki, skrah, vstinner, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Migrate decimal to use PEP 567 context variables
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Tue Jan 23 01:57:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Jan 2018 06:57:24 +0000
Subject: [issue32631] IDLE: revise zzdummy.py
Message-ID: <1516690644.63.0.467229070634.issue32631@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

zzdummy.py is needed for properly testing the extension mechanism.  It is intended to provide an example extension for users to follow.  When completed, enabled, and invoked, it will prefix every line of a window with some text, or remove the prefix from every line.  It would be even better to make it respect selections, as other format options do.

Needed: more comments, including what it does when enabled; docstring for z_in_event; uncomment z_in_event; code for z_out_event.

Should the extension have a different name? ZzTestExample? ZzIgnoreThis?  Changing an extension name would normally be a bad idea, as it would disable any customizations.  But I think we could do it for this one if desired.

The default insertion text could be more informative: for instance, 'ignore this' or 'see-doc' or #ignore#.  The last would make it a configurable comment/uncomment.  Normally, changing a default is a no-no, as it can mess up user configurations.  But since the current text is inoperative, this should not matter here.

The menu defs are commented out because enabling the extension currently has no effect, so the menu entries would be useless.

***There should be help text for the extension tab explaining the presence and operation of the extension.  (This should have  been done already.)

Extension tests, last revised in #31480, will likely need more changes.

----------
assignee: terry.reedy
components: IDLE
messages: 310473
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: revise zzdummy.py
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32631>
_______________________________________

From report at bugs.python.org  Tue Jan 23 01:58:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 06:58:37 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516690717.88.0.467229070634.issue32630@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5122

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:00:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 07:00:05 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516690805.48.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 83c8675edb4fe278c5d930f7865977a5d3c7168a by Yury Selivanov in branch 'master':
bpo-32436: Remove a redundant assert (#5275)
https://github.com/python/cpython/commit/83c8675edb4fe278c5d930f7865977a5d3c7168a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:10:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Jan 2018 07:10:19 +0000
Subject: [issue27099] IDLE: turn built-in extensions into regular modules
In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za>
Message-ID: <1516691419.85.0.467229070634.issue27099@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

These patches were first released with the 3.6.3 release candidate.  Nothing was changed for 3.6.4.  Rechecking the changes to autocomplete.py in PR 2494, the only expected effect, after the followup in #31488, PR 3612, is that changes to the popup wait time should take effect immediately instead of sometime later.  I considered making this happen for the 'extension' features, as with with other features, a type of bugfix.

If you have an issue with completions, other than those listed in #27609, please open a new issue.

I know zzdummy is listed.  An explanation that it is there for testing and example should have been added to the [Help] buttom text for the extension tab.  I opened #32631 for this and possible changes to zzdummy.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27099>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:24:45 2018
From: report at bugs.python.org (Sergey)
Date: Tue, 23 Jan 2018 07:24:45 +0000
Subject: [issue32632] Mock does not create deepcopy of mutable args
Message-ID: <1516692285.74.0.467229070634.issue32632@psf.upfronthosting.co.za>


New submission from Sergey <sergejyit at gmail.com>:

MagicMock allows to check parameters of calls by using "assert_has_calls". However it fails if argument has a mutable type and was changed in-place before the second call.

The example is provided in attached file.

In "func1" value in "data" changes for each iteration and as result:
call_args_list contains two same calls.
In "func2" variable "data" generates by function "get_dict" and in this case call_args_list contains correct values.

Obviously it happens because class _Call (https://github.com/python/cpython/blob/3.5/Lib/unittest/mock.py#L1929) does not create a deepcopy of call args/kwargs.

Will it be correct to add deep_copy logic in mock.py ? or may be it's wrong to use logic like in "func1"? 
I see only one disadvantage of using deepcopy: it will become slower.

----------
components: Tests
files: test.py
messages: 310476
nosy: michael.foord, skraynev
priority: normal
severity: normal
status: open
title: Mock does not create deepcopy of mutable args
versions: Python 3.5
Added file: https://bugs.python.org/file47401/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32632>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:27:01 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 23 Jan 2018 07:27:01 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516692421.3.0.467229070634.issue32612@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Arguably, a WindowsPath instance only represents the *path* and not the file located by the path. So the programmer has to take just as much responsibility as if they were using plain strings, except there are some conveniences added to make those strings easier to manage.

I don't see anything in the docs suggesting that a Path instances have file-identity (that is, two Path objects are always equal if they refer to the same file). Even the "resolve()" method doesn't pretend to get the exact filename.

The best option for true comparison is to use stat() and compare st_inode and st_dev. Lacking that, doing a good enough job of case folding is better than ignoring it, as most workarounds are likely to do a worse job (e.g., they won't even correct for "A"=="B\..\A", let alone casing).

If you have a specific suggestion for how comparison could be improved here without having to go to kernel mode, feel free to make it. Unfortunately, your two suggestions here are not workable.

(And yes, PurePosixPath and "import posixpath" are the right way to handle case-sensitive paths explicitly, which is why they're available on all platforms.)

----------
type: security -> enhancement
versions: +Python 3.8 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:28:09 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 23 Jan 2018 07:28:09 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516692489.52.0.467229070634.issue30491@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
keywords: +patch
pull_requests: +5123
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:43:08 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 23 Jan 2018 07:43:08 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
Message-ID: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

The test_asyncio tests are generating some warnings:

0:00:00 load avg: 2.14 [1/1] test_asyncio.test_tasks
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_exception_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_result_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_exception_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_result_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
1 test OK.

It looks like these have been here for a while. Easy to fix though.

----------
components: Tests, asyncio
messages: 310478
nosy: asvetlov, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: Warnings from test_asyncio.test_tasks.SetMethodsTest
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:44:08 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 23 Jan 2018 07:44:08 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
In-Reply-To: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>
Message-ID: <1516693448.95.0.467229070634.issue32633@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
keywords: +patch
pull_requests: +5124
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:55:57 2018
From: report at bugs.python.org (benrg)
Date: Tue, 23 Jan 2018 07:55:57 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516694157.3.0.467229070634.issue32612@psf.upfronthosting.co.za>


benrg <benrudiak at gmail.com> added the comment:

This bug is about paths that compare *equal*, but refer to *different* files. I agree that the opposite is not much of a problem (and I said so in the original comment).

The reason I classified this as a security bug is that Python scripts using pathlib on Windows could be vulnerable in certain cases to an attacker that can choose file names. For example, the order in which paths are added to a set or dict could affect which of two files is seen by the script. If different parts of the script add files in different orders - which would normally be safe - the result could be similar to a TOCTTOU race.

I don't disagree that "doing a good enough job of case folding is better than ignoring it." I just think that pathlib should not case-fold strings that Windows filesystems don't.

----------
nosy: +pitrou
type: enhancement -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:09:40 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 23 Jan 2018 08:09:40 +0000
Subject: [issue32299] unittest.mock.patch.dict.__enter__ should return the dict
In-Reply-To: <1513148900.41.0.213398074469.issue32299@psf.upfronthosting.co.za>
Message-ID: <1516694980.31.0.467229070634.issue32299@psf.upfronthosting.co.za>


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


----------
nosy: +michael.foord, rbcollins
versions:  -Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32299>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:15:07 2018
From: report at bugs.python.org (benrg)
Date: Tue, 23 Jan 2018 08:15:07 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516695307.38.0.467229070634.issue32612@psf.upfronthosting.co.za>


benrg <benrudiak at gmail.com> added the comment:

I don't know whether this clarifies it at all, but if x and y are Path objects, and x == y, I would expect also x.exists() == y.exists(), and x.read_bytes() == y.read_bytes(), and so on, unless there is a race condition. I think all programmers expect that if x == y, then they refer to the same file. This is not true currently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:20:06 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 23 Jan 2018 08:20:06 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516695606.24.0.467229070634.issue32612@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

(FWIW, I don't think your "security" argument is going to be very convincing, as this problem has been around for far too long to be treated as suddenly urgent. But up to you.)

My fear is that if PureWindowsPath stops handling the >90% of cases it currently does (by making "Path"!="path"), then we'll see developers implement their own workarounds, most likely by replacing:

    my_set.add(p)

with:

    my_dict[str(p).lower()] = p

This doesn't improve anything, and actually regresses it as I pointed out, so removing case folding cannot be the answer.

That leaves finding a better way to obtain hashes and comparisons for PureWindowsPath instances (note that all the functionality that appears to be at issue is inherited by WindowsPath, so there's presumably nothing to fix there). My initial guess would be that some combination of locale and flags to LcMapStringEx will give us a better sort key than .lower(), though I don't know what that combination is. The $UpCase file is not accessible directly, so that isn't any help.

I have heard that .upper() is considered to be "more accurate" for NTFS than .lower(), but have no confirmation. Calling stat is not an option for PureWindowsPath, so I'm running out of ideas on how to improve it.

Perhaps the best answer is to add a note to the docs warning about this and suggesting not using pathlib if you are concerned? And document the stat() method, or maybe offer some way to integrate with filecmp?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:25:54 2018
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Jan 2018 08:25:54 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516695954.37.0.467229070634.issue32630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I'll take a look.

----------
assignee:  -> skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:27:00 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 23 Jan 2018 08:27:00 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516696020.26.0.467229070634.issue32612@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> I think all programmers expect that if x == y, then they refer to the same file. This is not true currently.

Perhaps, but you could equally say that they expect that if x != y then they refer to different files, which is also not true. So do we optimise for the false positive or the false negative? It really depends on what operation you are doing, and so it has to be left in the hands of the developer.

Currently, we have a cheap comparison that minimises both without preventing either. The only option for PureWindowsPath is to prevent false positives (== always means same file), at the cost of causing so many false negatives that I suspect most developers would simply roll their own equality comparison. That's not the status quo, and especially for a behaviour that has been shipping for a few years without significant problems, changing the status quo that dramatically requires a more compelling case than has been presented so far.

If there are ways we can reduce the false positives without increasing the false negatives, then let's do it. But pragmatically, we should balance both, and leave the "perfect" comparisons to other methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:30:53 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 23 Jan 2018 08:30:53 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516696253.84.0.467229070634.issue32612@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Just tested something that I'd assumed and it turned out I was wrong:

>>> p1 = PureWindowsPath(r"C:\a\b\..\c")
>>> p2 = PureWindowsPath(r"C:\a\c")
>>> p1 == p2
False
>>> p1, p2
(PureWindowsPath('C:/a/b/../c'), PureWindowsPath('C:/a/c'))

So PureWindowsPath already doesn't collapse '..' elements (as they could change meaning in the presence of symlinks), so that's a point against the "what if everyone started doing str(p1).lower() == str(p2).lower() instead" argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:31:16 2018
From: report at bugs.python.org (Maxim Barabanov)
Date: Tue, 23 Jan 2018 08:31:16 +0000
Subject: [issue32634] Message parsing fails where it has incompele headers
Message-ID: <1516696276.33.0.467229070634.issue32634@psf.upfronthosting.co.za>


New submission from Maxim Barabanov <maxim.barabanov at gmail.com>:

If email message dont have a content-transfer-encoding or content-type header, function write in generator.py crashes

----------
components: email
messages: 310485
nosy: barry, r.david.murray, reb00ter
priority: normal
severity: normal
status: open
title: Message parsing fails where it has incompele headers
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32634>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:32:00 2018
From: report at bugs.python.org (Maxim Barabanov)
Date: Tue, 23 Jan 2018 08:32:00 +0000
Subject: [issue32634] Message parsing fails where it has incompele headers
In-Reply-To: <1516696276.33.0.467229070634.issue32634@psf.upfronthosting.co.za>
Message-ID: <1516696320.26.0.467229070634.issue32634@psf.upfronthosting.co.za>


Change by Maxim Barabanov <maxim.barabanov at gmail.com>:


----------
keywords: +patch
pull_requests: +5125
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32634>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:35:22 2018
From: report at bugs.python.org (Maxim Barabanov)
Date: Tue, 23 Jan 2018 08:35:22 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
 available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1516696522.9.0.467229070634.issue3264@psf.upfronthosting.co.za>


Change by Maxim Barabanov <maxim.barabanov at gmail.com>:


----------
pull_requests: +5126

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:51:40 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 23 Jan 2018 08:51:40 +0000
Subject: [issue32391] Add StreamWriter.wait_closed()
In-Reply-To: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za>
Message-ID: <1516697500.41.0.467229070634.issue32391@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +5127
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32391>
_______________________________________

From report at bugs.python.org  Tue Jan 23 04:09:37 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 23 Jan 2018 09:09:37 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
In-Reply-To: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>
Message-ID: <1516698577.93.0.467229070634.issue32633@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 6934831e43d66222a626403dd775429d1c8963f3 by Andrew Svetlov (Nathaniel J. Smith) in branch 'master':
bpo-32633: Fix some warnings in test_asyncio.test_tasks (#5280)
https://github.com/python/cpython/commit/6934831e43d66222a626403dd775429d1c8963f3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 04:10:17 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 23 Jan 2018 09:10:17 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
In-Reply-To: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>
Message-ID: <1516698617.8.0.467229070634.issue32633@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 04:10:45 2018
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 23 Jan 2018 09:10:45 +0000
Subject: [issue32620] [3.5] Travis CI fails on Python 3.5 with "pyenv: version
 `3.5' not installed"
In-Reply-To: <1516618613.48.0.467229070634.issue32620@psf.upfronthosting.co.za>
Message-ID: <1516698645.98.0.467229070634.issue32620@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 4a4c2743133e195cc3725b78a895d85d69e50089 by larryhastings (Nick Coghlan) in branch '3.5':
[3.5] bpo-32620: Remove failing pyenv call from CI config (#5274)
https://github.com/python/cpython/commit/4a4c2743133e195cc3725b78a895d85d69e50089


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32620>
_______________________________________

From report at bugs.python.org  Tue Jan 23 04:31:13 2018
From: report at bugs.python.org (Michael Foord)
Date: Tue, 23 Jan 2018 09:31:13 +0000
Subject: [issue32632] Mock does not create deepcopy of mutable args
In-Reply-To: <1516692285.74.0.467229070634.issue32632@psf.upfronthosting.co.za>
Message-ID: <1516699873.94.0.467229070634.issue32632@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

There are several disadvantages to doing deepcopy:

* identity checks now fail
* deep copying is slow
* deep copying doesn't work on arbitrary objects

So deep copying by default isn't a good idea. This particular case is mentioned in the docs, with an example of a deep-copying mock if you need one.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32632>
_______________________________________

From report at bugs.python.org  Tue Jan 23 04:35:32 2018
From: report at bugs.python.org (Michael Foord)
Date: Tue, 23 Jan 2018 09:35:32 +0000
Subject: [issue32299] unittest.mock.patch.dict.__enter__ should return the dict
In-Reply-To: <1513148900.41.0.213398074469.issue32299@psf.upfronthosting.co.za>
Message-ID: <1516700132.36.0.467229070634.issue32299@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This seems like a reasonable feature request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32299>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:22:07 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 23 Jan 2018 10:22:07 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
Message-ID: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Currently in Fedora glibc stopped providing libcrypt[0] a change which is slowly being upstreamed as well[1] in favor of the libxcrypt project[2].

This causes a segfault when importing the crypt module as python assumes that crypt.h is always available.

Providing a working patch from the libxcrypt maintainer. I'll convert the patch into a PR.

[0] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
[1] https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
[2] https://github.com/besser82/libxcrypt

----------
files: 00290-cryptmodule-Include-crypt.h-for-declaration-of-crypt.patch
keywords: patch
messages: 310490
nosy: cstratak
priority: normal
severity: normal
status: open
title: test_crypt segfaults when using libxcrypt instead of libcrypt
Added file: https://bugs.python.org/file47402/00290-cryptmodule-Include-crypt.h-for-declaration-of-crypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:24:46 2018
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 23 Jan 2018 10:24:46 +0000
Subject: [issue32563] -Werror=declaration-after-statement expat build failure
 on Python 3.5
In-Reply-To: <1516079681.55.0.467229070634.issue32563@psf.upfronthosting.co.za>
Message-ID: <1516703086.29.0.467229070634.issue32563@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 57fa0ab8911a70d91e5b60b8dc91f1085442a9e7 by larryhastings (Nick Coghlan) in branch '3.5':
[3.5] bpo-32563: Get expat to compile under C89 (#5201)
https://github.com/python/cpython/commit/57fa0ab8911a70d91e5b60b8dc91f1085442a9e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:28:23 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 23 Jan 2018 10:28:23 +0000
Subject: [issue32634] Message parsing fails where it has incompele headers
In-Reply-To: <1516696276.33.0.467229070634.issue32634@psf.upfronthosting.co.za>
Message-ID: <1516703303.77.0.467229070634.issue32634@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Looks like a dupe of Issue 27321

----------
nosy: +martin.panter
resolution:  -> duplicate
superseder:  -> Email parser creates a message object that can't be flattened

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32634>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:28:26 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 23 Jan 2018 10:28:26 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516703306.66.0.467229070634.issue32635@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:28:39 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 23 Jan 2018 10:28:39 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516703319.55.0.467229070634.issue32635@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:47:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 10:47:09 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
In-Reply-To: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>
Message-ID: <1516704429.12.0.467229070634.issue32633@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

FYI "x86 Gentoo Refleaks 3.x" buildbot failed with:

http://buildbot.python.org/all/#builders/1/builds/109
---
/buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/test/libregrtest/refleak.py:248: RuntimeWarning: coroutine 'SetMethodsTest.test_set_exception_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
/buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/test/libregrtest/refleak.py:248: RuntimeWarning: coroutine 'SetMethodsTest.test_set_result_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
.
test_asyncio leaked [2, 2, 1] memory blocks, sum=5
1 test failed again:
    test_asyncio
---

This build ran before the commit 6934831e43d66222a626403dd775429d1c8963f3. So I understand that the bug was already fixed: thanks!

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:48:14 2018
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 23 Jan 2018 10:48:14 +0000
Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files
In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za>
Message-ID: <1516704494.0.0.467229070634.issue29319@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 891c91d8d38848377a9f475242507510873eb9c3 by larryhastings (Nick Coghlan) in branch '3.5':
[3.5] bpo-32551: Consistently configure sys.path[0] (#5197)
https://github.com/python/cpython/commit/891c91d8d38848377a9f475242507510873eb9c3


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29319>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:48:14 2018
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 23 Jan 2018 10:48:14 +0000
Subject: [issue32551] Zipfile & directory execution in 3.5.4 also adds the
 parent directory to sys.path
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516704494.23.0.714561066657.issue32551@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 891c91d8d38848377a9f475242507510873eb9c3 by larryhastings (Nick Coghlan) in branch '3.5':
[3.5] bpo-32551: Consistently configure sys.path[0] (#5197)
https://github.com/python/cpython/commit/891c91d8d38848377a9f475242507510873eb9c3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:52:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 10:52:33 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516704753.08.0.467229070634.issue32593@psf.upfronthosting.co.za>


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


----------
pull_requests: +5128

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Tue Jan 23 06:21:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 11:21:13 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
Message-ID: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

(1) test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests.test_wait_with_exception() hangs:

vstinner at apu$ PYTHONASYNCIODEBUG=1 ./python -m test test_asyncio -m test_wait_with_exception -v
== CPython 3.7.0a4+ (heads/freebsd_configure:27218edef7, Jan 23 2018, 11:52:08) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)]
== Linux-4.14.13-300.fc27.x86_64-x86_64-with-fedora-27-Twenty_Seven little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_24675
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.37 [1/1] test_asyncio
test_wait_with_exception (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests) ... /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:1009: RuntimeWarning: coroutine 'sleep' was never awaited
Coroutine created at (most recent call last)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 1021, in test_wait_with_exception
    loop.run_until_complete(self.new_task(loop, foo()))
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 423, in run_until_complete
    self.run_forever()
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 391, in run_forever
    self._run_once()
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/utils.py", line 454, in _run_once
    super()._run_once()
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 1521, in _run_once
    handle._run()
  File "/home/vstinner/prog/python/master/Lib/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2289, in _step
    return super()._step(*args)
  File "/home/vstinner/prog/python/master/Lib/asyncio/coroutines.py", line 61, in send
    return self.gen.send(value)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 1009, in sleeper
    yield from asyncio.sleep(0.15, loop=loop)
  yield from asyncio.sleep(0.15, loop=loop)


(2) 43 failures and 55 errors:

ERROR: test_context_manager (test.test_asyncio.test_locks.ConditionTests)
ERROR: test_context_manager (test.test_asyncio.test_locks.LockTests)
ERROR: test_context_manager_cant_reuse (test.test_asyncio.test_locks.LockTests)
ERROR: test_lock (test.test_asyncio.test_locks.LockTests)
ERROR: test_lock_by_with_statement (test.test_asyncio.test_locks.LockTests)
ERROR: test_repr (test.test_asyncio.test_locks.LockTests)
ERROR: test_context_manager (test.test_asyncio.test_locks.SemaphoreTests)
ERROR: test_semaphore (test.test_asyncio.test_locks.SemaphoreTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_foobar (test.test_asyncio.test_tasks.CTask_Future_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_await_old_style_coro (test.test_asyncio.test_tasks.CompatibilityTests)
ERROR: test_yield_from_awaitable (test.test_asyncio.test_tasks.CompatibilityTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_run_coroutine_threadsafe (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
ERROR: test_run_coroutine_threadsafe_task_cancelled (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
ERROR: test_run_coroutine_threadsafe_with_exception (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
ERROR: test_sleep_zero (test.test_asyncio.test_tasks.SleepTests)
FAIL: test_default_exc_handler_coro (test.test_asyncio.test_base_events.BaseEventLoopTests)
FAIL: test_nonstream_socket (test.test_asyncio.test_base_events.BaseLoopSendfileTests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_run_coroutine_threadsafe_task_factory_exception (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
FAILED (failures=43, errors=55, skipped=5)

These errors can be reproduced using attached fails file:

PYTHONASYNCIODEBUG=1 ./python -m test -v test_asyncio --matchfile=fails


Note: I found these issue when trying to run the full Python test suite using -X dev.

----------
components: Tests, asyncio
files: fails
messages: 310496
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio fails with PYTHONASYNCIODEBUG=1
versions: Python 3.7
Added file: https://bugs.python.org/file47403/fails

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 06:21:23 2018
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 23 Jan 2018 11:21:23 +0000
Subject: [issue32072] Issues with binary plists
In-Reply-To: <1511031976.48.0.213398074469.issue32072@psf.upfronthosting.co.za>
Message-ID: <1516706483.3.0.467229070634.issue32072@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 43f014d3f12468edf61046f0612edc7660042fd5 by larryhastings (Serhiy Storchaka) in branch '3.5':
[3.5] bpo-32072: Fix issues with binary plists. (GH-4455) (#4656)
https://github.com/python/cpython/commit/43f014d3f12468edf61046f0612edc7660042fd5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32072>
_______________________________________

From report at bugs.python.org  Tue Jan 23 06:21:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 11:21:38 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516706498.55.0.467229070634.issue32636@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I used this change to skip the test which hangs, (1):

diff --git a/Lib/test/test_asyncio/test_tasks.py b/Lib/test/test_asyncio/test_tasks.py
index 1c361c8ec1..cf01df7061 100644
--- a/Lib/test/test_asyncio/test_tasks.py
+++ b/Lib/test/test_asyncio/test_tasks.py
@@ -991,7 +991,7 @@ class BaseTaskTests:
         loop.advance_time(10)
         loop.run_until_complete(asyncio.wait([a, b], loop=loop))
 
-    def test_wait_with_exception(self):
+    def Xtest_wait_with_exception(self):
 
         def gen():
             when = yield

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 06:24:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 11:24:37 +0000
Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental
 variable should not override -b / -bb command line options
In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za>
Message-ID: <1516706677.78.0.467229070634.issue20361@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20361>
_______________________________________

From report at bugs.python.org  Tue Jan 23 06:24:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 11:24:45 +0000
Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental
 variable should not override -b / -bb command line options
In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za>
Message-ID: <1516706685.39.0.467229070634.issue20361@psf.upfronthosting.co.za>


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


----------
pull_requests: +5129

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20361>
_______________________________________

From report at bugs.python.org  Tue Jan 23 07:14:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 12:14:10 +0000
Subject: [issue32593] Drop support of FreeBSD 9 and older in Python 3.7
In-Reply-To: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>
Message-ID: <1516709650.53.0.467229070634.issue32593@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 872f841b122160987845db8fdddfaee1aaa203f1 by Victor Stinner in branch 'master':
bpo-32593: Run autoconf (#5282)
https://github.com/python/cpython/commit/872f841b122160987845db8fdddfaee1aaa203f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Tue Jan 23 07:15:43 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 23 Jan 2018 12:15:43 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516709743.79.0.467229070634.issue32635@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
pull_requests: +5130
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Tue Jan 23 07:30:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 12:30:55 +0000
Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental
 variable should not override -b / -bb command line options
In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za>
Message-ID: <1516710655.72.0.467229070634.issue20361@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset dc6b9462c00873c8404a7966b7ca210717718af5 by Victor Stinner in branch 'master':
bpo-20361: Remove workaround for a now fixed bug (#5283)
https://github.com/python/cpython/commit/dc6b9462c00873c8404a7966b7ca210717718af5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20361>
_______________________________________

From report at bugs.python.org  Tue Jan 23 07:42:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 12:42:33 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516711353.72.0.467229070634.issue32635@psf.upfronthosting.co.za>


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


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Tue Jan 23 09:34:20 2018
From: report at bugs.python.org (David CARLIER)
Date: Tue, 23 Jan 2018 14:34:20 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516718060.47.0.467229070634.issue32493@psf.upfronthosting.co.za>


David CARLIER <devnexen at gmail.com> added the comment:

In OpenBSD it s even "worse", the version for each call is random (not a surprise when looking at the source). The question is, do we go back to support only AIX or do we accept somehow wrong version ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Tue Jan 23 09:50:53 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 23 Jan 2018 14:50:53 +0000
Subject: [issue32618] fix test_codeccallbacks.test_mutatingdecodehandler
In-Reply-To: <1516602509.19.0.467229070634.issue32618@psf.upfronthosting.co.za>
Message-ID: <1516719053.33.0.467229070634.issue32618@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 370d04d1dcca50a52d59f40aff4d11434f71df6b by Xiang Zhang in branch 'master':
bpo-32618: Fix test_mutatingdecodehandler not testing test.mutating (#5269)
https://github.com/python/cpython/commit/370d04d1dcca50a52d59f40aff4d11434f71df6b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32618>
_______________________________________

From report at bugs.python.org  Tue Jan 23 09:51:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Jan 2018 14:51:07 +0000
Subject: [issue32618] fix test_codeccallbacks.test_mutatingdecodehandler
In-Reply-To: <1516602509.19.0.467229070634.issue32618@psf.upfronthosting.co.za>
Message-ID: <1516719067.65.0.467229070634.issue32618@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5131

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32618>
_______________________________________

From report at bugs.python.org  Tue Jan 23 10:11:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 15:11:27 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516720286.99.0.467229070634.issue32635@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset e768c86ef442ef89004089a8a34ce5909ffb90f2 by Victor Stinner (stratakis) in branch 'master':
 bpo-32635: Fix a segfault when importing the crypt module with libxcrypt. (#5284)
https://github.com/python/cpython/commit/e768c86ef442ef89004089a8a34ce5909ffb90f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Tue Jan 23 10:47:18 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 23 Jan 2018 15:47:18 +0000
Subject: [issue32618] fix test_codeccallbacks.test_mutatingdecodehandler
In-Reply-To: <1516602509.19.0.467229070634.issue32618@psf.upfronthosting.co.za>
Message-ID: <1516722438.35.0.467229070634.issue32618@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 6abbf14a876ee1e04d1493bb27025f2f0aa56430 by Xiang Zhang (Miss Islington (bot)) in branch '3.6':
bpo-32618: Fix test_mutatingdecodehandler not testing test.mutating (GH-5269) (#5285)
https://github.com/python/cpython/commit/6abbf14a876ee1e04d1493bb27025f2f0aa56430


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32618>
_______________________________________

From report at bugs.python.org  Tue Jan 23 11:09:51 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 23 Jan 2018 16:09:51 +0000
Subject: [issue32618] fix test_codeccallbacks.test_mutatingdecodehandler
In-Reply-To: <1516602509.19.0.467229070634.issue32618@psf.upfronthosting.co.za>
Message-ID: <1516723791.37.0.467229070634.issue32618@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32618>
_______________________________________

From report at bugs.python.org  Tue Jan 23 11:32:16 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 16:32:16 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516725136.37.0.467229070634.issue32636@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Nathaniel, this is is a regression of fc2f407829d9817ddacccae6944dd0879cfaca24 -- bpo-32591: Add native coroutine origin tracking.

Please take a look.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 11:33:27 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Jan 2018 16:33:27 +0000
Subject: [issue31930] IDLE: Pressing "Home" on Windows places cursor before
 ">>>"
In-Reply-To: <1509660581.35.0.213398074469.issue31930@psf.upfronthosting.co.za>
Message-ID: <1516725207.17.0.467229070634.issue31930@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#17060 and #18444 are similar issues for Mac.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31930>
_______________________________________

From report at bugs.python.org  Tue Jan 23 11:41:58 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 16:41:58 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
In-Reply-To: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>
Message-ID: <1516725718.43.0.467229070634.issue32633@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I don't think that 6934831e43d66222a626403dd775429d1c8963f3 can address the leak in any way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 11:46:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 16:46:49 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516726009.51.0.467229070634.issue30491@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'd like to see benchmarks of coroutine creation time and awaits with and without the proposed patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Tue Jan 23 11:56:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 16:56:05 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
In-Reply-To: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>
Message-ID: <1516726565.65.0.467229070634.issue32633@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

However I ran the whole asyncio test suite in reftracking mode on my machine (latest master) and it passed.  So I guess this issue is indeed closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:16:40 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jan 2018 17:16:40 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516727800.69.0.467229070634.issue32612@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Maybe we could at least mention the issue (and perhaps link to samefile) in the "General Properties" section?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:16:49 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 17:16:49 +0000
Subject: [issue32637] Android: set sys.platform and os.name to android
Message-ID: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Currently, sys.platform and os.name are equal to 'linux' on Android. While Android uses the Linux kernel, the operating system is not a regular Linux. The libc (bionic) is very different than the regular glibc, the filesystem is organized very differently, etc.

I propose to change sys.platform and os.name to 'android' when running on Android.

----------
components: Library (Lib)
messages: 310511
nosy: vstinner, xdegaye
priority: normal
severity: normal
status: open
title: Android: set sys.platform and os.name to android
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:18:35 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jan 2018 17:18:35 +0000
Subject: [issue32612] pathlib.(Pure)WindowsPaths can compare equal but refer
 to different files
In-Reply-To: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>
Message-ID: <1516727915.56.0.467229070634.issue32612@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Could WindowsPath (as opposed to PureWindowsPath) call samefile as part of the equality test?  (I'm not familiar enough with pathlib to know if that is a nonsense question.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:33:32 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jan 2018 17:33:32 +0000
Subject: [issue27321] Email parser creates a message object that can't be
 flattened
In-Reply-To: <1465930372.53.0.0254623453508.issue27321@psf.upfronthosting.co.za>
Message-ID: <1516728812.64.0.467229070634.issue27321@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note: I reviewed this a while ago but the review comments haven't been addressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27321>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:33:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 17:33:55 +0000
Subject: [issue32633] Warnings from test_asyncio.test_tasks.SetMethodsTest
In-Reply-To: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>
Message-ID: <1516728835.31.0.467229070634.issue32633@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I don't think that 6934831e43d66222a626403dd775429d1c8963f3 can address the leak in any way.

If a coroutine lives longer than expected, its refcount may be decreased after regrtest checks the total reference counter.

Anyway, it's not a big deal. If the bug comes back, trust me, I will bug you again :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:34:20 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jan 2018 17:34:20 +0000
Subject: [issue32634] Message parsing fails where it has incompele headers
In-Reply-To: <1516696276.33.0.467229070634.issue32634@psf.upfronthosting.co.za>
Message-ID: <1516728860.76.0.467229070634.issue32634@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, it is.

----------
stage: patch review -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32634>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:38:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 17:38:53 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516729133.81.0.467229070634.issue32637@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Wait, os.name is 'posix' on Android. That's fine in fact. Only sys.platform should be updated.

----------
title: Android: set sys.platform and os.name to android -> Android: set sys.platform to android

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 13:20:03 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 23 Jan 2018 18:20:03 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516731603.31.0.467229070634.issue32636@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Huh, weird. I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 13:52:13 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 23 Jan 2018 18:52:13 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1516733533.3.0.467229070634.issue11191@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

Just tested the patch presented.

For Python3-3.6.4 the patch in PR-5206 works as is, however, for Python3-3.5.4 - the patch to Lib/test/support/__init__.py does not work.

So, for Python3-3.5, Python3-3.6 and Python3-master - the test test_search_cpp is resolved.

As that is the "literal" question here - I am removing the patch to Lib/test/support/__init__.py so that the same tests fail (for different reasons). I'll open a new issue for these tests - so that this PR can be applied to all current Python3 branches (and skip the test_search_cpp test when the compiler is not gcc on AIX).

HTH!

----------
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Tue Jan 23 14:39:08 2018
From: report at bugs.python.org (pmpp)
Date: Tue, 23 Jan 2018 19:39:08 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516736348.1.0.467229070634.issue32637@psf.upfronthosting.co.za>


Change by pmpp <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:06:26 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 23 Jan 2018 20:06:26 +0000
Subject: [issue32638] distutils test errors with AIX and xlc
Message-ID: <1516737985.98.0.467229070634.issue32638@psf.upfronthosting.co.za>


New submission from Michael Felt <michael at felt.demon.nl>:

While working in issue11191 I found a fix for Python3-3.6 and later for the following tests, and later - but not for Python3-3.5

I suppose "we" could ignore the error on Python3-3.5 (as I then have a quick - simple - fix for Python3-3.6 and later.

Suggestions, rather - how important are the tests on Python3-3.5?

++++++++++++++++

root at x066:[/data/prj/python/git/x066-python3-3.7]nohup ./python Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

root at x066:[/data/prj/python/python3-3.6.4]nohup ./python ../src/python3-3.6.4/Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

root at x066:[/data/prj/python/python3-3.5.4]nohup ./python Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
FAIL: test_sysconfig_compiler_vars (distutils.tests.test_sysconfig.SysconfigTestCase)
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)

----------
components: Distutils
messages: 310519
nosy: Michael.Felt, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils test errors with AIX and xlc
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32638>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:10:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 20:10:06 +0000
Subject: [issue32296] Implement asyncio._get_running_loop() and
 get_event_loop() in C
In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za>
Message-ID: <1516738205.99.0.467229070634.issue32296@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 9d411c119fdd8e42209ec16be27686a843507f18 by Yury Selivanov in branch 'master':
bpo-32296: Make get_running_loop() another 4-5x faster (#5277)
https://github.com/python/cpython/commit/9d411c119fdd8e42209ec16be27686a843507f18


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32296>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:19:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 20:19:20 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516738760.61.0.467229070634.issue32410@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Andrew, test_cancel2 test fails 1 out of 10 times on my machine (log below).  Could you please take a look?

Also, can you rename sendfile tests to 'test_sock_sendfile_*'?


{pydev} ~/d/p/cpython (master %) ? ./python.exe -m test test_asyncio -v -m test_cancel2
== CPython 3.7.0a4+ (heads/master:9d411c119f, Jan 23 2018, 15:12:10) [Clang 9.0.0 (clang-900.0.39.2)]
== Darwin-17.3.0-x86_64-i386-64bit little-endian
== cwd: /Users/yury/dev/pydev/cpython/build/test_python_65406
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.80 [1/1] test_asyncio
test_cancel2 (test.test_asyncio.test_unix_events.SelectorEventLoopUnixSockSendfileTests) ... ERROR

======================================================================
ERROR: test_cancel2 (test.test_asyncio.test_unix_events.SelectorEventLoopUnixSockSendfileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/yury/dev/pydev/cpython/Lib/test/test_asyncio/test_unix_events.py", line 487, in cleanup
    proto.transport.close()
AttributeError: 'NoneType' object has no attribute 'close'

----------------------------------------------------------------------
Ran 1 test in 0.010s

FAILED (errors=1)
Task was destroyed but it is pending!
task: <Task pending coro=<BaseSelectorEventLoop._accept_connection2() done, defined at /Users/yury/dev/pydev/cpython/Lib/asyncio/selector_events.py:200> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x10731c2e8>()]>>
test test_asyncio failed
test_asyncio failed

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:22:36 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 20:22:36 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516738956.24.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
pull_requests: +5132

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:31:17 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 20:31:17 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516739477.38.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:53:26 2018
From: report at bugs.python.org (pmpp)
Date: Tue, 23 Jan 2018 20:53:26 +0000
Subject: [issue32202] [ctypes] all long double tests fail on android-24-x86_64
In-Reply-To: <1512234593.69.0.213398074469.issue32202@psf.upfronthosting.co.za>
Message-ID: <1516740806.35.0.467229070634.issue32202@psf.upfronthosting.co.za>


Change by pmpp <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32202>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:53:38 2018
From: report at bugs.python.org (pmpp)
Date: Tue, 23 Jan 2018 20:53:38 +0000
Subject: [issue32203] [ctypes] test_struct_by_value fails on android-24-arm64
In-Reply-To: <1512235574.32.0.213398074469.issue32203@psf.upfronthosting.co.za>
Message-ID: <1516740818.7.0.467229070634.issue32203@psf.upfronthosting.co.za>


Change by pmpp <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32203>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:58:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 20:58:35 +0000
Subject: [issue32639] Coverity: CID 1428443: Null pointer dereferences
 (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without()
Message-ID: <1516741115.79.0.467229070634.issue32639@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Coverity found a bug in hamt.c:

** CID 1428443:  Null pointer dereferences  (NULL_RETURNS)
/Python/hamt.c: 1058 in hamt_node_bitmap_without()


________________________________________________________________________________________________________
*** CID 1428443:  Null pointer dereferences  (NULL_RETURNS)
/Python/hamt.c: 1058 in hamt_node_bitmap_without()
1052                         assert(hamt_node_collision_count(
1053                                 (PyHamtNode_Collision*)sub_node) > 1);
1054                     }
1055     #endif
1056
1057                     PyHamtNode_Bitmap *clone = hamt_node_bitmap_clone(self);
>>>     CID 1428443:  Null pointer dereferences  (NULL_RETURNS)
>>>     Dereferencing a null pointer "clone".
1058                     Py_SETREF(clone->b_array[val_idx],
1059                               (PyObject *)sub_node);  /* borrow */
1060
1061                     *new_node = (PyHamtNode *)clone;
1062                     return W_NEWNODE;
1063                 }

----------
components: Interpreter Core
messages: 310522
nosy: vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Coverity: CID 1428443:  Null pointer dereferences  (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32639>
_______________________________________

From report at bugs.python.org  Tue Jan 23 16:08:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 21:08:03 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516741683.38.0.467229070634.issue32637@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5133
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 16:26:09 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 21:26:09 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516742769.45.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 0bad4d63c654d93e1f32ff35026405a3987db5ca by Yury Selivanov in branch 'master':
bpo-32436: Fix potential NULL dereference (#5286)
https://github.com/python/cpython/commit/0bad4d63c654d93e1f32ff35026405a3987db5ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Tue Jan 23 16:26:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 21:26:57 +0000
Subject: [issue32639] Coverity: CID 1428443: Null pointer dereferences
 (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without()
In-Reply-To: <1516741115.79.0.467229070634.issue32639@psf.upfronthosting.co.za>
Message-ID: <1516742817.15.0.467229070634.issue32639@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Victor, it's been already fixed/tracked here: https://github.com/python/cpython/pull/5286

(I also receive coverity reports :)

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32639>
_______________________________________

From report at bugs.python.org  Tue Jan 23 16:32:21 2018
From: report at bugs.python.org (Malcolm Smith)
Date: Tue, 23 Jan 2018 21:32:21 +0000
Subject: [issue32640] Python 2.7 str.join documentation is incorrect
Message-ID: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>


New submission from Malcolm Smith <malcolm.smith at gmail.com>:

At some point the Python 3 documentation of str.join has been copied to Python 2. This includes the sentence "A TypeError will be raised if there are any non-string values in iterable, including bytes objects." 

The second half of this sentence is wrong for Python 2. Not only is there no "bytes" type in Python 2, but join() in this version will happily join any mixture of unicode and (byte-)str objects, producing unicode output if any of the items (or separator) were unicode.

https://docs.python.org/2/library/stdtypes.html#str.join

----------
assignee: docs at python
components: Documentation
messages: 310525
nosy: Malcolm Smith, docs at python
priority: normal
severity: normal
status: open
title: Python 2.7 str.join documentation is incorrect
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Tue Jan 23 16:33:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 21:33:35 +0000
Subject: [issue32639] Coverity: CID 1428443: Null pointer dereferences
 (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without()
In-Reply-To: <1516742817.15.0.467229070634.issue32639@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaEhefwYA-vbZuqv06fKKrV_VCpxu7+WcDcXdMVyBg_KA@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> (I also receive coverity reports :)

Oh, I didn't know. The current workflow is not ideal to avoid duplicated issues.

----------
title: Coverity: CID 1428443:  Null pointer dereferences  (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without() -> Coverity: CID 1428443: Null pointer dereferences (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32639>
_______________________________________

From report at bugs.python.org  Tue Jan 23 16:47:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 21:47:25 +0000
Subject: [issue32639] Coverity: CID 1428443: Null pointer dereferences
 (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without()
In-Reply-To: <1516741115.79.0.467229070634.issue32639@psf.upfronthosting.co.za>
Message-ID: <1516744045.9.0.467229070634.issue32639@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Oh, I didn't know. The current workflow is not ideal to avoid duplicated issues.

If I fix something that's been reported there I usually update the coverity issue directly.  But yeah...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32639>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:07:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 22:07:58 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
Message-ID: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

http://buildbot.python.org/all/#/builders/58/builds/498

0:36:25 [252/414/1] test_context crashed (Exit code 3) -- running: test_largefile (239 sec)
Windows fatal exception: code 0xc000001d

Current thread 0x00000944 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 321 in ctx1_fun
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 339 in test_context_copy_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
Fatal Python error: Illegal instruction

Current thread 0x00000944 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 321 in ctx1_fun
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 339 in test_context_copy_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main


0:46:50 [306/414/2] test_asyncio crashed (Exit code 3) -- running: test_io (487 sec)
Windows fatal exception: code 0xc000001d

Current thread 0x00000d24 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2191 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2289 in _step
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\events.py", line 88 in _run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 1529 in _run_once
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 391 in run_forever
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 423 in run_until_complete
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2199 in test_context_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
Fatal Python error: Illegal instruction

Current thread 0x00000d24 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2191 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2289 in _step
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\events.py", line 88 in _run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 1529 in _run_once
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 391 in run_forever
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 423 in run_until_complete
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2199 in test_context_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main

Note: the commit 0bad4d63c654d93e1f32ff35026405a3987db5ca doesn't fix these crashes. (The running build 399 hash this fix, and test_context does still crash.)

----------
components: asyncio
messages: 310528
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_context and test_asyncio crash on Windows 7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:11:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 22:11:40 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516745500.15.0.467229070634.issue32641@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

test_asyncio started to crash at build 491:

http://buildbot.python.org/all/#/builders/58/builds/491

This build contains the commit f23746a934177c48eff754411aba54c31d6be2f0: "bpo-32436: Implement PEP 567". I'm not 100% sure that it's the cause of the regression. Since test_context added by this commit also crash, it really smells this the cause of the regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:13:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 22:13:28 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516745608.31.0.467229070634.issue32641@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

It's not a regression, the newly added code doesn't work on some Windows buildbot... looking at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:18:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 22:18:22 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516745902.54.0.467229070634.issue32641@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Some hints. Compiler warnings:

..\Python\hamt.c(625): warning C4018: '<': signed/unsigned mismatch [D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\pythoncore.vcxproj]
..\Python\hamt.c(733): warning C4018: '<': signed/unsigned mismatch [D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\pythoncore.vcxproj]
..\Python\hamt.c(939): warning C4018: '<': signed/unsigned mismatch [D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\pythoncore.vcxproj]
..\Python\hamt.c(1122): warning C4018: '<': signed/unsigned mismatch [D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\pythoncore.vcxproj]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:19:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 22:19:28 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516745968.75.0.467229070634.issue32641@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

No, these are trivial uint32_t/Py_SIZE: `for (uint32_t i = val_idx + 1; i < Py_SIZE(o); i++)`; it's something else.  I suspect popcount instruction...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:22:06 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 23 Jan 2018 22:22:06 +0000
Subject: [issue20709] os.utime(path_to_directory): wrong documentation for
 Windows.
In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za>
Message-ID: <1516746126.91.0.467229070634.issue20709@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

@jgehrcke, would you be able to convert your patch to a Github pull request on the master branch?

----------
nosy: +csabella
stage:  -> needs patch
versions: +Python 3.7 -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20709>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:41:14 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 23 Jan 2018 22:41:14 +0000
Subject: [issue32640] Python 2.7 str.join documentation is incorrect
In-Reply-To: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>
Message-ID: <1516747274.98.0.467229070634.issue32640@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Looks like this happened in PR1898.

----------
nosy: +Mariatta, csabella
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:50:49 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 23 Jan 2018 22:50:49 +0000
Subject: [issue22946] urllib gives incorrect url after open when using HTTPS
In-Reply-To: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za>
Message-ID: <1516747849.21.0.467229070634.issue22946@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

@John.McKay, would you be interested in converting your patch to a Github pull request on the master branch?

----------
nosy: +csabella
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22946>
_______________________________________

From report at bugs.python.org  Tue Jan 23 18:50:59 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 23 Jan 2018 23:50:59 +0000
Subject: [issue32551] Zipfile & directory execution in 3.5.4 also adds the
 parent directory to sys.path
In-Reply-To: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>
Message-ID: <1516751459.06.0.467229070634.issue32551@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

I can confirm that 3.5.5rc1 fixes the problem I had.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Tue Jan 23 18:55:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 23:55:21 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516751721.59.0.467229070634.issue32637@psf.upfronthosting.co.za>


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


----------
pull_requests: +5134

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:12:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:12:39 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516752759.53.0.467229070634.issue32637@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The idea was first discussed on python-dev:

https://mail.python.org/pipermail/python-dev/2018-January/151874.html

me: "It seems like sys.platform == 'android' would be more appropriate
since Android is not Linux: different libc, different filesystems,
etc."

https://mail.python.org/pipermail/python-dev/2018-January/151887.html

Brett Cannon: "I've had a similar thought myself.".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:12:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:12:46 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516752766.47.0.467229070634.issue32637@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:22:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 00:22:11 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516753331.8.0.467229070634.issue32641@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I suspect this is a compiler bug.  I can't reproduce it on my windows 7 virtual machine and on AppVeyor.

It's not related to HAMT, btw, as there is a multitude of HAMT-specific tests that all pass.  The crash is specifically in context.c, and the code there is pretty trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:23:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:23:36 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516753416.84.0.467229070634.issue32641@psf.upfronthosting.co.za>


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


----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:26:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:26:50 +0000
Subject: [issue28046] Remove the concept of platform-specific directories
In-Reply-To: <1473443913.59.0.936788039942.issue28046@psf.upfronthosting.co.za>
Message-ID: <1516753610.92.0.467229070634.issue28046@psf.upfronthosting.co.za>


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


----------
pull_requests: +5135

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28046>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:27:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:27:40 +0000
Subject: [issue28046] Remove the concept of platform-specific directories
In-Reply-To: <1473443913.59.0.936788039942.issue28046@psf.upfronthosting.co.za>
Message-ID: <1516753660.57.0.467229070634.issue28046@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The cleanup is not complete, so I reopen the issue: https://github.com/python/cpython/pull/5289

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28046>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:35:35 2018
From: report at bugs.python.org (paul j3)
Date: Wed, 24 Jan 2018 00:35:35 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1516754135.16.0.467229070634.issue9334@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

I attached a script that implements Evan's _match_argument idea, using a ArgumentParser subclass.  I think this is the safest way to add different functionality to the parser.  It (subclassing) is used, for example in pypi extensions like plac.

My version places the special nargs case after the default match test.  So it acts only if the regular action fails.  But I don't know of a test case where that difference matters.

I've tested it with all the examples posted in this issue, but have not tested it against test_argparse.py.  I'd also like to know if it goes far enough in adapting to optparse/POSIX usage.  It probably doesn't.

----------
Added file: https://bugs.python.org/file47404/argparse_opt.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:36:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:36:22 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516754182.75.0.467229070634.issue32641@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I suspect this is a compiler bug.

It may be interesting to add the compiler version to test.pythoninfo. It would be simpler to compare Windows buildbots to identify a bug.

Currently, the only info is:

"sys.version: 3.7.0a4+ (heads/master:9d411c1, Jan 23 2018, 15:13:42) [MSC v.1900 32 bit (Intel)]"

Some environment variables are also dumped:

os.environ[VS100COMNTOOLS]: C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\
os.environ[VS140COMNTOOLS]: D:\Program Files\Microsoft Visual Studio 14.0\Common7\Tools\
os.environ[VS90COMNTOOLS]: D:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\

In the compile step, I see lines like:

"Microsoft (R) Build Engine version 14.0.24730.2"

I recall also issues with outdated ucrtbase DLLs. Maybe we can also dump the version of such DLL?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:38:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:38:05 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516754285.22.0.467229070634.issue32637@psf.upfronthosting.co.za>


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


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:39:15 2018
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 24 Jan 2018 00:39:15 +0000
Subject: [issue31000] Test failure in resource module on ZFS
In-Reply-To: <1500851878.05.0.462798019219.issue31000@psf.upfronthosting.co.za>
Message-ID: <1516754355.29.0.467229070634.issue31000@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I'm using ZFS on 64-bit Linux.

I did see a Github issue / commit that claims to address this.  I'm using a reasonably recent ZoL build, that should have that commit, and I still see the behavior.

I actually experimented with it a little, and, hmm.  The test sets the rlimit to 1024 bytes.  I can write exactly 512 bytes to the file; it fails on the 513th.  We *could* change the test to behave like that (write 512 bytes, then write 513 more) but I don't think we should work around their bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31000>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:42:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:42:58 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516754578.55.0.467229070634.issue32637@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

A similar change was proposed by pmp-p on MicroPython: https://github.com/micropython/micropython/pull/3564

His use case is to use ffi module on Android (see the PR for more information), currently ffi fails to locate libraries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 19:44:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 00:44:12 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516754652.64.0.467229070634.issue32637@psf.upfronthosting.co.za>


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


----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 20:11:51 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 01:11:51 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1516756311.22.0.467229070634.issue32502@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset 6b273f7f4056f8276f61a97c789d6bb4425e653c by Barry Warsaw (Bo Bayles) in branch 'master':
bpo-32502: Discard 64-bit (and other invalid) hardware addresses (#5254)
https://github.com/python/cpython/commit/6b273f7f4056f8276f61a97c789d6bb4425e653c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Tue Jan 23 20:27:06 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 01:27:06 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516757226.14.0.467229070634.issue32636@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Question: there are lots of tests -- for example test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests.test_wait_with_exception, which freezes for me -- that use 'yield from asyncio.sleep(...)', e.g.:

        @asyncio.coroutine
        def sleeper():
            yield from asyncio.sleep(0.15, loop=loop)
            raise ZeroDivisionError('really')

But Andrew switch asyncio.sleep to be an ordinary 'async def' coroutine back in December. How does this work at all?

My tentative hypothesis about the actual bug is that the code above is working in regular mode, but stops working in debug mode, probably because in debug mode @asyncio.coroutine takes a different path involving CoroWrapper and we changed CoroWrapper. But I'm having trouble knowing how to verify or fix that because I don't understand how it ever works in the first place :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 20:31:10 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 01:31:10 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516757470.85.0.467229070634.issue32636@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

(However, I can report that at least that particular test starts working again if I convert 'sleeper' into an 'async def' coroutine.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 20:31:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 01:31:34 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516757494.08.0.467229070634.issue32636@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

asyncio.coroutine sets the co_flags bit CO_ITERABLE_COROUTINE for generator functions' code objects.

With that bit flag, Python allows to 'yield from' native coroutines.

CoroWrapper.send() -> wrapped_generator.send() -> YIELD_FROM(native_coro) -> native_coro.send()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 20:53:52 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 24 Jan 2018 01:53:52 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516758832.97.0.467229070634.issue32623@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

For insert/pop loop, reduce table size aggressively on pop may cause
performance regression.  So reducing size should be conservative.

So my opinion is:

* When dict size become 0, make the dict shared-empty, like dict.clear()
* When (dict size < dk_size/8), call insertion_resize()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Tue Jan 23 20:54:44 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 01:54:44 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516758884.69.0.467229070634.issue32636@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

How confident are we that this is a regression from the coroutine origin tracking changes? (I'd double-check myself, but my cpython checkout is tied up for the next few hours doing --enable-optimizations builds.)

Looking at @asyncio.coroutine, in particular this branch that gets taken when debug mode is enabled:

https://github.com/python/cpython/blob/6b273f7f4056f8276f61a97c789d6bb4425e653c/Lib/asyncio/coroutines.py#L135-L149

I'm not seeing anything that would toggle the CO_ITERABLE_COROUTINE flag, and if I use pdb I can see that in the broken test the 'sleeper' function indeed doesn't have that flag set. But I didn't touch that code in the origin tracking patch, which makes me think that the proximal cause here might have been 5f841b553814969220b096a2b4f959b7f6fcbaf6 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 20:59:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 01:59:05 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516759145.1.0.467229070634.issue32636@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

No, it's this specific commit.  I can double check later, but I'm pretty sure about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 21:11:13 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 02:11:13 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516759873.88.0.467229070634.issue32636@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Ah-hah, I get what's going on.

@asyncio.coroutine has always been buggy: when debug mode is turned on, then it fails to set CO_ITERABLE_COROUTINE.

However, when debug mode is turned on, then traditionally native coroutines got wrapped into CoroWrapper objects. We've always been lazy and reused the same CoroWrapper type for both native coroutines and old-style @asyncio.coroutine coroutines, so CoroWrapper has both coroutine and generator attributes.

This means that until my patch, in debug mode, native coroutines were *getting turned back into generators*. So this hid the bug in @asyncio.coroutine, because it doesn't matter if you can't call native coroutines if you've just turned them into generators.

The fix is trivial, we just need to always use @types.coroutine in @asyncio.coroutine, I'll put up a PR momentarily.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 21:14:25 2018
From: report at bugs.python.org (bbayles)
Date: Wed, 24 Jan 2018 02:14:25 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1516760065.67.0.467229070634.issue32502@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
pull_requests: +5136

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Tue Jan 23 21:55:24 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 02:55:24 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516762524.19.0.467229070634.issue32636@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
keywords: +patch
pull_requests: +5137
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 21:59:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 02:59:34 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516762774.1.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
pull_requests: +5138
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Tue Jan 23 21:59:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 02:59:34 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516762774.19.0.574204596225.issue32641@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5139
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 22:01:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 03:01:48 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516762908.42.0.467229070634.issue32641@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

In an off-list conversation with David, it was confirmed that the buildbot in question runs on an old hardware without SSE4.2 support.

I decided to simply stop using native popcount instructions as there's no detectable performance difference when using them vs using the fallback code.

See https://github.com/python/cpython/pull/5292 for details.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 22:17:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 03:17:06 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516763826.76.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b7a80d543e1e94475ab9c8214f7a9eab4e63c9ab by Yury Selivanov in branch 'master':
bpo-32436: Don't use native popcount() (also fixes bpo-32641) (#5292)
https://github.com/python/cpython/commit/b7a80d543e1e94475ab9c8214f7a9eab4e63c9ab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Tue Jan 23 22:17:07 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 03:17:07 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516763827.43.0.714561066657.issue32641@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b7a80d543e1e94475ab9c8214f7a9eab4e63c9ab by Yury Selivanov in branch 'master':
bpo-32436: Don't use native popcount() (also fixes bpo-32641) (#5292)
https://github.com/python/cpython/commit/b7a80d543e1e94475ab9c8214f7a9eab4e63c9ab


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 22:17:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 03:17:48 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516763868.35.0.467229070634.issue32641@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I've pushed a commit that should fix the buildbot. Please reopen if it doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Tue Jan 23 22:27:32 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 24 Jan 2018 03:27:32 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516764452.12.0.467229070634.issue32513@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Are we clear on the proposal now? It would be good to have this implemented in beta 1. Eric's long message looks good to me (though I have to admit the logic around __hash__ confuses me, but I've spent two long days at PyCascades, and I trust Eric's judgment).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Tue Jan 23 23:11:13 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 04:11:13 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516767073.04.0.467229070634.issue30491@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Please insert the usual caveats around how reliable benchmarking is impossible. (Last month when I tried this with a previous version of the patch, the interpreter that had the patch applied -- and thus was doing slightly *more* work -- was consistently a few percent faster in general, because something something PGO I guess? Compilers are weird.)

That said, I'm not seeing any measurable difference at all with this patch. This isn't surprising: in the default mode (tracking disabled), the extra operations are:

coroutine creation: 'if (predictably_true) { self->a = NULL; self->b = NULL }'

send/throw: 'if (genobject->ob_type == PyCoro_Type && self->a != NULL) { /* not executed, because the condition always fails */ }'

----- benchmark details

I built 3954f6126f (head of my PR branch, labeled "with-unawaited-coroutines" below) and f23746a934 (its immediate parent, on master, labeled "without-unawaited-coroutines" below), with --enable-optimizations, on a Thinkpad T450s running 64-bit Linux. I ran a script (included below) that simply created and executed a trivial coroutine over and over, and measured using perf.

2 runs of each, alternating:

~/src/cpython$ without-unawaited-tracking/install/bin/python3 corobench.py
.....................
coroutine creation/close: Mean +- std dev: 3.90 us +- 0.11 us
~/src/cpython$ with-unawaited-tracking/install/bin/python3 corobench.py   
.....................
coroutine creation/close: Mean +- std dev: 3.90 us +- 0.09 us
~/src/cpython$ without-unawaited-tracking/install/bin/python3 corobench.py
.....................
coroutine creation/close: Mean +- std dev: 3.93 us +- 0.21 us
~/src/cpython$ with-unawaited-tracking/install/bin/python3 corobench.py   
.....................
coroutine creation/close: Mean +- std dev: 3.91 us +- 0.10 us


Script: attached as "corobench.py"

----------
Added file: https://bugs.python.org/file47405/corobench.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Tue Jan 23 23:29:00 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 04:29:00 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516768140.87.0.467229070634.issue30491@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Yury also asked me to try running a generator/coroutine microbenchmark from PEP 492 (https://www.python.org/dev/peps/pep-0492/#async-await). I'm attaching the actual script for that as well (pep492bench.py), since I had to add a few lines to actually run the functions in the PEP :-).

Results from 3 runs each of the two builds, alternating:

-----

~/src/cpython$ without-unawaited-tracking/install/bin/python3 pep492bench.py 
binary(19) * 30: total 7.349s
abinary(19) * 30: total 7.727s
~/src/cpython$ with-unawaited-tracking/install/bin/python3 pep492bench.py 
binary(19) * 30: total 7.758s
abinary(19) * 30: total 8.023s
~/src/cpython$ without-unawaited-tracking/install/bin/python3 pep492bench.py
binary(19) * 30: total 7.326s
abinary(19) * 30: total 7.686s
~/src/cpython$ with-unawaited-tracking/install/bin/python3 pep492bench.py   
binary(19) * 30: total 7.652s
abinary(19) * 30: total 7.999s
~/src/cpython$ without-unawaited-tracking/install/bin/python3 pep492bench.py
binary(19) * 30: total 7.421s
abinary(19) * 30: total 7.732s
~/src/cpython$ with-unawaited-tracking/install/bin/python3 pep492bench.py   
binary(19) * 30: total 7.541s
abinary(19) * 30: total 8.132s

-----

So here we get a small difference between the with-unawaited-tracking and the without-unawaited-tracking builds. For generators, with-unawaited-tracking is:

In [1]: (7.541 + 7.652 + 7.758) / (7.349 + 7.326 + 7.421)
Out[1]: 1.0386947863866764

~3.9% slower.

And for coroutines, with-unawaited-tracking is:

In [2]: (8.023 + 7.999 + 8.132) / (7.727 + 7.686 + 7.732)
Out[2]: 1.043594728883128

~4.4% slower.

----------
Added file: https://bugs.python.org/file47406/pep492bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:06:30 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 05:06:30 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516770390.68.0.467229070634.issue30491@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Guido,

This is another feature for native coroutines that Nathaniel proposes for 3.7.

Here's a summary (this issue has too many messages):

1. It adds a new mechanism to detect un-awaited coroutines (i.e. when a user forgets to use await).

2. To enable the mechanism, which is disabled by default, a "sys. set_unawaited_coroutine_tracking_enabled()" function needs to be called by a framework.

3. "sys.get_unawaited_coroutines()" returns a list of not-yet-awaited native-coroutine objects that were created since the previous call to "get_unawaited_coroutines()".

4. In Trio, the APIs are designed to accept *coroutine functions*.  So in Trio, a user either writes "await coro()" or passes "coro" to a Trio API.  Nathaniel wants Trio to check periodically if there are any un-awaited coroutines and raise an error, which should improve Trio usability.

5. Another potential user of this new functionality is pytest-asyncio. It can use the API to warn the user that a test created some coroutines that were never awaited. 

6. asyncio/tornado/curio/twisted will not be able to use this API.

7. Effectively, the previously merged origin-tracking API (the one with which we replaced set_coroutine_wrapper) achieves the same goal.  The only downside is that the warning won't be raised until GC.  On other interpreters like PyPy it can take a while before a coroutine gets GCed.

8. The patch adds two pointers to native coroutines objects to maintain a doubly-linked list of them.

9. The performance impact is visible in micro-benchmarks, but is unlikely be visible in real applications.  Still, it's about 3-4% slowdown for both generators and coroutines.

10. The PR itself is in a good shape, although I'll still make a review pass if you approve this feature to go in 3.7.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:06:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 05:06:38 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516770398.96.0.467229070634.issue30491@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:27:12 2018
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 24 Jan 2018 05:27:12 +0000
Subject: [issue32642] add support for path-like objects in sys.path
Message-ID: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to suggest enhancing sys.path to recognize path-like objects, per PEP 519.

I recently ran into an issue where a path was getting added to sys.path, but the corresponding imports weren't working as they should, even though sys.path showed the path as being present. Eventually I tracked this down to the path being a pathlib.Path object rather than a string. This wasn't obvious because Path objects appear as strings in normal debug output, etc.

The sys.path docs currently say this:

> Only strings and bytes should be added to sys.path; all other data types are ignored during import.

----------
components: Library (Lib)
messages: 310560
nosy: brett.cannon, chris.jerdonek
priority: normal
severity: normal
status: open
title: add support for path-like objects in sys.path
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32642>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:32:19 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 05:32:19 +0000
Subject: [issue32643] Make Task._step,
 Task._wakeup and Future._schedule_callback methods private
Message-ID: <1516771939.71.0.467229070634.issue32643@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I propose to drop support for overloading Task._step, Task._wakeup, and Future._schedule_callbacks.

This makes the implementation easier for us to maintain and optimize. It also makes it easier for alternative asyncio event loops and interops with other async frameworks.

----------
components: asyncio
messages: 310561
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Make Task._step, Task._wakeup and Future._schedule_callback methods private
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32643>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:33:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 05:33:28 +0000
Subject: [issue32643] Make Task._step,
 Task._wakeup and Future._schedule_callback methods private
In-Reply-To: <1516771939.71.0.467229070634.issue32643@psf.upfronthosting.co.za>
Message-ID: <1516772008.05.0.467229070634.issue32643@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5140
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32643>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:38:28 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 24 Jan 2018 05:38:28 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1516772308.66.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Sounds good, Ned.  Thanks for taking a look.  I should have everything finished up by Friday, so I'm hopeful for landing the change before the deadline.  I may have a few minor tweaks to make after that, but I'll discuss that with you before making any changes if that happens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:41:18 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Jan 2018 05:41:18 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516772478.61.0.467229070634.issue32635@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Incidentally, why did this manifest as a segfault rather than a compilation error?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:43:23 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 24 Jan 2018 05:43:23 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516772603.12.0.467229070634.issue30491@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Thanks for the summary, Yury! One quick note:

> Effectively, the previously merged origin-tracking API (the one with which we replaced set_coroutine_wrapper) achieves the same goal.

I would say the two features are complementary. This feature (unawaited tracking) is cheap (a few % slowdown on microbenchmarks), and lets you find all the unawaited coroutine objects created in a given span of code. Origin-tracking is expensive (~3x slowdown on microbenchmarks with asyncio's default settings), and lets you take a coroutine object and map it back to the exact line of code where it was created. If you have both, then you can find all the coroutine objects and then find their exact origins.

In the testing use case, there are two problems with relying on the GC to issue warnings: (1) because of traceback frame capture, reference cycles, etc., currently "coroutine was never awaited" warnings often (usually?) get attributed to the wrong test. (And yeah, it's even worse on pypy.) (2) because it's just a warning, it's easy to miss entirely -- if you forget an 'await' you can easily get a test that passes because it never actually executed any code (!), and when the tests are green most people don't read the CI logs to check for warnings.

The idea of this feature is it's cheap enough for pytest-asyncio or trio to turn it on by default, and it makes the detection deterministic, so e.g. pytest-asyncio can reliably figure out which test caused the problem and mark it as FAILed. Then if it you also turn on origin-tracking, it can further narrow that down to the exact line in the test that caused the failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Wed Jan 24 01:52:38 2018
From: report at bugs.python.org (Snakevil)
Date: Wed, 24 Jan 2018 06:52:38 +0000
Subject: [issue32644] unittest.mock.call len() error
Message-ID: <1516776758.4.0.467229070634.issue32644@psf.upfronthosting.co.za>


New submission from Snakevil <zsnakevil at gmail.com>:

In some testcase, an instance of unittest.mock.call was generated as:

call('solution', 'foo', {'__spots__': {}, '__event__': None, '__solution__': None})

The third argument is an instance of a derived component from dict.

In this issue, result of len() is 2 but not 3 as expected.

----------
components: Tests
messages: 310565
nosy: snakevil
priority: normal
severity: normal
status: open
title: unittest.mock.call len() error
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32644>
_______________________________________

From report at bugs.python.org  Wed Jan 24 01:57:37 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 24 Jan 2018 06:57:37 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1516772603.12.0.467229070634.issue30491@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+gO3tOtg+nQwTT1Y9hu+ZKkVPeuR8OrwYUk0Xv1pvC6Q@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

No. I just mailed Yury with an explanation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Wed Jan 24 02:13:08 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Dupuis?=)
Date: Wed, 24 Jan 2018 07:13:08 +0000
Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links
In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za>
Message-ID: <1516777988.31.0.467229070634.issue9949@psf.upfronthosting.co.za>


?tienne Dupuis <svart.riddare at gmail.com> added the comment:

Referenced here: https://stackoverflow.com/questions/43333640/python-os-path-realpath-for-symlink-in-windows.

----------
nosy: +?tienne Dupuis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9949>
_______________________________________

From report at bugs.python.org  Wed Jan 24 03:16:36 2018
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 24 Jan 2018 08:16:36 +0000
Subject: [issue32643] Make Task._step,
 Task._wakeup and Future._schedule_callback methods private
In-Reply-To: <1516771939.71.0.467229070634.issue32643@psf.upfronthosting.co.za>
Message-ID: <1516781796.77.0.467229070634.issue32643@psf.upfronthosting.co.za>


Change by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +chris.jerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32643>
_______________________________________

From report at bugs.python.org  Wed Jan 24 03:50:58 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 24 Jan 2018 08:50:58 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516783858.42.0.467229070634.issue32410@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +5141
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:12:12 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 24 Jan 2018 09:12:12 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516785132.14.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm working on a patch before beta 1. The only issue is whether to raise in the case that order=True and the user specifies one of the 4 ordering dunders. I think raising is okay, especially since order=False is the default: you'd have to go out of your way to cause the exception. I'll mention functools.total_ordering in the exception message.

I do think that the discussion in my long message about __hash__ is correct, although I'm not done thinking it through. I think it's already pretty well tested, but if not I'll make sure there are enough test cases for objects that I think should or shouldn't be hashable that I'll have all of the kinks worked about before beta 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:29:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:29:40 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516786180.82.0.467229070634.issue32623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I agree that an heuristic is needed to decide when a dict should be compacted.

> * When (dict size < dk_size/8), call insertion_resize()

In bpo-31179, I suggested to Yury to use 2/3 ratio... to avoid integer overflow :-) He first used 80%, but I dislike using the FPU in the dictobject.c. I'm not sure of the cost of switching from integers to floats, and more generally I hate rounding issues, so I prefer to use regular integers ;-)

+           (3) if 'mp' is non-compact ('del' operation does not resize dicts),
+               do fast-copy only if it has at most 1/3 non-used keys.
+
+           The last condition (3) is important to guard against a pathalogical
+           case when a large dict is almost emptied with multiple del/pop
+           operations and copied after that.  In cases like this, we defer to
+           PyDict_Merge, which produces a compacted copy.

By the way, if dict automatically compacts itself automatically, do we still need Yury's test "is the dict compact"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:31:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:31:37 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516786297.32.0.467229070634.issue32623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

This issue is a matter of CPU vs memory tradeoff. It reminds me the PEP 393: str type doesn't make tradeoff anymore, CPython guarantee that str always use the most efficient storage (least memory) for characters.

But here the tradeoff is different. A dict is mutable, whereas str is immutable ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:35:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:35:33 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516786533.67.0.467229070634.issue32635@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:36:02 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Jan 2018 09:36:02 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516786562.29.0.467229070634.issue32635@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:36:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:36:26 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516786586.37.0.467229070634.issue32636@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Good. Using PR 5291, test_asyncio doesn't hang anymore, and only 2 tests still fail:

======================================================================
ERROR: test_foobar (test.test_asyncio.test_tasks.CTask_Future_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2473, in test_foobar
    self.loop.call_later(0.1, fut.set_result(1))
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 509, in call_later
    context=context)
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 522, in call_at
    self._check_callback(callback, 'call_at')
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 556, in _check_callback
    f'a callable object was expected by {method}(), '
TypeError: a callable object was expected by call_at(), got None

======================================================================
FAIL: test_nonstream_socket (test.test_asyncio.test_base_events.BaseLoopSendfileTests)
----------------------------------------------------------------------
ValueError: the socket must be non-blocking

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_base_events.py", line 1922, in test_nonstream_socket
    self.run_loop(self.loop.sock_sendfile(sock, self.file))
AssertionError: "only SOCK_STREAM type" does not match "the socket must be non-blocking"

----------------------------------------------------------------------
Ran 1874 tests in 49.198s

FAILED (failures=1, errors=1, skipped=5)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:36:57 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Jan 2018 09:36:57 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516786617.79.0.467229070634.issue32635@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5143

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:42:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:42:00 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516786920.63.0.467229070634.issue32635@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Charalampos, Christian: are you ok to backport the fix to Python 2.7 and 3.6? (PR 5295 and PR 5296)

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:42:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:42:26 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516786946.59.0.467229070634.issue32636@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Fix for the two remaining bugs:

diff --git a/Lib/test/test_asyncio/test_base_events.py b/Lib/test/test_asyncio/test_base_events.py
index 8d72df6a72..6489f50f27 100644
--- a/Lib/test/test_asyncio/test_base_events.py
+++ b/Lib/test/test_asyncio/test_base_events.py
@@ -1917,6 +1917,7 @@ class BaseLoopSendfileTests(test_utils.TestCase):
 
     def test_nonstream_socket(self):
         sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
+        sock.setblocking(False)
         self.addCleanup(sock.close)
         with self.assertRaisesRegex(ValueError, "only SOCK_STREAM type"):
             self.run_loop(self.loop.sock_sendfile(sock, self.file))
diff --git a/Lib/test/test_asyncio/test_tasks.py b/Lib/test/test_asyncio/test_tasks.py
index d2162c31b4..9b62d207e4 100644
--- a/Lib/test/test_asyncio/test_tasks.py
+++ b/Lib/test/test_asyncio/test_tasks.py
@@ -2470,7 +2470,7 @@ class CTask_Future_Tests(test_utils.TestCase):
         self.loop = asyncio.new_event_loop()
         try:
             fut = Fut(loop=self.loop)
-            self.loop.call_later(0.1, fut.set_result(1))
+            self.loop.call_later(0.1, fut.set_result, 1)
             task = asyncio.Task(coro(), loop=self.loop)
             res = self.loop.run_until_complete(task)
         finally:

---

Nathaniel: do you want to include these fixes in your PR as well?

Hum, I'm concerned that "self.loop.call_later(0.1, fut.set_result(1))" bug wasn't spotted previously.

I plan to always run the Python test suite (especially when running on our CIs) in the new Python 3.7 "development mode" (python3 -X dev) which enables asyncio debug mode. Are you ok with that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:42:58 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Jan 2018 09:42:58 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516786978.6.0.467229070634.issue32635@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

yes, go ahead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:49:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:49:29 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
Message-ID: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

test_asyncio started to fail after the implementation of STARTTLS in asyncio, bpo-23749: commit f111b3dcb414093a4efb9d74b69925e535ddc470.

http://buildbot.python.org/all/#/builders/58/builds/502

Extract of test.pythoninfo:
----
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.0f  25 May 2017
ssl.OPENSSL_VERSION_INFO: (1, 1, 0, 6, 15)
ssl.OP_ALL: -0x7fffffac
ssl.OP_NO_TLSv1_1: 0x10000000

sys.version: 3.7.0a4+ (heads/master:018e1b7, Jan 24 2018, 02:53:43) [MSC v.1900 32 bit (Intel)]
sys.version_info: sys.version_info(major=3, minor=7, micro=0, releaselevel='alpha', serial=4)
sys.windowsversion: sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1')
sys.winver: 3.7-32
---

Extract of compile step:
---
Fetching external libraries...
(...)
openssl-bin-1.1.0f already exists, skipping.
---

Test failures:

======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 436, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

======================================================================
ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 285, in test_start_tls_server_1
    asyncio.wait_for(main(), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 436, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 436, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

======================================================================
FAIL: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\functional.py", line 42, in tearDown
    self.fail('unexpected calls to loop.call_exception_handler()')
AssertionError: unexpected calls to loop.call_exception_handler()

----------------------------------------------------------------------
Ran 1651 tests in 117.209s

FAILED (failures=1, errors=3, skipped=56)

----------
components: Tests, Windows, asyncio
messages: 310576
nosy: asvetlov, paul.moore, steve.dower, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: test_asyncio: TLS tests fail on "x86 Windows7" buildbot
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:50:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:50:01 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1516787401.05.0.467229070634.issue23749@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Tests fail on x86 Windows7 3.x:

I created a more specific issue: bpo-32645, test_asyncio: TLS tests fail on "x86 Windows7" buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:50:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:50:40 +0000
Subject: [issue32641] test_context and test_asyncio crash on Windows 7
In-Reply-To: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>
Message-ID: <1516787440.29.0.467229070634.issue32641@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I've pushed a commit that should fix the buildbot. Please reopen if it doesn't.

test_context and test_asyncio do'nt crash anymore on this buildbot, thanks Yury.

test_asyncio still fail on this buildbot, I created a new issue: bpo-32645, test_asyncio: TLS tests fail on "x86 Windows7" buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:51:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:51:41 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516787501.69.0.467229070634.issue32635@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 6ccdad7b1f6fb316e4e85aa1eba8fbdc3169741e by Victor Stinner (Miss Islington (bot)) in branch '2.7':
bpo-32635: Fix a segfault when importing the crypt module with libxcrypt. (GH-5284) (#5295)
https://github.com/python/cpython/commit/6ccdad7b1f6fb316e4e85aa1eba8fbdc3169741e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:10:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 10:10:20 +0000
Subject: [issue32646] test_asyncgen: race condition on
 test_async_gen_asyncio_gc_aclose_09(), random failure
Message-ID: <1516788620.43.0.467229070634.issue32646@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

test_asyncgen.test_async_gen_asyncio_gc_aclose_09() fails randomly. It looks like a race condition, likely related to the system load.

https://ci.appveyor.com/project/python/cpython/build/3.6build10993/job/l89045et4rmey72q

(...)
Run tests in parallel using 4 child processes
(...)
test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest) ... Task was destroyed but it is pending!
task: <Task pending coro=<async_generator_athrow()> wait_for=<Future finished result=None>>
FAIL

======================================================================
FAIL: test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_asyncgen.py", line 630, in test_async_gen_asyncio_gc_aclose_09
    self.assertEqual(DONE, 1)
AssertionError: 0 != 1
----------------------------------------------------------------------

(...)

Re-running test 'test_asyncgen' in verbose mode
(...)
test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest) ... ok
(...)
Ran 40 tests in 1.125s

----------
components: asyncio
messages: 310580
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncgen: race condition on test_async_gen_asyncio_gc_aclose_09(), random failure
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32646>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:11:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 10:11:19 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516788679.61.0.467229070634.issue32635@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 8e230e1eb3d38ad557b5dc5c31166afa35c01ff3 by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-32635: Fix a segfault when importing the crypt module with libxcrypt. (GH-5284) (#5296)
https://github.com/python/cpython/commit/8e230e1eb3d38ad557b5dc5c31166afa35c01ff3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:15:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 10:15:07 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516788907.81.0.467229070634.issue32636@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I plan to always run the Python test suite (especially when running on our CIs) in the new Python 3.7 "development mode" (python3 -X dev) which enables asyncio debug mode. Are you ok with that?

Oh, I forgot to mention the obvious drawback: asyncio debug mode is slower. test_asyncio: 36 seconds => 48 seconds (+12 seconds).

"./python -m test test_asyncio" will not use the asyncio debug mode, only an explicit "./python -X dev -m test test_asyncio" and "make buildbottest".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:27:29 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 24 Jan 2018 10:27:29 +0000
Subject: [issue32647] Undefined references when compiling ctypes
Message-ID: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1537489

As soon as strict symbol checking was enabled on the development branch of Fedora, our build of CPython started failing due to undefined symbols when compiling ctypes.

Build log is attached.

That seems to be because ctypes are not explicitly linked against -ldl.

This can be fixed by adding the -ldl flag at https://github.com/python/cpython/blob/master/setup.py#L1935 , not sure though how portable that is.

----------
files: build.log
messages: 310583
nosy: cstratak
priority: normal
severity: normal
status: open
title: Undefined references when compiling ctypes
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47407/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:27:35 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 24 Jan 2018 10:27:35 +0000
Subject: [issue32647] Undefined references when compiling ctypes
In-Reply-To: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>
Message-ID: <1516789655.97.0.467229070634.issue32647@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:52:36 2018
From: report at bugs.python.org (=?utf-8?q?R=C3=B3bert_Lexmann?=)
Date: Wed, 24 Jan 2018 10:52:36 +0000
Subject: [issue32648] Wrong byte count with struct
Message-ID: <1516791156.25.0.467229070634.issue32648@psf.upfronthosting.co.za>


New submission from R?bert Lexmann <robo.lexmann at gmail.com>:

struct.pack('id',a,b) returns 16 bytes, should return 4+8=12 bytes. struct.calcsize('id') also returns 16.

----------
messages: 310584
nosy: R?bert Lexmann
priority: normal
severity: normal
status: open
title: Wrong byte count with struct
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32648>
_______________________________________

From report at bugs.python.org  Wed Jan 24 06:00:52 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Jan 2018 11:00:52 +0000
Subject: [issue32648] Wrong byte count with struct
In-Reply-To: <1516791156.25.0.467229070634.issue32648@psf.upfronthosting.co.za>
Message-ID: <1516791652.0.0.467229070634.issue32648@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It's not a bug. Please read the section about padding.

>>> struct.calcsize('id')
16
>>> struct.calcsize('>id')
12

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32648>
_______________________________________

From report at bugs.python.org  Wed Jan 24 06:04:43 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Jan 2018 11:04:43 +0000
Subject: [issue32647] Undefined references when compiling ctypes
In-Reply-To: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>
Message-ID: <1516791883.77.0.467229070634.issue32647@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The attached file is 1.3 MB and your build is using Fedora-specific patches. Please post the relevant part from a vanilla build without Fedora patches.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 07:57:18 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 24 Jan 2018 12:57:18 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516798638.24.0.467229070634.issue32623@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +5144
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 07:57:52 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 12:57:52 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516798672.45.0.467229070634.issue17799@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 131fd7f96c619bc7eaea956e45c6337175f4b27f by Xiang Zhang (Pablo Galindo) in branch 'master':
bpo-17799: Explain real behaviour of sys.settrace and sys.setprofile (#4056)
https://github.com/python/cpython/commit/131fd7f96c619bc7eaea956e45c6337175f4b27f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:02:30 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 13:02:30 +0000
Subject: [issue32649] complete C API doc debug and profile part with new
 PyTrace_OPCODE
Message-ID: <1516798950.57.0.467229070634.issue32649@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

As the title, the new PyTrace_OPCODE event is not documented in C API doc yet.

----------
assignee: docs at python
components: Documentation
messages: 310588
nosy: docs at python, ncoghlan, pablogsal, xiang.zhang
priority: normal
severity: normal
status: open
title: complete C API doc debug and profile part with new PyTrace_OPCODE
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32649>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:04:15 2018
From: report at bugs.python.org (=?utf-8?q?R=C3=B3bert_Lexmann?=)
Date: Wed, 24 Jan 2018 13:04:15 +0000
Subject: [issue32648] Wrong byte count with struct
In-Reply-To: <1516791652.0.0.467229070634.issue32648@psf.upfronthosting.co.za>
Message-ID: <01256ed8-5671-fadb-9dd7-03904914a47f@gmail.com>


R?bert Lexmann <robo.lexmann at gmail.com> added the comment:

Thanks for a fast response. If I may ask, what is it good for to encode 
'id' in 16 bytes and 'di' in 12?

Rob

On 01/24/2018 12:00 PM, Christian Heimes wrote:
> Christian Heimes <lists at cheimes.de> added the comment:
>
> It's not a bug. Please read the section about padding.
>
>>>> struct.calcsize('id')
> 16
>>>> struct.calcsize('>id')
> 12
>
> ----------
> nosy: +christian.heimes
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32648>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32648>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:18:46 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Jan 2018 13:18:46 +0000
Subject: [issue32648] Wrong byte count with struct
In-Reply-To: <1516791156.25.0.467229070634.issue32648@psf.upfronthosting.co.za>
Message-ID: <1516799926.8.0.467229070634.issue32648@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Hardware restrictions, some CPUs require types to be aligned in certain ways. Doubles must be aligned by multiple of 8 bytes.

Please read https://en.wikipedia.org/wiki/Data_structure_alignment and use the Python users mailing list for further questions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32648>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:21:39 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 24 Jan 2018 13:21:39 +0000
Subject: [issue32647] Undefined references when compiling ctypes
In-Reply-To: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>
Message-ID: <1516800099.62.0.467229070634.issue32647@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Relevant part from the build log:

running build_ext
building '_ctypes' extension
gcc -pthread -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include -I. -IObjects -IInclude -IPython -I/usr/local/include -I/builddir/build/BUILD/Python-3.6.4/Include -I/builddir/build/BUILD/Python-3.6.4/build/optimized -c /builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.c -o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.o
gcc -pthread -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include -I. -IObjects -IInclude -IPython -I/usr/local/include -I/builddir/build/BUILD/Python-3.6.4/Include -I/builddir/build/BUILD/Python-3.6.4/build/optimized -c /builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callbacks.c -o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callbacks.o
gcc -pthread -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include -I. -IObjects -IInclude -IPython -I/usr/local/include -I/builddir/build/BUILD/Python-3.6.4/Include -I/builddir/build/BUILD/Python-3.6.4/build/optimized -c /builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.c -o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.o
gcc -pthread -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include -I. -IObjects -IInclude -IPython -I/usr/local/include -I/builddir/build/BUILD/Python-3.6.4/Include -I/builddir/build/BUILD/Python-3.6.4/build/optimized -c /builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/stgdict.c -o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/stgdict.o
gcc -pthread -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include -I. -IObjects -IInclude -IPython -I/usr/local/include -I/builddir/build/BUILD/Python-3.6.4/Include -I/builddir/build/BUILD/Python-3.6.4/build/optimized -c /builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/cfield.c -o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/cfield.o
gcc -pthread -shared -Wl,-z,relro -Wl,-z,defs -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -g build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callbacks.o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/stgdict.o build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/cfield.o -L. -L/usr/local/lib64 -lffi -lpython3.6m -o build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so
build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.o: In function `PyCFuncPtr_FromDll':
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.c:3391: undefined reference to `dlsym'
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.c:3399: undefined reference to `dlerror'
build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.o: In function `CDataType_in_dll':
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.c:675: undefined reference to `dlsym'
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/_ctypes.c:683: undefined reference to `dlerror'
build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.o: In function `py_dl_open':
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.c:1329: undefined reference to `dlopen'
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.c:1332: undefined reference to `dlerror'
build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.o: In function `py_dl_sym':
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.c:1366: undefined reference to `dlsym'
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.c:1369: undefined reference to `dlerror'
build/temp.linux-x86_64-3.6/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.o: In function `py_dl_close':
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.c:1348: undefined reference to `dlclose'
/builddir/build/BUILD/Python-3.6.4/Modules/_ctypes/callproc.c:1350: undefined reference to `dlerror'
collect2: error: ld returned 1 exit status
The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
atexit                pwd                   time               
Failed to build these modules:
_ctypes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:25:31 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 24 Jan 2018 13:25:31 +0000
Subject: [issue32647] Undefined references when compiling ctypes
In-Reply-To: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>
Message-ID: <1516800331.03.0.467229070634.issue32647@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Unfortunately when trying to reproduce it by compiling from source and adding the '-z defs' flag to the linker, undefined symbol issues appeared for all the extension modules of the stdlib.

----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:27:19 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 13:27:19 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1516800439.66.0.467229070634.issue32502@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset d69794f4df81de731cc66dc82136e28bee691e1e by Barry Warsaw (Bo Bayles) in branch '3.6':
[3.6] bpo-32502: Discard 64-bit (and other invalid) hardware addresses (GH-5254) (#5290)
https://github.com/python/cpython/commit/d69794f4df81de731cc66dc82136e28bee691e1e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:27:37 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 13:27:37 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1516800457.88.0.467229070634.issue32502@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:30:26 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 24 Jan 2018 13:30:26 +0000
Subject: [issue32635] test_crypt segfaults when using libxcrypt instead of
 libcrypt
In-Reply-To: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>
Message-ID: <1516800626.9.0.467229070634.issue32635@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:37:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 13:37:33 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516801053.37.0.467229070634.issue32637@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I propose to leave MACHDEP unchanged: keep MACHDEP="linux". Can it create inconsistencies? Is it an issue in practice?

My short term goal is to use sys.platform == 'android' has the reference test to check if we are running on Android.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:43:01 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 13:43:01 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516801381.58.0.467229070634.issue17799@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5145

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:58:11 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 13:58:11 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516802291.52.0.467229070634.issue17799@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5146

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Wed Jan 24 09:13:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 14:13:18 +0000
Subject: [issue32647] Undefined references when compiling ctypes on binutils
 2.29.1 with gcc -Wl, -z, undefs (Fedora 28)
In-Reply-To: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>
Message-ID: <1516803198.99.0.467229070634.issue32647@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I'm unable to reproduce the issue on Fedora 27 (binutils-2.29-6.fc27.src.rpm, gcc-7.2.1-2.fc27.src.rpm). _ctypes.cpython-37dm-x86_64-linux-gnu.so is generated whereas it's not linked to libdl.so (as expected). The flag seems to be ignored. https://src.fedoraproject.org/rpms/redhat-rpm-config/c/078af192613e1beec34824a94dc5f6feeeea1568?branch=master says "The latter needs binutils 2.29.1-12.fc28 or later. I understand that my binutils are too old (2.29 vs 2.29.1).

----------
nosy: +vstinner
title: Undefined references when compiling ctypes -> Undefined references when compiling ctypes on binutils 2.29.1 with gcc -Wl,-z,undefs (Fedora 28)
versions: +Python 2.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 09:16:58 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Jan 2018 14:16:58 +0000
Subject: [issue32647] Undefined references when compiling ctypes on binutils
 2.29.1 with gcc -Wl, -z, undefs (Fedora 28)
In-Reply-To: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>
Message-ID: <1516803418.39.0.467229070634.issue32647@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

-ldl is the correct fix here. https://fedoraproject.org/wiki/UnderstandingDSOLinkChange explains the problem. tl;dr linking with dl is required because the linker no longer adds indirect dependencies.

We can't just add dl unconditionally. You have to add a check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 09:36:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 14:36:04 +0000
Subject: [issue32647] Undefined references when compiling ctypes on binutils
 2.29.1 with gcc -Wl, -z, undefs (Fedora 28)
In-Reply-To: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>
Message-ID: <1516804564.78.0.467229070634.issue32647@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> We can't just add dl unconditionally.

dlopen() is not used on Windows nor macOS older than 10.3. On old macOS, functions like NSCreateObjectFileImageFromFile() are used.

I don't think that the master branch still supports macOS 10.2.

Mac OS X 10.2 was released in 2002 and unsupported as of 2006.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 09:44:55 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 14:44:55 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516805095.22.0.467229070634.issue17799@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset fd844efa9c31e1f00e04b07940875b9dacff3d77 by Xiang Zhang in branch '3.6':
bpo-17799: Explain real behaviour of sys.settrace and sys.setprofile (GH-4056) (#5298)
https://github.com/python/cpython/commit/fd844efa9c31e1f00e04b07940875b9dacff3d77


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Wed Jan 24 09:53:44 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 14:53:44 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516805624.98.0.467229070634.issue17799@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset e64a47b37d0c592fd162b2f51e79ecfd046b45ec by Xiang Zhang in branch '2.7':
bpo-17799: Explain real behaviour of sys.settrace and sys.setprofile (GH-4056). (#5299)
https://github.com/python/cpython/commit/e64a47b37d0c592fd162b2f51e79ecfd046b45ec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Wed Jan 24 09:54:45 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 14:54:45 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1516805685.28.0.467229070634.issue17799@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:07:04 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 24 Jan 2018 15:07:04 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516806424.24.0.467229070634.issue32623@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:08:43 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 24 Jan 2018 15:08:43 +0000
Subject: [issue32650] Debug support for native coroutines is broken
Message-ID: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

pdb (and other Python debuggers) are built on top of bdb.py module.

The module has a support for stepping to next line in function (next command).

The command checks frame flags and do extra steps if the flags contains CO_GENERATOR.

But CO_COROUTINE is not supported, it leads to stepping into a native coroutine instead of expecting stepping over.

The patch should be relative simple: just add a check for CO_COROUTINE along with CO_GENERATOR everywhere.

----------
messages: 310600
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Debug support for native coroutines is broken
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:16:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 15:16:32 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1516806992.58.0.467229070634.issue32650@psf.upfronthosting.co.za>


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


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:37:19 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 15:37:19 +0000
Subject: [issue32651] os.getlogin() should recommend getpass.getuser()
Message-ID: <1516808239.87.0.467229070634.issue32651@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

The documentation for os.getlogin() says:

"Return the name of the user logged in on the controlling terminal of the process. For most purposes, it is more useful to use the environment variables LOGNAME or USERNAME to find out who the user is, or pwd.getpwuid(os.getuid())[0] to get the login name of the current real user id.

Availability: Unix, Windows."

Well, why not suggestion getpass.getuser() since that's exactly how the latter works? :)

----------
assignee: barry
components: Documentation
messages: 310601
nosy: barry
priority: normal
severity: normal
status: open
title: os.getlogin() should recommend getpass.getuser()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32651>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:38:06 2018
From: report at bugs.python.org (Arusekk)
Date: Wed, 24 Jan 2018 15:38:06 +0000
Subject: [issue17852] Built-in module _io can lose data from buffered files at
 exit
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1516808286.55.0.467229070634.issue17852@psf.upfronthosting.co.za>


Arusekk <arek_koz at o2.pl> added the comment:

Since the issue seems to have been active lately, may I suggest my view on solving it.

One solution that comes to my mind is to keep a weak reference to the file, and to register an atexit function per file (and to unregister it when the file is closed). Example concept-illustrating python code for the _pyio module:

import atexit, weakref

# ...

class TextIOWrapper(TextIOBase):
    def __init__(self):
        # ...
        self._weakclose = operator.methodcaller('close')
        atexit.register(self._weakclose, weakref.proxy(self))

    # ...

    def close(self):
        atexit.unregister(self._weakclose)
        # and now actually close the file

There is a possibility of a negative impact arising from the use of operator.methodcaller, because it may return something cached in future versions of python. There is also the issue of unregistering an atexit function during atexit processing. But the general idea seems to be simple and worth considering.

----------
nosy: +Arusekk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:40:26 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 15:40:26 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1516808426.02.0.467229070634.issue32645@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I now have a Win7 VM, I'll take a look at this later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:47:14 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 15:47:14 +0000
Subject: [issue32651] os.getlogin() should recommend getpass.getuser()
In-Reply-To: <1516808239.87.0.467229070634.issue32651@psf.upfronthosting.co.za>
Message-ID: <1516808834.97.0.467229070634.issue32651@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
keywords: +patch
pull_requests: +5148
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32651>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:02:09 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 24 Jan 2018 16:02:09 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516809729.57.0.467229070634.issue32623@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> * When dict size become 0, make the dict shared-empty, like dict.clear()

This will cause significant performance regression for `dict[a]=None; del dict[a]` loop.
del/pop shouldn't do clear().

> * When (dict size < dk_size/8), call insertion_resize()

This is bad too.
When ma_used=127 and dk_size=1024, new size will be 1024!
It's because current GROWTH_RATE is used*2 + size/2.

This GROWTH_RATE is set in issue17563.
We should understand it before changing anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:02:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:02:48 +0000
Subject: [issue28046] Remove the concept of platform-specific directories
In-Reply-To: <1473443913.59.0.936788039942.issue28046@psf.upfronthosting.co.za>
Message-ID: <1516809768.12.0.467229070634.issue28046@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 5de15f1d5ff09085620f63f0597d0920d75be719 by Victor Stinner in branch 'master':
bpo-28046: Remove MACHDEPPATH from Modules/Setup.dist (#5289)
https://github.com/python/cpython/commit/5de15f1d5ff09085620f63f0597d0920d75be719


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28046>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:03:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:03:30 +0000
Subject: [issue32030] PEP 432: Rewrite Py_Main()
In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za>
Message-ID: <1516809810.3.0.467229070634.issue32030@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 8ded5b803705328749622256701b3f08a9d6c5ab by Victor Stinner in branch 'master':
bpo-32030: Add _PyCoreConfig.module_search_paths (#4954)
https://github.com/python/cpython/commit/8ded5b803705328749622256701b3f08a9d6c5ab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32030>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:20:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:20:32 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516809729.57.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYnLphT73mzqKHctjzXMB-nXUhO-eVhXc13Hg4qvpUhLw@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

"This will cause significant performance regression for `dict[a]=None;
del dict[a]` loop. del/pop shouldn't do clear()."

Should we make sure that all dicts have at least MINSIZE entries?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:20:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:20:42 +0000
Subject: [issue28046] Remove the concept of platform-specific directories
In-Reply-To: <1473443913.59.0.936788039942.issue28046@psf.upfronthosting.co.za>
Message-ID: <1516810841.99.0.467229070634.issue28046@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Fixed. I close again the issue. I don't want to backport this change, it doesn't hurt Python 3.6.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28046>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:26:22 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 16:26:22 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516811182.98.0.467229070634.issue32636@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Nathaniel: do you want to include these fixes in your PR as well?

Victor, can you submit a new PR for this? Let's merge this right away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:31:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 16:31:08 +0000
Subject: [issue32643] Make Task._step,
 Task._wakeup and Future._schedule_callback methods private
In-Reply-To: <1516771939.71.0.467229070634.issue32643@psf.upfronthosting.co.za>
Message-ID: <1516811468.55.0.467229070634.issue32643@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 22feeb88b473b288950cdb2f6c5d28692274b5f9 by Yury Selivanov in branch 'master':
bpo-32643: Drop support for a few private Task and Future APIs. (#5293)
https://github.com/python/cpython/commit/22feeb88b473b288950cdb2f6c5d28692274b5f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32643>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:32:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:32:35 +0000
Subject: [issue32030] PEP 432: Rewrite Py_Main()
In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za>
Message-ID: <1516811555.13.0.467229070634.issue32030@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32030>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:35:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:35:34 +0000
Subject: [issue32652] test_distutils: BuildRpmTestCase tests fail on RHEL
 buildbots
Message-ID: <1516811734.58.0.467229070634.issue32652@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

It may be a regression introduced by commit 8ded5b803705328749622256701b3f08a9d6c5ab, bpo-32030: "Add _PyCoreConfig.module_search_paths", since it's the only change of the failing build 577.

s390x RHEL 3.x5:

http://buildbot.python.org/all/#/builders/21/builds/577

======================================================================
ERROR: test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/tests/test_bdist_rpm.py", line 120, in test_no_optimize_flag
    cmd.run()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/command/bdist_rpm.py", line 366, in run
    self.spawn(rpm_cmd)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/cmd.py", line 365, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 159, in _spawn_posix
    % (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

======================================================================
ERROR: test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/tests/test_bdist_rpm.py", line 77, in test_quiet
    cmd.run()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/command/bdist_rpm.py", line 366, in run
    self.spawn(rpm_cmd)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/cmd.py", line 365, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 159, in _spawn_posix
    % (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

----------
components: Tests
messages: 310614
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_distutils: BuildRpmTestCase tests fail on RHEL buildbots
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32652>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:31:19 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 16:31:19 +0000
Subject: [issue32643] Make Task._step,
 Task._wakeup and Future._schedule_callback methods private
In-Reply-To: <1516771939.71.0.467229070634.issue32643@psf.upfronthosting.co.za>
Message-ID: <1516811479.17.0.467229070634.issue32643@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32643>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:32:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:32:24 +0000
Subject: [issue32030] PEP 432: Rewrite Py_Main()
In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za>
Message-ID: <1516811544.18.0.467229070634.issue32030@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I made most, if not all, changes that I wanted to do. It's time to close this huge issue to continue the work in new more specific issues.

Notes on Py_Main().

(*) _PyPathConfig_Init() is called even if it's not needed (if all "Path configuration outputs" fileds of PyCoreConfig are filled).

(*) pymain_cmdline() uses _Py_CommandLineDetails structure which contains a copy of each global configuration variable like Py_UTF8Mode. Internally, the function has to "set" or "get" these variables when calling some functions like _PyPathConfig_Init().

This code is fragile. *But* pymain_read_conf() is complex, it had to read again the whole configuration a second time if the encoding changed.

It would be nice to remove global variables from _Py_CommandLineDetails to avoid the get/set dance which introduces a risk of loosing changes by mistake. But I'm not sure that it's doable?

(*) Should we make Py_FileSystemDefaultEncoding and Py_FileSystemDefaultEncodeErrors configurable in _PyCoreConfig? Same question for _Py_StandardStreamEncoding, _Py_StandardStreamErrors and PYTHONIOENCODING environment variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32030>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:29:43 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 16:29:43 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1516811383.01.0.467229070634.issue30491@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

So let's retarget this to 3.8 as it's too close to 3.7 feature freeze to get seriously considered/merged.

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:40:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:40:02 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516812002.35.0.467229070634.issue32636@psf.upfronthosting.co.za>


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


----------
pull_requests: +5149

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:40:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:40:20 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516812020.48.0.467229070634.issue32636@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Victor, can you submit a new PR for this? Let's merge this right away.

Ok, done: https://github.com/python/cpython/pull/5302

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:44:23 2018
From: report at bugs.python.org (Timur Irmatov)
Date: Wed, 24 Jan 2018 16:44:23 +0000
Subject: [issue32653] AttributeError: 'Task' object has no attribute
 '_callbacks'
Message-ID: <1516812263.42.0.467229070634.issue32653@psf.upfronthosting.co.za>


New submission from Timur Irmatov <irmatov at gmail.com>:

Sometimes during shutdown of our simple http server based on asyncio/ aiohttp we get following stack trace:

ERROR    [2018-01-24 08:28:33,398]: Exception in default exception handler while handling an unexpected error in custom exception handler
Traceback (most recent call last):
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1293, in call_exception_handler
    self._exception_handler(self, context)
  File "/opt/alt/python35/bin/imunify360-captchaserver", line 640, in _error_handler
    loop.default_exception_handler(context)
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1256, in default_exception_handler
    value = repr(value)
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 213, in __repr__
    info = self._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/tasks.py", line 96, in _repr_info
    info = super()._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 205, in _repr_info
    if self._callbacks:
AttributeError: 'Task' object has no attribute '_callbacks'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1301, in call_exception_handler
    'context': context,
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1256, in default_exception_handler
    value = repr(value)
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 213, in __repr__
    info = self._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/tasks.py", line 96, in _repr_info
    info = super()._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 205, in _repr_info
    if self._callbacks:
AttributeError: 'Task' object has no attribute '_callbacks'

Is this some bug or consequence of our code not cancelling/ waiting for all coroutines?

----------
components: asyncio
messages: 310616
nosy: Timur Irmatov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: AttributeError: 'Task' object has no attribute '_callbacks'
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32653>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:45:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 16:45:37 +0000
Subject: [issue32653] AttributeError: 'Task' object has no attribute
 '_callbacks'
In-Reply-To: <1516812263.42.0.467229070634.issue32653@psf.upfronthosting.co.za>
Message-ID: <1516812337.0.0.467229070634.issue32653@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Can you check if this happens on 3.6?  3.5 is in a security-fix mode only, so even if this is a bug it would take us a long time to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32653>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:56:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:56:05 +0000
Subject: [issue32030] PEP 432: Rewrite Py_Main()
In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za>
Message-ID: <1516812965.82.0.467229070634.issue32030@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh, my latest commit introduced a regression in test_distutils: bpo-32652.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32030>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:25:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 17:25:01 +0000
Subject: [issue32652] test_distutils: BuildRpmTestCase tests fail on RHEL
 buildbots
In-Reply-To: <1516811734.58.0.467229070634.issue32652@psf.upfronthosting.co.za>
Message-ID: <1516814701.14.0.467229070634.issue32652@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5150
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32652>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:31:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 17:31:20 +0000
Subject: [issue32654] Fixes Python for Android API 19
Message-ID: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

I'm working on a pull request to make https://github.com/pmp-p/droid-pydk/tree/master/sources.32/cpython-bpo-30386.patchset changes upstream.

----------
messages: 310619
nosy: vstinner
priority: normal
severity: normal
status: open
title: Fixes Python for Android API 19
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:31:36 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Wed, 24 Jan 2018 17:31:36 +0000
Subject: [issue32655] File mode shou
Message-ID: <1516815096.3.0.467229070634.issue32655@psf.upfronthosting.co.za>


Change by ????? ?????? <sidorovmarat1995 at gmail.com>:


----------
components: IO
nosy: nagayev
priority: normal
severity: normal
status: open
title: File mode shou
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32655>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:41:06 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Wed, 24 Jan 2018 17:41:06 +0000
Subject: [issue32655] File mode should be a constant
Message-ID: <1516815666.29.0.467229070634.issue32655@psf.upfronthosting.co.za>


New submission from ????? ?????? <sidorovmarat1995 at gmail.com>:

Hey guys,
I find bug in Python.
If you'll try to file stream using open function you can edit file mode:
Watch git:
https://gist.github.com/nagayev/7d17ead7b3bc2b06f2445fb5d9122a5c
In fact,mode don't changed,so mode shoul be constant like a encoding of the file and raise AttributeError if you'll edit it.

----------
title: File mode shou -> File mode should be a constant

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32655>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:51:31 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 17:51:31 +0000
Subject: [issue32651] os.getlogin() should recommend getpass.getuser()
In-Reply-To: <1516808239.87.0.467229070634.issue32651@psf.upfronthosting.co.za>
Message-ID: <1516816291.97.0.467229070634.issue32651@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset d499031f5f33c3ef71be7c81ef52eee6b47c42e1 by Barry Warsaw in branch 'master':
bpo-32651 Recommend getpass.getuser() (#5301)
https://github.com/python/cpython/commit/d499031f5f33c3ef71be7c81ef52eee6b47c42e1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32651>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:52:42 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Jan 2018 17:52:42 +0000
Subject: [issue32651] os.getlogin() should recommend getpass.getuser()
In-Reply-To: <1516808239.87.0.467229070634.issue32651@psf.upfronthosting.co.za>
Message-ID: <1516816362.54.0.467229070634.issue32651@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5151

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32651>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:56:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 17:56:50 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516816610.23.0.467229070634.issue32654@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5152
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Wed Jan 24 13:13:01 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Jan 2018 18:13:01 +0000
Subject: [issue32655] File mode should be a constant
In-Reply-To: <1516815666.29.0.467229070634.issue32655@psf.upfronthosting.co.za>
Message-ID: <1516817581.06.0.467229070634.issue32655@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That isn't a bug.  Python doesn't protect you from doing the wrong thing, in general.  On the other hand, it might be a worthwhile improvement to make it read-only in this case.  Especially since, as you point out, other seemingly similar attributes of this object are read-only.

----------
nosy: +r.david.murray
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32655>
_______________________________________

From report at bugs.python.org  Wed Jan 24 14:09:59 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 19:09:59 +0000
Subject: [issue32651] os.getlogin() should recommend getpass.getuser()
In-Reply-To: <1516808239.87.0.467229070634.issue32651@psf.upfronthosting.co.za>
Message-ID: <1516820999.53.0.467229070634.issue32651@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset 196b8cbab2b5044b92077f0b3c07c798fff68bc6 by Barry Warsaw (Miss Islington (bot)) in branch '3.6':
bpo-32651 Recommend getpass.getuser() (GH-5301) (#5304)
https://github.com/python/cpython/commit/196b8cbab2b5044b92077f0b3c07c798fff68bc6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32651>
_______________________________________

From report at bugs.python.org  Wed Jan 24 14:10:16 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 19:10:16 +0000
Subject: [issue32651] os.getlogin() should recommend getpass.getuser()
In-Reply-To: <1516808239.87.0.467229070634.issue32651@psf.upfronthosting.co.za>
Message-ID: <1516821016.62.0.467229070634.issue32651@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32651>
_______________________________________

From report at bugs.python.org  Wed Jan 24 14:40:38 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 24 Jan 2018 19:40:38 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516822838.23.0.467229070634.issue32410@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 0a5e71b4c70aab87125a54d7a59765e18d7583a4 by Andrew Svetlov in branch 'master':
bpo-32410: Improve sock_sendfile tests (#5294)
https://github.com/python/cpython/commit/0a5e71b4c70aab87125a54d7a59765e18d7583a4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Wed Jan 24 14:42:42 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 24 Jan 2018 19:42:42 +0000
Subject: [issue32410] Implement loop.sock_sendfile method
In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za>
Message-ID: <1516822962.13.0.467229070634.issue32410@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32410>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:14:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 20:14:35 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516824875.21.0.467229070634.issue32636@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset fb5a7ad421ac20c49218ee4b86fb0d85ca4cd664 by Yury Selivanov (Nathaniel J. Smith) in branch 'master':
bpo-32636: Fix @asyncio.coroutine debug mode bug exposed by gh-5250 (#5291)
https://github.com/python/cpython/commit/fb5a7ad421ac20c49218ee4b86fb0d85ca4cd664


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:15:15 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 20:15:15 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516824915.99.0.467229070634.issue32636@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 789e359f51d2b27bea01b8c6c3bf090aaedf8839 by Yury Selivanov (Victor Stinner) in branch 'master':
bpo-32636: Fix two bugs in test_asyncio (#5302)
https://github.com/python/cpython/commit/789e359f51d2b27bea01b8c6c3bf090aaedf8839


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:16:07 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 20:16:07 +0000
Subject: [issue32636] test_asyncio fails with PYTHONASYNCIODEBUG=1
In-Reply-To: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>
Message-ID: <1516824967.21.0.467229070634.issue32636@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This can probably be closed now. Thanks Victor and Nathaniel!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:36:24 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 20:36:24 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516826184.39.0.467229070634.issue32248@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset 6f6eb35f9bee18f54945f09664344f2d118ed89f by Barry Warsaw in branch 'master':
 bpo-32248 - Implement `ResourceReader` and `get_resource_reader()` for zipimport (#5248)
https://github.com/python/cpython/commit/6f6eb35f9bee18f54945f09664344f2d118ed89f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:38:34 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 20:38:34 +0000
Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7
In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za>
Message-ID: <1516826314.06.0.467229070634.issue32248@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Now that the zipimporter support has landed, I think we're done!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32248>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:48:18 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 20:48:18 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516826898.14.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Stefan, it would be great to have this committed before 3.7 feature freeze.

The change is pretty straightforward -- we replaced threading.local() with a contextvar, which should be a backwards compatible change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:54:41 2018
From: report at bugs.python.org (David Albert Torpey)
Date: Wed, 24 Jan 2018 20:54:41 +0000
Subject: [issue32656] writing to stdout prints extraneous size character
Message-ID: <1516827281.38.0.467229070634.issue32656@psf.upfronthosting.co.za>


New submission from David Albert Torpey <dtorp at users.sourceforge.net>:

$ python3.5
Python 3.5.3 (v3.5.3:1880cb95a742, Jan 16 2017, 08:49:46)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.write('python')
python6

----------
messages: 310631
nosy: dtorp
priority: normal
severity: normal
status: open
title: writing to stdout prints extraneous size character
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32656>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:59:04 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 24 Jan 2018 20:59:04 +0000
Subject: [issue32656] writing to stdout prints extraneous size character
In-Reply-To: <1516827281.38.0.467229070634.issue32656@psf.upfronthosting.co.za>
Message-ID: <1516827544.69.0.467229070634.issue32656@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This is not a bug, it's a side effect of using the REPL for this test and not assigning the return value of `sys.stdout.write` to anything.  Try the following:

>>> import sys
>>> character_count = sys.stdout.write('python\n') # note trailing newline
python
>>> character_count
6
>>> print('python')
python
>>> 

Or try saving your original test to a file and running it.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32656>
_______________________________________

From report at bugs.python.org  Wed Jan 24 16:00:22 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 24 Jan 2018 21:00:22 +0000
Subject: [issue32656] writing to stdout prints extraneous size character
In-Reply-To: <1516827281.38.0.467229070634.issue32656@psf.upfronthosting.co.za>
Message-ID: <1516827622.4.0.467229070634.issue32656@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Of course, I realize after clicking "submit" that my character count there is actually wrong, and should be 7.  That's what I get for writing out the example instead of actually running and copying it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32656>
_______________________________________

From report at bugs.python.org  Wed Jan 24 16:13:36 2018
From: report at bugs.python.org (Keith)
Date: Wed, 24 Jan 2018 21:13:36 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1516828416.91.0.467229070634.issue24132@psf.upfronthosting.co.za>


Keith <keithy at consultant.com> added the comment:

Look at the architecture of Rio in Ruby (also ported to Squeak/Smalltalk)

Leave Path to handle path stuff, and have another class to handle Platform stuff.

https://rubygems.org/gems/rio/versions/0.6.0

----------
nosy: +keithy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Wed Jan 24 16:22:04 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 24 Jan 2018 21:22:04 +0000
Subject: [issue17882] test_objecttypes fails for 3.2.4 on CentOS 6
In-Reply-To: <1367340943.59.0.839415774822.issue17882@psf.upfronthosting.co.za>
Message-ID: <1516828924.96.0.467229070634.issue17882@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I believe this may have been fixed in #19527.

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17882>
_______________________________________

From report at bugs.python.org  Wed Jan 24 16:26:21 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Jan 2018 21:26:21 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516829181.45.0.467229070634.issue29708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:


New changeset ccbe5818af20f8c12043f5c30c277a74714405e0 by Brett Cannon (Bernhard M. Wiedemann) in branch 'master':
bpo-29708: Setting SOURCE_DATE_EPOCH forces hash-based .pyc files (GH-5200)
https://github.com/python/cpython/commit/ccbe5818af20f8c12043f5c30c277a74714405e0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Jan 24 16:27:17 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Jan 2018 21:27:17 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516829237.79.0.467229070634.issue29708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just merged Bernhard's PR which forces hash-based .pyc files. Thanks to everyone who constructively helped reach this point.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Jan 24 16:30:03 2018
From: report at bugs.python.org (bharper)
Date: Wed, 24 Jan 2018 21:30:03 +0000
Subject: [issue17882] test_objecttypes fails for 3.2.4 on CentOS 6
In-Reply-To: <1367340943.59.0.839415774822.issue17882@psf.upfronthosting.co.za>
Message-ID: <1516829403.74.0.467229070634.issue17882@psf.upfronthosting.co.za>


bharper <ben.harper at rackspace.com> added the comment:

Hey all,

I am not having this issue on other versions of python.  Seeing that python 3.2 is EOL, lets just close this issue.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17882>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:29:37 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Jan 2018 22:29:37 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1516832977.05.0.467229070634.issue10381@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:


New changeset 04af5b1ba9eb546a29735fac6cb5298159069b53 by Alexander Belopolsky (Paul Ganssle) in branch 'master':
bpo-10381: Add timezone to datetime C API (#5032)
https://github.com/python/cpython/commit/04af5b1ba9eb546a29735fac6cb5298159069b53


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:30:32 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 24 Jan 2018 22:30:32 +0000
Subject: [issue32391] Add StreamWriter.wait_closed()
In-Reply-To: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za>
Message-ID: <1516833032.66.0.467229070634.issue32391@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset fe133aad52222949db7309c26c58b066c22e714e by Andrew Svetlov in branch 'master':
bpo-32391: Implement StreamWriter.wait_closed() (#5281)
https://github.com/python/cpython/commit/fe133aad52222949db7309c26c58b066c22e714e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32391>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:30:42 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Jan 2018 22:30:42 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1516833042.85.0.467229070634.issue10381@psf.upfronthosting.co.za>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:38:05 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 24 Jan 2018 22:38:05 +0000
Subject: [issue17882] test_objecttypes fails for 3.2.4 on CentOS 6
In-Reply-To: <1367340943.59.0.839415774822.issue17882@psf.upfronthosting.co.za>
Message-ID: <1516833485.31.0.467229070634.issue17882@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
resolution:  -> out of date
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17882>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:44:57 2018
From: report at bugs.python.org (Kenny Trytek)
Date: Wed, 24 Jan 2018 22:44:57 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
Message-ID: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>


New submission from Kenny Trytek <kenny.trytek at workiva.com>:

Mutable arguments in signature of send_message:
https://github.com/python/cpython/blob/master/Lib/smtplib.py#L892-L893

More Information:
http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments

----------
components: Library (Lib)
messages: 310641
nosy: Kenny Trytek
priority: normal
severity: normal
status: open
title: Mutable Objects in SMTP send_message Signature
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:49:00 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 24 Jan 2018 22:49:00 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516834140.1.0.467229070634.issue18533@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

It looks like Serhiy approved the PR on 12/13.  Is it ready to merge?  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:51:17 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 24 Jan 2018 22:51:17 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1516834277.29.0.467229070634.issue27505@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Nick, 

It looks like #32225 took care of this documentation change, so I think this can be closed?  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Wed Jan 24 18:21:26 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 24 Jan 2018 23:21:26 +0000
Subject: [issue32391] Add StreamWriter.wait_closed()
In-Reply-To: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za>
Message-ID: <1516836086.18.0.467229070634.issue32391@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32391>
_______________________________________

From report at bugs.python.org  Wed Jan 24 18:39:01 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 24 Jan 2018 23:39:01 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516837141.09.0.467229070634.issue18533@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Not ready to merge.
1. We need the Appveyer test to pass or special action from the gateway gods.
2. After a month, the PR needed to be updated and retested anyway.  I pulled, updated, pushed the update (which will trigger Travis and AV), and tested on my Windows machine. The two new tests fail.  See PR.
3. Someone has to sell assign and merge when ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Wed Jan 24 18:42:47 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 24 Jan 2018 23:42:47 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516837367.79.0.467229070634.issue18533@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Hold the failure comment.  I forgot that I have to recompile when patch changes .c files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Wed Jan 24 18:57:13 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 24 Jan 2018 23:57:13 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516838233.67.0.467229070634.issue18533@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

OK, test_dictviews and test_ordered_dict now pass for me, and Appveyor already ran entire suite and says OK to all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:01:01 2018
From: report at bugs.python.org (Kevin Raeder)
Date: Thu, 25 Jan 2018 00:01:01 +0000
Subject: [issue32658] Metacharacter (\) documentation suggestion
Message-ID: <1516838461.29.0.467229070634.issue32658@psf.upfronthosting.co.za>


New submission from Kevin Raeder <raeder at ucar.edu>:

I've found the Regular Expression HOWTO to be very helpful
(https://docs.python.org/3/howto/regex.html?highlight=regular%20expressions). 
One inconsistency I noticed is that the intro to metacharacters says
"Metacharacters are not active inside classes. "
But farther down we learn that a class can be constructed using \s: [\s,.],
which is "all white space characters , and ."
It's not the 4 characters "\ s , and ."
So I think the first statement would be clearer as
"Metacharacters (except \) are not active inside classes. "

----------
assignee: docs at python
components: Documentation
messages: 310647
nosy: docs at python, kdraeder
priority: normal
severity: normal
status: open
title: Metacharacter (\) documentation suggestion

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32658>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:13:20 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 25 Jan 2018 00:13:20 +0000
Subject: [issue17852] Built-in module _io can lose data from buffered files at
 exit
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1516839200.6.0.467229070634.issue17852@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Using atexit is not the solution because the data can be lost even while the program is running, not just at interpreter shutdown.  The problem occurs if the buffered file object and the underlying file object are both part of a reference cycle.  Then, when the cycle is destroyed by the GC module, if the file __del__ is called before the buffer __del__, data is lost.

So far, the best solution I've come up with is as follows:  split the buffered file object into two objects, a wrapper object that will be returned from open() and an underlying object that holds the actual buffer.  Make the underlying file object keep references to all the buffers that are using the file.  When the file _del__ gets called, first flush all of the buffers and then close the file.  Splitting the buffered file object is required so that we don't create reference cycles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:46:17 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 25 Jan 2018 00:46:17 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516841177.46.0.467229070634.issue32623@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> Should we make sure that all dicts have at least MINSIZE entries?

I don't think so.  I think "allocate on first insert" is good idea for dict.clear()
And I think it's good idea for new dict too:
https://github.com/python/cpython/pull/1080

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:46:54 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Jan 2018 00:46:54 +0000
Subject: [issue32659] Solaris "stat" should support "st_fstype"
Message-ID: <1516841214.25.0.467229070634.issue32659@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Solaris has an extra "st_fstype" in the "stat" structure:

"""
       st_fstype
                     A null-teminated string that uniquely identifies the type
                     of the filesystem that contains the file.
"""

Supporting this should be trivial and 3.7RC1 is still a week away. I can take care of the patch for Python 3.7, if you agree that this must be fixed.

----------
assignee: jcea
messages: 310650
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: Solaris "stat" should support "st_fstype"
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32659>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:53:52 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Jan 2018 00:53:52 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516841632.39.0.467229070634.issue29708@psf.upfronthosting.co.za>


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


----------
pull_requests: +5153

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:56:59 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Jan 2018 00:56:59 +0000
Subject: [issue32660] Solaris should support constants like termios' FIONREAD
Message-ID: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Solaris supports termios constants like FIONREAD with an appropiate "#include" in the C code. The main issue is that some names conflicts between System V and BSD personalities.

I could evaluate the situation and do a patch proposal for Python 3.7. We are still a week away of 3.7RC1 and this patch would affect only Solaris/derivatives.

----------
assignee: jcea
messages: 310651
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: Solaris should support constants like termios' FIONREAD
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32660>
_______________________________________

From report at bugs.python.org  Wed Jan 24 20:13:26 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Jan 2018 01:13:26 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516842806.78.0.467229070634.issue29708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:


New changeset cab0b2b053970982b760048acc3046363615a8dd by Brett Cannon in branch 'master':
bpo-29708: Add What's New entries for SOURCE_DATE_EPOCH and py_compile (GH-5306)
https://github.com/python/cpython/commit/cab0b2b053970982b760048acc3046363615a8dd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Jan 24 20:33:14 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 25 Jan 2018 01:33:14 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516843994.68.0.467229070634.issue32513@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Raising for order=True if one of the ordering dunders exists sounds fine.

I am confused by the corner case for hash. Your table:

"""
eq=?	frozen=?	__hash__
False	False		do not generate __hash__
False	True		do not generate __hash__
True	False		set __hash__ to None unless it already exists
True	True		generate __hash__ unless it already exists
                         and is None
"""

Then you write at the end of that message:

"""
One special case to recognize is if the class defines a __eq__. In this case, Python will assign __hash__=None before the dataclass decorator is called. The decorator cannot distinguish between these two cases (except possibly by using the order of __dict__ keys, but that seems overly fragile):

@dataclass
class A:
    def __eq__(self, other): pass

@dataclass
class B:
    def __eq__(self, other): pass
    __hash__ = None

This is the source of the last line in the above table: for a dataclass where eq=True, frozen=True, and hash=None, if __hash__ is None it will still be overwritten. The assumption is that this is what the user wants, but it's a tricky corner case. It also occurs if setting hash=True and defining __eq__. Again, it's not expected to come up in normal usage.
"""

I think I understand what you are saying there -- the two cases are treated the same, and a __hash__ is created (assuming the decorator is really "@dataclass(eq=True, frozen=True)"), overwriting the "__hash__ = None" for class B.

However the table's last line says "generate __hash__ unless it already exists and is None". Perhaps that was a typo and you meant to write "and is *not* None"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Wed Jan 24 21:07:15 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 25 Jan 2018 02:07:15 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1516846035.49.0.467229070634.issue32623@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I think I understand #17563, and I should fix GROWTH_RATE.

Before compact-ordered dict, we can avoid resizing in
"the number of deletions is on a par with the number of insertions."
scenario, by large GROWTH_RATE.
That's because new entry can reuse dummy entries.

But in compact-ordered dict, we can't do that.
We need resizing always, and resize is much faster than legacy dict.

I think GROWTH_RATE should be ma_used*3 for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Wed Jan 24 22:02:14 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Jan 2018 03:02:14 +0000
Subject: [issue32659] Solaris "stat" should support "st_fstype"
In-Reply-To: <1516841214.25.0.467229070634.issue32659@psf.upfronthosting.co.za>
Message-ID: <1516849334.51.0.467229070634.issue32659@psf.upfronthosting.co.za>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
keywords: +patch
pull_requests: +5154
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32659>
_______________________________________

From report at bugs.python.org  Wed Jan 24 22:24:15 2018
From: report at bugs.python.org (Roger Taylor)
Date: Thu, 25 Jan 2018 03:24:15 +0000
Subject: [issue32661] ProactorEventLoop locks up on close call
Message-ID: <1516850655.32.0.467229070634.issue32661@psf.upfronthosting.co.za>


New submission from Roger Taylor <roger.taylor.email at gmail.com>:

The following problem only occurs when I use ProactorEventLoop.  If I use 'asyncio.get_event_loop()' it exits normally, rather than infinite looping in IOCP land.

1. I run the attached 'bug.py' script in a DOS window.  It is a slightly modified version of the asyncio echo server example.
2. It reaches 'loop.run_forever()' and blocks.  I can make connections here and use it as an echo server.  Or make no connections.
3. I press Ctrl-C in the DOS window.  Nothing happens.
4. I do a raw connection with Putty and try some input.
5. 'run_forever()' exits and the script proceeds to the 'loop.close()' call.  Before this is invoked and the infinite loop entered, I see the script output '<ProactorEventLoop running=False closed=False debug=False>'.

At this point, the script locks up and never reaches the next line.  It can be interrupted with another Ctrl-C, and the following stack track is seen:

	Traceback (most recent call last):
	  File "bug.py", line 39, in <module>
		loop.close()
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\proactor_events.py", line 437, in close
		self._proactor.close()
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\windows_events.py", line 745, in close
		if not self._poll(1):
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\windows_events.py", line 673, in _poll
		status = _overlapped.GetQueuedCompletionStatus(self._iocp, ms)
	KeyboardInterrupt

The following code in 'windows_events.py:IocpProactor.close' is looping infinitely.

        while self._cache:
            if not self._poll(1):
                logger.debug('taking long time to close proactor')

Note that '_poll' does not actually return anything.

----------
components: asyncio
files: bug.py
messages: 310655
nosy: asvetlov, rt121212121, yselivanov
priority: normal
severity: normal
status: open
title: ProactorEventLoop locks up on close call
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47408/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32661>
_______________________________________

From report at bugs.python.org  Wed Jan 24 23:19:15 2018
From: report at bugs.python.org (Erik Paulson)
Date: Thu, 25 Jan 2018 04:19:15 +0000
Subject: [issue32628] Add configurable DirectoryIndex to http.server
In-Reply-To: <1516681005.05.0.467229070634.issue32628@psf.upfronthosting.co.za>
Message-ID: <1516853955.69.0.467229070634.issue32628@psf.upfronthosting.co.za>


Change by Erik Paulson <epaulson at unit1127.com>:


----------
keywords: +patch
pull_requests: +5155
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32628>
_______________________________________

From report at bugs.python.org  Thu Jan 25 00:01:57 2018
From: report at bugs.python.org (Marcel Widjaja)
Date: Thu, 25 Jan 2018 05:01:57 +0000
Subject: [issue12706] timeout sentinel in ftplib and poplib documentation
In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>
Message-ID: <1516856517.42.0.467229070634.issue12706@psf.upfronthosting.co.za>


Change by Marcel Widjaja <mwidj at yahoo.com>:


----------
pull_requests: +5156
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12706>
_______________________________________

From report at bugs.python.org  Thu Jan 25 00:14:55 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Thu, 25 Jan 2018 05:14:55 +0000
Subject: [issue31972] Inherited docstrings for pathlib classes are confusing
In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za>
Message-ID: <1516857295.24.0.467229070634.issue31972@psf.upfronthosting.co.za>


Change by Chason Chaffin <chason at gmail.com>:


----------
pull_requests: +5157

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31972>
_______________________________________

From report at bugs.python.org  Thu Jan 25 00:39:01 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 25 Jan 2018 05:39:01 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1516858741.93.0.467229070634.issue27505@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think the only thing missing for the 3.7 docs now would be a pair of "versionchanged" notes indicating that __class__ has been settable since 3.5, while module level __dir__ and __getattr__ support is new in 3.7.

It would also be desirable to add the __class__ docs to the 3.6 maintenance branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Thu Jan 25 01:44:24 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 06:44:24 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
Message-ID: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

As discussed, we want to make Server objects more usable in async/await code and more compatible with asyncio.run.

This is also needed to handle a use case when two or more servers are created and need to start listening at the same time.

We propose to:

1. Add a new bool flag defaulting to True to loop.create_server and loop.create_unix_server: start_serving.  By default, loop will return a server that is already accepting connections.  When start_serving is set to False, create_server and create_unix_server will return a server that will not listen on its sockets.

2. A new idempotent Server.start_serving() method can be used to make server listen on its sockets (useful when a server object was created with start_serving=False).

3. A new Server.serve_forever() method that calls start_serving() and blocks forever, until cancelled.  When cancelled, it closes its server object.

4. A new Server.is_serving() method.  This is useful to introspect a server object in unittests.

5. Server objects should be async context managers.  Server.__aexit__ should close the server and await on Server.wait_closed().

With these new APIs, the following pattern becomes possible:

    async def main():
        srv = await asyncio.start_server(...)
        async with srv:
            await srv.serve_forever()

    asyncio.run(main())

----------
components: asyncio
messages: 310657
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement Server.serve_forever and corresponding APIs
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Thu Jan 25 01:47:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 06:47:37 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516862857.17.0.467229070634.issue32662@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5158
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Thu Jan 25 02:00:02 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 25 Jan 2018 07:00:02 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1516863602.79.0.467229070634.issue32657@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Hi Kenny, and thanks, but I'm not sure what your point is. Are you claiming this is a bug in the code or the documentation?

For what it is worth... mutable defaults *are* a "gotcha", so the documentation isn't wrong. And mutable defaults are *not* illegal nor a bug and are occasionally useful. So I'm not sure why you are reporting this? Have you found a problem?

(I see that send_message gives rcpt_options a default of {} (empty dict) and then passes it to sendmail, which expects rcpt_options to be a list. I don't know if that matters.)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 02:19:14 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 25 Jan 2018 07:19:14 +0000
Subject: [issue17852] Built-in module _io can lose data from buffered files at
 exit
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1516864754.42.0.467229070634.issue17852@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> I attempted to implement my weakref idea (i.e. raw file keeps a weakref to the buffered file, calls flush before the raw file gets closed).  That doesn't work either because the GC clears the weakref before calling __del__.

This may be a bit of a left-field or too-big-a-hammer suggestion, but as far I can tell from this thread [1] it probably is technically possible to modify the GC to clear weakrefs after calling __del__. Nick wasn't a fan (he likes the invariant that weakrefs can't trigger a resurrection), but if all else fails it might be worth re-raising.

You could add a secondary reference count on FileIO recording how many BufferedIO wrappers there are around it; then it's __del__ would skip calling close() if there are still BufferedIO wrappers, and BufferedIO.__del__ would decrement the reference count and close the underlying file if it hits zero and FileIO.__del__ had already been called.

[1] https://mail.python.org/pipermail/python-dev/2016-October/146747.html

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Thu Jan 25 02:25:23 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Thu, 25 Jan 2018 07:25:23 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1516865123.61.0.467229070634.issue32657@psf.upfronthosting.co.za>


Chason Chaffin <chason at gmail.com> added the comment:

Hi Steven,

I have nothing to do with the original submitter but this bug did catch my eye. Does using mutable variables in the SMTP library serve a purpose? Looking through the code, I wasn't able to spot anything obvious, and I did spot a place with a potential bug:

https://github.com/python/cpython/blob/master/Lib/smtplib.py#L960

Here mail_options is mutated in the case of a non-ASCII email address. Subsequent calls to send_message, even to a different SMTP server (if I'm not mistaken) would also send these headers along.

----------
nosy: +chason

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 02:55:24 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Thu, 25 Jan 2018 07:55:24 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516866924.36.0.467229070634.issue29708@psf.upfronthosting.co.za>


Change by Alexandru Ardelean <ardeleanalex at gmail.com>:


----------
pull_requests: +5159

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:07:47 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Thu, 25 Jan 2018 08:07:47 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516867667.9.0.467229070634.issue29708@psf.upfronthosting.co.za>


Alexandru Ardelean <ardeleanalex at gmail.com> added the comment:

Hey,

Sorry, if I'm a bit late to the party with this.
The road to reproducible builds has a few more steps.

The way I validate whether Python is reproducible is with this link:
https://tests.reproducible-builds.org/lede/lede_ar71xx.html

There is a need to also patch getbuildinfo.c to make Python reproducible.

I have opened a PR for this : https://github.com/python/cpython/pull/5313

I've waited for the periodic build to trigger on that reproducible page.
In OpenWrt, the packages to look for [that is affected by this getbuildinfo.c patch] are python-base & python3-base.

There are still some python3 packages that need patching.
Seems that python3-asyncio, pydoc, and some other pyc files need investigation.
I'll check.
Maybe this isn't an issue in 3.7.

Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:08:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 08:08:39 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1516867719.63.0.467229070634.issue10381@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Hunting reference leaks with "./python -m test -R 3:3 test_datetime" crashs since the commit 04af5b1ba9eb546a29735fac6cb5298159069b53.

***
vstinner at apu$ ./python -m test -R 3:3 test_datetime 
Run tests sequentially
0:00:00 load avg: 1.05 [1/1] test_datetime
beginning 6 repetitions
123456
Fatal Python error: Segmentation fault

Current thread 0x00007ff71fe33040 (most recent call first):
  File "/home/vstinner/prog/python/master/Lib/test/datetimetester.py", line 5464 in test_utc_capi
  (...)
Segmentation fault (core dumped)
***

Shorter example without -R, just run the same test twice:
***
vstinner at apu$ ./python -m test -v test_datetime test_datetime -m test_utc_capi
== CPython 3.7.0a4+ (heads/master:cab0b2b053, Jan 25 2018, 09:06:01) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)]
== Linux-4.14.13-300.fc27.x86_64-x86_64-with-fedora-27-Twenty_Seven little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_26308
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.26 [1/2] test_datetime
test_utc_capi (test.datetimetester.CapiTest_Pure) ... skipped 'Not relevant in pure Python'
test_utc_capi (test.datetimetester.CapiTest_Fast) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK (skipped=1)
0:00:00 load avg: 1.26 [2/2] test_datetime
test_utc_capi (test.datetimetester.CapiTest_Pure) ... skipped 'Not relevant in pure Python'
test_utc_capi (test.datetimetester.CapiTest_Fast) ... Fatal Python error: Segmentation fault

Current thread 0x00007f9836b31040 (most recent call first):
  File "/home/vstinner/prog/python/master/Lib/test/datetimetester.py", line 5464 in test_utc_capi
  (...)
Segmentation fault (core dumped)
***

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:18:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 08:18:39 +0000
Subject: [issue32652] test_distutils: BuildRpmTestCase tests fail on RHEL
 buildbots
In-Reply-To: <1516811734.58.0.467229070634.issue32652@psf.upfronthosting.co.za>
Message-ID: <1516868319.42.0.467229070634.issue32652@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 2b822a0bb1de2612c85d8f75e3ce89eda2ac9f68 by Victor Stinner in branch 'master':
bpo-32652: Defer pymain_set_global_config() call (#5303)
https://github.com/python/cpython/commit/2b822a0bb1de2612c85d8f75e3ce89eda2ac9f68


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32652>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:41:56 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Thu, 25 Jan 2018 08:41:56 +0000
Subject: [issue32663] SMTPUTF8SimTests are not actually being run
Message-ID: <1516869716.21.0.467229070634.issue32663@psf.upfronthosting.co.za>


New submission from Chason Chaffin <chason at gmail.com>:

In the tests for smtplib, the suite of tests for SMTPUTF8SimTests (added by issue 24218)  are not actually being run. This is troublesome in particular, because the test test_send_message_error_on_non_ascii_addrs_if_no_smtputf8 calls assertRaises incorrectly and thus fails.

----------
components: Tests
messages: 310664
nosy: chason
priority: normal
severity: normal
status: open
title: SMTPUTF8SimTests are not actually being run
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32663>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:49:45 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 25 Jan 2018 08:49:45 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516870185.35.0.467229070634.issue32571@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset f320be77ffb73e3b9e7fc98c37b8df3975d84b40 by INADA Naoki (Serhiy Storchaka) in branch 'master':
 bpo-32571: Avoid raising unneeded AttributeError and silencing it in C code (GH-5222)
https://github.com/python/cpython/commit/f320be77ffb73e3b9e7fc98c37b8df3975d84b40


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:54:10 2018
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 25 Jan 2018 08:54:10 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
Message-ID: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>


New submission from Richard Neumann <r.neumann at homeinfo.de>:

In the documentation of the built-in exceptions hierarchy, there is a "|" missing connecting ImportError and LookupError.

https://docs.python.org/3/library/exceptions.html#exception-hierarchy

>From LookupError.__mro__ we can tell, that it is actually derived from Exception, thus there should be a "|" connecting it to the hierarchy under Exception to emphasize that (like between ArithmeticError and AssertionError).

----------
assignee: docs at python
components: Documentation
messages: 310666
nosy: Richard Neumann, docs at python
priority: normal
severity: normal
status: open
title: Connector "|"  missing between ImportError and LookupError
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Thu Jan 25 04:04:21 2018
From: report at bugs.python.org (Nitish)
Date: Thu, 25 Jan 2018 09:04:21 +0000
Subject: [issue32655] File mode should be a constant
In-Reply-To: <1516815666.29.0.467229070634.issue32655@psf.upfronthosting.co.za>
Message-ID: <1516871061.48.0.467229070634.issue32655@psf.upfronthosting.co.za>


Nitish <nitishch at protonmail.com> added the comment:

It appears some files like Lib/tokenize.py changes the mode of TextIOWrapper:

        text = TextIOWrapper(buffer, encoding, line_buffering=True)
        text.mode = 'r'

setting of mode via _PyObject_SetAttrId(wrapper, &PyId_mode, modeobj) is done in some source files too.

What I don't understand is since TextIOWrapper doesn't store the mode explicitly, this only adds 'mode' variable to the the object's dict. So why bother setting the mode in all these files?

----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32655>
_______________________________________

From report at bugs.python.org  Thu Jan 25 04:08:56 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Thu, 25 Jan 2018 09:08:56 +0000
Subject: [issue32663] SMTPUTF8SimTests are not actually being run
In-Reply-To: <1516869716.21.0.467229070634.issue32663@psf.upfronthosting.co.za>
Message-ID: <1516871336.93.0.467229070634.issue32663@psf.upfronthosting.co.za>


Change by Chason Chaffin <chason at gmail.com>:


----------
keywords: +patch
pull_requests: +5160
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32663>
_______________________________________

From report at bugs.python.org  Thu Jan 25 04:40:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 25 Jan 2018 09:40:05 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516873205.48.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'll look at the hash question later today. It's sufficiently complex that I really want to sit down and work through all of the cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Thu Jan 25 05:08:58 2018
From: report at bugs.python.org (Lele Gaifax)
Date: Thu, 25 Jan 2018 10:08:58 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1516874938.48.0.467229070634.issue27645@psf.upfronthosting.co.za>


Lele Gaifax <lelegaifax at gmail.com> added the comment:

I suspect this won't land in 3.7...

Let me know if I can do something to make that happen, or instead if I should try to rebase the change on top of current master and rectify references to the Python version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Thu Jan 25 05:32:09 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 25 Jan 2018 10:32:09 +0000
Subject: [issue32360] Save OrderedDict imports in various stdlibs.
In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za>
Message-ID: <1516876329.51.0.467229070634.issue32360@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5161

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32360>
_______________________________________

From report at bugs.python.org  Thu Jan 25 05:53:02 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 25 Jan 2018 10:53:02 +0000
Subject: [issue32360] Save OrderedDict imports in various stdlibs.
In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za>
Message-ID: <1516877582.16.0.467229070634.issue32360@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 2812d3d99287c50bab99625d7240bcf1c2e32369 by INADA Naoki in branch 'master':
bpo-32360: Remove OrderedDict usage from json.tool (GH-5315)
https://github.com/python/cpython/commit/2812d3d99287c50bab99625d7240bcf1c2e32369


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32360>
_______________________________________

From report at bugs.python.org  Thu Jan 25 06:56:46 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 25 Jan 2018 11:56:46 +0000
Subject: [issue32596] Lazy import concurrent.futures.process and thread
In-Reply-To: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>
Message-ID: <1516881406.54.0.467229070634.issue32596@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5162

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Thu Jan 25 07:27:25 2018
From: report at bugs.python.org (qb-cea)
Date: Thu, 25 Jan 2018 12:27:25 +0000
Subject: [issue32665] pathlib.Path._from_parsed_parts should call
 cls.__new__(cls)
Message-ID: <1516883245.2.0.467229070634.issue32665@psf.upfronthosting.co.za>


New submission from qb-cea <quentin.bouget at cea.fr>:

Hi,

I tried subclassing pathlib.Path and provide it with a new attribute (basically an accessor to an extended attribute). I am rather new to the concept of __slots__ and __new__() but here is how I pictured it should look:

from errno import ENODATA
from os import getxattr, setxattr
from pathlib import Path

class Path_(type(Path())):

    __slots__ = ("new_attr",)

    def __new__(cls, *args, new_attr=None, **kwargs):
        self = super().__new__(cls, *args, **kwargs)
        self._new_attr = new_attr
        return self

    @property
    def new_attr(self):
        if self._new_attr:
            return self._new_attr

        try:
            new_attr = getxattr(self, "user.new_attr")
        except OSError as exc:
            if exc.errno != ENODATA:
                raise exc
        else:
            self._new_attr = new_attr
            return new_attr

        new_attr = b"something_dynamic" # for example uuid4().bytes
        setxattr(self, "user.new_attr", new_attr)
        self._new_attr = new_attr
        return new_attr

The issue I have is that although my class defines its own __new__() method, it is not always called by the methods of pathlib.Path. For example:

>>> Path_("/etc").parent.new_attr
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/path/to/reproducer.py", line 19, in new_attr
    if self._new_attr:
AttributeError: _new_attr

The current workaround I use consists in redefining pathlib.Path's _from_parsed_parts() method in my class: instead of creating a new object using:
    object.__new__(cls)
my implementation uses:
    cls.__new__(cls)

This is the first time I play with the __new__() special method, so it is possible I missed something, if so, sorry for the noise.

----------
components: Library (Lib)
files: reproducer.py
messages: 310671
nosy: pitrou, qb-cea
priority: normal
severity: normal
status: open
title: pathlib.Path._from_parsed_parts should call cls.__new__(cls)
versions: Python 3.6
Added file: https://bugs.python.org/file47409/reproducer.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32665>
_______________________________________

From report at bugs.python.org  Thu Jan 25 07:38:38 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 25 Jan 2018 12:38:38 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1516883918.84.0.467229070634.issue32637@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:27:11 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 25 Jan 2018 13:27:11 +0000
Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary
 mode
In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za>
Message-ID: <1516886831.71.0.467229070634.issue32236@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Any feedback on the updated PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32236>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:29:45 2018
From: report at bugs.python.org (Reuben Thomas)
Date: Thu, 25 Jan 2018 13:29:45 +0000
Subject: [issue32666] Valgrind documentation seems to need updating
Message-ID: <1516886985.24.0.467229070634.issue32666@psf.upfronthosting.co.za>


New submission from Reuben Thomas <rrt at sc3d.org>:

I have just been trying to use Valgrind (in my case, to debug code in a library being tested via a Cython module).

It is working fine, but there seem to be some discrepancies between the documentation in README.valgrind and valgrind-python.supp on the one hand, and the actual code on the other.

README.Valgrind says (current git master):

Second, you must do one of the following:

  * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
    then rebuild Python
  * Uncomment the lines in Misc/valgrind-python.supp that
    suppress the warnings for PyObject_Free and PyObject_Realloc

However, Objects/objmalloc.c no longer contain this symbol (though Python/dtoa.c does).

Further, in https://bugs.python.org/issue31494 I find the following comment:

Also, I don't think --with-pydebug works well with valgrind.

It's either:
   1) --with-pydebug
   2) CFLAGS="-O0 -g" --with-valgrind
   3) CFLAGS="-O0 -g" --without-pymalloc

Combining 2) and 3) probably does not hurt, but is not necessary.

It would be useful to have this information in README.valgrind.

Also, the provided suppressions do not currently work with a normal build of Python, at least with Python 2.7 (with the PyObject_{Free,Realloc} suppressions uncommented). There seem to be at least two problems:

1. Extra symbols from LTO. This can be fixed by adding "*" to PyObject_Realloc in all its suppressions.

2. After fixing that, I still get one more "Invalid read of size 4":

==3227== Invalid read of size 4
==3227==    at 0x4FCEE2: long_dealloc.lto_priv.323 (abstract.c:2000)
==3227==    by 0x4BA22B: frame_dealloc (frameobject.c:458)
==3227==    by 0x4BA22B: PyEval_EvalCodeEx (ceval.c:3593)
==3227==    by 0x4C16E6: fast_function (ceval.c:4445)
==3227==    by 0x4C16E6: call_function (ceval.c:4370)

I can't see how this is related to any existing suppression.

I am using the stock Python 2.7 on Ubuntu 16.04. I find that I can work around both the above problems (that is, use the suppressions file as-is, just uncommenting the extra suppressions for PyObject_{Free,Realloc}) by using Ubuntu's debug build of Python (installed as /usr/bin/python-dbg). It is built with --with-pydebug.

Finally, README.valgrind says: "Valgrind is used periodically by Python developers to try to ensure there are no memory leaks or invalid memory reads/writes." Another reason to use Valgrind is, as in my case, to debug unrelated C code that is being run via Python (this is often a convenient way to write tests). I suggest deleting this sentence and making it more obvious how to simply make Python "transparent to Valgrind" for those trying to debug C libraries.

To summarise:

i. It seems that for current Python 3, this text:

  * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
    then rebuild Python

needs to be updated.

ii. For Python 2.7 at least, and possibly Python 3, extra suppressions are needed to use a standard build.

iii. It would be good to have the specific build advice from https://bugs.python.org/issue31494 in README.valgrind.

iv. It would be nice to clarify how to use a normal build of Python (e.g. by splitting the advice into "For Python developers" and "For Python users").

Given some guidance on what is correct, and what is desired/acceptable, I'd be happy to work up a patch to README.valgrind and valgrind-python.supp.

----------
assignee: docs at python
components: Documentation
messages: 310673
nosy: docs at python, rrt
priority: normal
severity: normal
status: open
title: Valgrind documentation seems to need updating
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32666>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:33:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 13:33:18 +0000
Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary
 mode
In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za>
Message-ID: <1516887198.48.0.467229070634.issue32236@psf.upfronthosting.co.za>


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


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32236>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:35:07 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 25 Jan 2018 13:35:07 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1516887307.47.0.467229070634.issue10381@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
pull_requests: +5163
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:36:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 13:36:53 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516887413.06.0.467229070634.issue32654@psf.upfronthosting.co.za>


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


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:43:29 2018
From: report at bugs.python.org (Jan Vlcinsky)
Date: Thu, 25 Jan 2018 13:43:29 +0000
Subject: [issue32223] distutils doesn't correctly read UTF-8 content from
 config files
In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za>
Message-ID: <1516887809.92.0.467229070634.issue32223@psf.upfronthosting.co.za>


Jan Vlcinsky <jan.vlcinsky at tamtamresearch.com> added the comment:

The fix shall go to

https://github.com/python/cpython/blob/2812d3d99287c50bab99625d7240bcf1c2e32369/Lib/distutils/dist.py#L406

where `parser.read(filename)`

shall be changed to `parser.read(filename, encoding="utf-8")`

This assumes that the setup.cfg shall be UTF-8 encoded what I thing is correct assumption.

Alternative assumptions are (and I do not find them good):

- assume the file is encoded as current console is (this is not deterministic and is direct cause of this issue)
- let user to specify the encoding somewhere around (this requires extra step and does not bring any value)

----------
nosy: +vlcinsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32223>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:47:37 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 25 Jan 2018 13:47:37 +0000
Subject: [issue32256] Make patchcheck.py work for out-of-tree builds
In-Reply-To: <1512783358.62.0.213398074469.issue32256@psf.upfronthosting.co.za>
Message-ID: <1516888057.87.0.467229070634.issue32256@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Any objections to the PR?

----------
nosy: +belopolsky, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32256>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:58:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 13:58:40 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1516888720.8.0.467229070634.issue10381@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Ok, this time it should be fixed for real ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Thu Jan 25 09:09:02 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 25 Jan 2018 14:09:02 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1516889342.68.0.467229070634.issue10381@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
pull_requests: +5164

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Thu Jan 25 09:28:17 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jan 2018 14:28:17 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1516890497.9.0.467229070634.issue32657@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Chason: that does look like a bug.

Mutable defaults are best to avoid, but if they are used read-only and not passed down further it isn't a problem.  send_message was modeled on sendmail, and so copied it's use of defaults (which date from quite some time back :), but obviously I missed that mutation of the value in the code review of the patch that added those lines :(

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:05:59 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 25 Jan 2018 15:05:59 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1516892759.87.0.467229070634.issue32664@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:12:46 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 25 Jan 2018 15:12:46 +0000
Subject: [issue32667] Failing test_dtrace and test_subprocess on Ubuntu 16.04
 on master
Message-ID: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>


New submission from Jay Yin <jayyin11043 at gmail.com>:

Hello everyone,


I've been trying to build the master branch on Ubuntu 16.04 and it currently fails 2 test, I was wondering if this was normal or if I'm missing dependencies, I also tried apt-get build-dev python3.6 and python3.7 to no avail, the build requirements install worked for python3.5 but I suspect 3.7 has different dependencies but I can't find where the documentation for the requirements are. 
2 tests failed:
    test_dtrace test_subprocess


running test_dtrace as verbose gave https://pastebin.com/ZGzzxwjk
	
[Bash] FAILED (errors=4) test test_dtrace failed 1 test failed: test_dtrace R - Pastebin.com
pastebin.com


and running test_subprocess gives


https://pastebin.com/DNjPzpgp

----------
messages: 310678
nosy: jayyin11043
priority: normal
severity: normal
status: open
title: Failing test_dtrace and test_subprocess on Ubuntu 16.04 on master
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:18:01 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 25 Jan 2018 15:18:01 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516890497.9.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <20180125151753.GY22500@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Thu, Jan 25, 2018 at 02:28:17PM +0000, R. David Murray wrote:

> obviously I missed that mutation of the value 
> in the code review of the patch that added those lines :(

The docstring for send_message does say 

    If the sender or any of the recipient addresses contain non-ASCII
    and the server advertises the SMTPUTF8 capability, the policy is
    cloned with utf8 set to True for the serialization, and SMTPUTF8
    and BODY=8BITMIME are asserted on the send.

which I don't really understand, but I thought that perhaps it was a 
typo for *inserted* on the send, in the sense of inserted into the mail 
options:

    mail_options += ['SMTPUTF8', 'BODY=8BITMIME']

So are we agreed this is a bug? What about the default for rcpt_options 
being a dict?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:38:30 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 25 Jan 2018 15:38:30 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1516894710.33.0.467229070634.issue27505@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5165
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:40:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 15:40:15 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1516894815.38.0.467229070634.issue32645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Build 537 of x86 Tiger 3.x failed, whereas the previous build was a success. Hum, maybe these asyncio failures are "just" race conditions, trigger if the system load is too high? I recall that the Windows 7 buildbot is usually slow/busy.

http://buildbot.python.org/all/#/builders/30/builds/537

======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 436, in run_until_complete
    return future.result()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
======================================================================
ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_sslproto.py", line 285, in test_start_tls_server_1
    asyncio.wait_for(main(), loop=self.loop, timeout=10))
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 436, in run_until_complete
    return future.result()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:51:56 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 25 Jan 2018 15:51:56 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1516895516.58.0.467229070634.issue27505@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
pull_requests: +5166

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:52:52 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 25 Jan 2018 15:52:52 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1516895572.44.0.467229070634.issue27505@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Thanks Nick.  I've made the PRs for the versionadded and to add __class__ to the 3.6 docs.

----------
stage: patch review -> needs patch
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:53:44 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 25 Jan 2018 15:53:44 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1516895624.78.0.467229070634.issue27505@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Thu Jan 25 11:09:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 16:09:52 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516896592.99.0.467229070634.issue32654@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I wrote PR 5305 for Paul Peny who uses cheap devices (less than 50$, maybe less 20$? I'm not sure) for development, but these devices use old Android versions.

It seems like some people are exchanging patches, in private or in public, for Android API 19. My intent is to make patches upstream, especially small patches which fix compilation of Python on Android API 19.

I'm not sure that we should support API 19.

Xavier de Gaye wants to focus on the future, support API 24 and newer:
https://github.com/xdegaye/cagibi/blob/master/doc/android_support.rst

His document gives many good reasons to not support API < 24.

My intent is not to "fully support" Python on Android API 19. Just to make sure that we can compile Python and that python3 -c pass doesn't crash :-) So only merge the most critical fixes for API 19.

IMHO merging further changes to fix other Python functions should be discussed on a case by base basis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 11:10:29 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Thu, 25 Jan 2018 16:10:29 +0000
Subject: [issue32621] Problem of consistence in collection.abc documentation
In-Reply-To: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za>
Message-ID: <1516896629.62.0.467229070634.issue32621@psf.upfronthosting.co.za>


Yahya Abou Imran <yahya-abou-imran at protonmail.com> added the comment:

There is another one:

Reversible list __reversed__ in the abstract method but inherits __iter__ from Iterable.

So there is definitely an inconsistency...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32621>
_______________________________________

From report at bugs.python.org  Thu Jan 25 11:15:24 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Thu, 25 Jan 2018 16:15:24 +0000
Subject: [issue32471] Add an UML class diagram to the collections.abc module
 documentation
In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>
Message-ID: <1516896923.99.0.467229070634.issue32471@psf.upfronthosting.co.za>


Yahya Abou Imran <yahya-abou-imran at protonmail.com> added the comment:

I succeed in submitting a PR and building the doc locally.

But there is a little problem of consistency with the abstract methods:
in some classes, the inherited one are mentioned (Collection, Sequence, Mapping), but not in some others (Coroutine, Reversible).

So I don't not what to show and what to hide.

I opened an other issue for this:
https://bugs.python.org/issue32621

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Thu Jan 25 11:36:08 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Thu, 25 Jan 2018 16:36:08 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516898168.86.0.467229070634.issue32654@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Here's another argument for supporting android < 21: according to Google [1], 12.8% devices on the world run android-19. Furthermore, upgrading Android OS for a device is almost impossible for non-hackers unless the manufacturer provides an image for newer Android, and it's common for manufacturers not upgrading a phone soon after its debut.

----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 11:37:37 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 25 Jan 2018 16:37:37 +0000
Subject: [issue32667] Failing test_dtrace and test_subprocess on Ubuntu 16.04
 on master
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516898257.49.0.467229070634.issue32667@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +lukasz.langa, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 11:39:40 2018
From: report at bugs.python.org (Martin Kolman)
Date: Thu, 25 Jan 2018 16:39:40 +0000
Subject: [issue32668] deepcopy() fails on ArgumentParser instances
Message-ID: <1516898380.94.0.467229070634.issue32668@psf.upfronthosting.co.za>


New submission from Martin Kolman <mkolman at redhat.com>:

We (the Anaconda OS intaller team) are in the process of switching to a new version of a library (Pykickstart), which among other things switched from using optparse to argparse. And during this endeavour we found that it's apparently not possible to deepcopy ArgumentParser instances:


$ ipython3
Python 3.6.3 (default, Oct  9 2017, 12:07:10) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import argparse

In [2]: from copy import deepcopy

In [3]: parser = argparse.ArgumentParser()

In [4]: deepcopy(parser)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-53dc517e3ecc> in <module>()
----> 1 deepcopy(parser)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    178                     y = x
    179                 else:
--> 180                     y = _reconstruct(x, memo, *rv)
    181 
    182     # If is its own copy, don't memoize.

/usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy)
    278     if state is not None:
    279         if deep:
--> 280             state = deepcopy(state, memo)
    281         if hasattr(y, '__setstate__'):
    282             y.__setstate__(state)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy)
    238     memo[id(x)] = y
    239     for key, value in x.items():
--> 240         y[deepcopy(key, memo)] = deepcopy(value, memo)
    241     return y
    242 d[dict] = _deepcopy_dict

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_list(x, memo, deepcopy)
    213     append = y.append
    214     for a in x:
--> 215         append(deepcopy(a, memo))
    216     return y
    217 d[list] = _deepcopy_list

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    178                     y = x
    179                 else:
--> 180                     y = _reconstruct(x, memo, *rv)
    181 
    182     # If is its own copy, don't memoize.

/usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy)
    278     if state is not None:
    279         if deep:
--> 280             state = deepcopy(state, memo)
    281         if hasattr(y, '__setstate__'):
    282             y.__setstate__(state)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy)
    238     memo[id(x)] = y
    239     for key, value in x.items():
--> 240         y[deepcopy(key, memo)] = deepcopy(value, memo)
    241     return y
    242 d[dict] = _deepcopy_dict

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    178                     y = x
    179                 else:
--> 180                     y = _reconstruct(x, memo, *rv)
    181 
    182     # If is its own copy, don't memoize.

/usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy)
    278     if state is not None:
    279         if deep:
--> 280             state = deepcopy(state, memo)
    281         if hasattr(y, '__setstate__'):
    282             y.__setstate__(state)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy)
    238     memo[id(x)] = y
    239     for key, value in x.items():
--> 240         y[deepcopy(key, memo)] = deepcopy(value, memo)
    241     return y
    242 d[dict] = _deepcopy_dict

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    159             copier = getattr(x, "__deepcopy__", None)
    160             if copier:
--> 161                 y = copier(memo)
    162             else:
    163                 reductor = dispatch_table.get(cls)

TypeError: cannot deepcopy this pattern object


This should either be fixed or documented in proper places (the argparse documentation does not mention any pottential deepcopy issues as far as we can tell).

----------
components: Library (Lib)
messages: 310686
nosy: mkolman
priority: normal
severity: normal
status: open
title: deepcopy() fails on ArgumentParser instances
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32668>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:05:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 25 Jan 2018 17:05:51 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516899951.54.0.467229070634.issue32654@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I don't think we should be adding this platform-version-specific code unless we are going to fully support that particular platform and version.  That means at a minimum adding a buildbot for it and then having a core developer signed up to maintain the platform version.  It's not fair to other code developers and to downstream users to falsely imply that we support something that we are not set up to support, especially an already out-of-date version when we don't yet support any version of Android.  We will end up with another support headache as has been the case with other non-mainstream (with regard to Python) platforms.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:17:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 17:17:10 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1516900630.01.0.467229070634.issue10381@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh, PR 5317 title mentionned this bpo number, but the merged change omits the bpo number and so wasn't mentioned on this issue.

PR 5317 added:

commit 58dc03c737a71de93edef7723c9f6186116288ef (upstream/master, master)
Author: Paul Ganssle <pganssle at users.noreply.github.com>
Date:   Thu Jan 25 08:58:07 2018 -0500

    Cleanup dangling reference in get_timezone_utc_capi (#5317)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:22:30 2018
From: report at bugs.python.org (pmpp)
Date: Thu, 25 Jan 2018 17:22:30 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516900950.37.0.467229070634.issue32654@psf.upfronthosting.co.za>


pmpp <pmpp.pub at gmail.com> added the comment:

Thanks ! I tested your PR it just built out of the box with the help of a one line change to Xavier de Gaye's android build support tool ( configure-android script + Android folder from bpo-30386 ). 

I'll forward to you the result of testsuite on a $10 Arm cortex-a7 board running Android kitkat 4.4.2 ( H3droid ) as soon as it finishes as i run a testbot on it.

My point of view is that "out of date" doesn't mean people don't actually *use* it : vstinner is indeed right , vendors provides almost no updates for hardware which actually can live long and have the power of some low power i*&a* cpu but without the actual drawbacks we heard about recently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:26:23 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 25 Jan 2018 17:26:23 +0000
Subject: [issue32640] Python 2.7 str.join documentation is incorrect
In-Reply-To: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>
Message-ID: <1516901183.24.0.467229070634.issue32640@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Oops.
Thanks, I will work on reverting the change later today.

----------
assignee: docs at python -> Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:28:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 17:28:51 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516901331.31.0.467229070634.issue32667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I discussed with Jay Yin on IRC and we understood the issue on his setup: the last entry of his PATH environment variable is a path to an existing *file*, not a directory.

In this case, subprocess.Popen() fails with ENOTDIR if the program cannot be found in any other directory of the PATH.

Copy of _posixmodule.c:
---
    /* This loop matches the Lib/os.py _execvpe()'s PATH search when */
    /* given the executable_list generated by Lib/subprocess.py.     */
    saved_errno = 0;
    for (i = 0; exec_array[i] != NULL; ++i) {
        const char *executable = exec_array[i];
        if (envp) {
            execve(executable, argv, envp);
        } else {
            execv(executable, argv);
        }
        if (errno != ENOENT && errno != ENOTDIR && saved_errno == 0) {
            saved_errno = errno;
        }
    }
    /* Report the first exec error, not the last. */
    if (saved_errno)
        errno = saved_errno;
---

If the first execv() calls with ENOENT and the last one fails with ENOTDIR, the function fails with ENOTDIR.

----------
nosy: +vstinner
title: Failing test_dtrace and test_subprocess on Ubuntu 16.04 on master -> test_subprocess and test_dtrace fails if the last entry of $PATH is a file

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:29:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 17:29:43 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516901383.14.0.467229070634.issue32667@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5167
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:32:08 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Thu, 25 Jan 2018 17:32:08 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516901528.14.0.467229070634.issue32654@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Agree with Ned Deily here. If CPython is going to be support android-19, it's better to fully support it. I'm optimistic here - I believe there won't be many android-19-specific patches beyond locale-related ones. Once android-24 is done, we can revisit this part and see how many patches are needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 12:32:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 17:32:17 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516901537.59.0.467229070634.issue32667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Attached PR 5322 fixes the issue.

Example to reproduce the bug:

$ touch file
$ PATH=$PATH:$PWD/file ./python -m test test_subprocess -m test_invalid_args -v
(...)
======================================================================
ERROR: test_invalid_args (test.test_subprocess.ContextManagerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_subprocess.py", line 3050, in test_invalid_args
    stderr=subprocess.PIPE) as proc:
  File "/home/vstinner/prog/python/master/Lib/subprocess.py", line 743, in __init__
    restore_signals, start_new_session)
  File "/home/vstinner/prog/python/master/Lib/subprocess.py", line 1431, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
NotADirectoryError: [Errno 20] Not a directory: 'nonexisting_i_hope'
(...)


With PR 5322 applied, the whole Python test suite pass with PATH=$PATH:$PWD/file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:01:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 18:01:32 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516903292.37.0.467229070634.issue32654@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Ned Deily: "I don't think we should be adding this platform-version-specific code unless we are going to fully support that particular platform and version."

I know the theory and I know the practice :-)

I started to list platforms that are "supported" by Python, with various support levels:
http://vstinner.readthedocs.io/cpython.html#supported-platforms

For example, Linux has an excellent support, whereas OpenBSD is more on the "best effort" side. "grep OpenBSD" in CPython shows me at least 51 lines of code, whereas OpenBSD has no buildbot and no dedicated developer to handle OpenBSD specific issues. For example, test_crypt is broken since at least 2 years on OpenBSD, as many test_socket tests.

For OpenBSD, IMHO it's ok to have a best effort support, basically apply proposed patches.

For Android, the situation is somehow different. There are more and more people working on supporting officially Python on Android, like Xavier de Gaye and me who are core developers. Xavier is working on that for 2 years, and IMHO the port is done at 95%. The last part is just to setup a buildbot for Android API 24.

The question is the added maintenance cost of Android API 19 #ifdef code, compared to pain of building Python on Android.

Technically, it should be possible to setup a buildbot for Android API 19, but only with a subset of tests. Either explicitly only run a subset of tests on this hypothetic buildbot, or even modify the Python test suite to skip some tests on Android API 19. While I expect a few patches for fix Python compilation on Android API 19, I do expect a lot of @skipIf() in tests, since API 19 has many broken or missing features. The thing is that most people don't care of these missing or broken features, it's not an issue for most applications on Android.

Note: Kivy is using Python on Android for years, but they use CrystaX NDK and not Google NDK. This issue is about supporting Google NDK: have the maximum compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:04:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 18:04:20 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516903460.19.0.467229070634.issue32654@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Another example of platform with best effort support is AIX. Until very recently, ctypes.util.find_library() didn't work on AIX which causes many tests failure. The AIX buildbot is red as far as I can remember. *Many* tests are failing on AIX for various reasons. While a few people sometimes propose fixes, basically the AIX support didn't evolved much last years in AIX...

AIX is a platform with a buildbot, but no real dedicated developer to fix all AIX specific issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:06:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 18:06:07 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516903567.56.0.467229070634.issue32667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset b31206a223955d614d7769f95fb979d60f77bf87 by Victor Stinner in branch 'master':
bpo-32667: Fix tests when $PATH contains a file (#5322)
https://github.com/python/cpython/commit/b31206a223955d614d7769f95fb979d60f77bf87


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:06:59 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Jan 2018 18:06:59 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516903619.13.0.467229070634.issue32667@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5168

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:12:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 18:12:28 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1516903948.65.0.467229070634.issue32654@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

By the way, I started to take notes on Python on Android, since the topic is wide and complex:
http://vstinner.readthedocs.io/python_android.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:14:08 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 25 Jan 2018 18:14:08 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516904048.57.0.467229070634.issue32630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I realize that you had to fight massive mailing list distractions
during the PEP discussions, but this is very close to the beta ...


Let's start here:

>>> from decimal import *
==18887== Invalid read of size 8
==18887==    at 0x5324E0: contextvar_new (context.c:744)
==18887==    by 0x53141A: PyContextVar_New (context.c:137)
==18887==    by 0xFED052B: PyInit__decimal (_decimal.c:5542)
==18887==    by 0x51FC56: _PyImport_LoadDynamicModuleWithSpec (importdl.c:159)
==18887==    by 0x51F29F: _imp_create_dynamic_impl (import.c:2145)
==18887==    by 0x51A4BA: _imp_create_dynamic (import.c.h:289)
==18887==    by 0x43257A: _PyMethodDef_RawFastCallDict (call.c:530)
==18887==    by 0x432710: _PyCFunction_FastCallDict (call.c:582)
==18887==    by 0x432DD6: PyCFunction_Call (call.c:787)
==18887==    by 0x4FAA44: do_call_core (ceval.c:4659)
==18887==    by 0x4F58CC: _PyEval_EvalFrameDefault (ceval.c:3232)
==18887==    by 0x4E7F99: PyEval_EvalFrameEx (ceval.c:545)
==18887==  Address 0xcf589a8 is 8 bytes before a block of size 64 alloc'd
==18887==    at 0x4C2A9A1: malloc (vg_replace_malloc.c:299)
==18887==    by 0x470498: _PyMem_RawMalloc (obmalloc.c:75)
==18887==    by 0x470FFC: PyMem_RawMalloc (obmalloc.c:503)
==18887==    by 0x471DEF: _PyObject_Malloc (obmalloc.c:1560)
==18887==    by 0x471312: PyObject_Malloc (obmalloc.c:616)
==18887==    by 0x4A35D6: PyUnicode_New (unicodeobject.c:1293)
==18887==    by 0x4CA16B: _PyUnicodeWriter_PrepareInternal (unicodeobject.c:13423)
==18887==    by 0x4B1843: PyUnicode_DecodeUTF8Stateful (unicodeobject.c:4806)
==18887==    by 0x4A5E67: PyUnicode_FromString (unicodeobject.c:2105)
==18887==    by 0x5313F5: PyContextVar_New (context.c:133)
==18887==    by 0xFED052B: PyInit__decimal (_decimal.c:5542)
==18887==    by 0x51FC56: _PyImport_LoadDynamicModuleWithSpec (importdl.c:159)
==18887==

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:18:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 18:18:26 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516904306.08.0.467229070634.issue32667@psf.upfronthosting.co.za>


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


----------
pull_requests: +5169

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:21:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 18:21:44 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516904504.06.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I realize that you had to fight massive mailing list distractions
> during the PEP discussions, but this is very close to the beta ...

Oh thanks, but I see no reason for you to be condescending here.

I cannot reproduce this on Mac OS / Linux.  Are you sure you've built your Python correctly?  Can you run 'make distclean; ./configure --with-pydebug; make -j4'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:24:58 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 25 Jan 2018 18:24:58 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1516904698.56.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5170

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:39:22 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 18:39:22 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516905562.42.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
pull_requests: +5171

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:42:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 18:42:57 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516905777.63.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

(Just in case I rebased my patch onto the latest master)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:47:40 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Jan 2018 18:47:40 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1516906060.21.0.467229070634.issue29708@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Jan 25 13:54:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 18:54:41 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516906481.45.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I think I found what cause this, but I have no idea why it has surfaced only now :)

https://github.com/python/cpython/pull/5326/files
(see the added PyType_IS_GC(Py_TYPE(name)) check)

I'll merge that PR and rebase the decimal patch again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:03:08 2018
From: report at bugs.python.org (steven Michalske)
Date: Thu, 25 Jan 2018 19:03:08 +0000
Subject: [issue32669] cgitb file to print OSError exceptions
Message-ID: <1516906988.26.0.467229070634.issue32669@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

With the source

```
import cgitb
import sys

try:
    f = open('non_exitant_file_path.foo')
except Exception as e:
    cgitb.text(sys.exc_info())
```

we get the output

```
Traceback (most recent call last):
  File "foo.py", line 22, in <module>
    f = open('non_exitant_file_path.foo')
FileNotFoundError: [Errno 2] No such file or directory: 'non_exitant_file_path.foo'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "foo.py", line 24, in <module>
    cgitb.text(sys.exc_info())
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/cgitb.py", line 245, in text
    value = pydoc.text.repr(getattr(evalue, name))
AttributeError: characters_written
```

In bug #30554 it was brought up that there are attributes designed as invariant os some other as designed behavior.  Unfortunately it was closed "as designed" 

So this means that cgitb has a bug when text formatting a sys_exc traceback of an OSError.

This is hidden in the by the hook with this code form cgitb.py
by falling back to the standard formatter...

line 277
```
        try:
            doc = formatter(info, self.context)
        except:                         # just in case something goes wrong
            doc = ''.join(traceback.format_exception(*info))
            plain = True
```

----------
messages: 310702
nosy: hardkrash
priority: normal
severity: normal
status: open
title: cgitb file to print OSError exceptions
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32669>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:18:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 19:18:57 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1516907937.44.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 6ab62920c87930dedc31fe633ecda3e51d3d7503 by Yury Selivanov in branch 'master':
bpo-32436: Fix a refleak; var GC tracking; a GCC warning (#5326)
https://github.com/python/cpython/commit/6ab62920c87930dedc31fe633ecda3e51d3d7503


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:20:12 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 19:20:12 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516908012.21.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I pushed a fix (already in the master branch) and rebased the patch once again.  I expect it to work now :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:49:49 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 25 Jan 2018 19:49:49 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516909789.73.0.467229070634.issue32667@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:50:06 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 25 Jan 2018 19:50:06 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516909806.49.0.467229070634.issue32667@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:50:14 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 25 Jan 2018 19:50:14 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516909814.88.0.467229070634.issue32667@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:52:37 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 25 Jan 2018 19:52:37 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516909957.98.0.467229070634.issue32667@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 15:11:28 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 25 Jan 2018 20:11:28 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516911088.33.0.467229070634.issue32630@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 15:51:26 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 20:51:26 +0000
Subject: [issue29302] add contextlib.AsyncExitStack
In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za>
Message-ID: <1516913486.43.0.467229070634.issue29302@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 1aa094f74039cd20fdc7df56c68f6848c18ce4dd by Yury Selivanov (Ilya Kulakov) in branch 'master':
bpo-29302: Implement contextlib.AsyncExitStack. (#4790)
https://github.com/python/cpython/commit/1aa094f74039cd20fdc7df56c68f6848c18ce4dd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29302>
_______________________________________

From report at bugs.python.org  Thu Jan 25 15:52:36 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 20:52:36 +0000
Subject: [issue29302] add contextlib.AsyncExitStack
In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za>
Message-ID: <1516913556.02.0.467229070634.issue29302@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thank you Alexander and Ilya!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29302>
_______________________________________

From report at bugs.python.org  Thu Jan 25 16:05:40 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jan 2018 21:05:40 +0000
Subject: [issue32669] cgitb file to print OSError exceptions
In-Reply-To: <1516906988.26.0.467229070634.issue32669@psf.upfronthosting.co.za>
Message-ID: <1516914340.45.0.467229070634.issue32669@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yep, this one might get closed as "as designed", too ;)  cgitb has to cope with something going wrong with trying to print out values, because there are a number of ways to break that in Python, not just the one you are pointing to.

If you have a thought about how to move the exception handling deeper into the module in a generalized way, we could consider that option.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32669>
_______________________________________

From report at bugs.python.org  Thu Jan 25 16:39:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 21:39:43 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516916383.98.0.467229070634.issue32667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 255dbd2102d5dec5ffbd0b94084377e98c3b56c4 by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-32667: Fix tests when $PATH contains a file (GH-5322) (#5323)
https://github.com/python/cpython/commit/255dbd2102d5dec5ffbd0b94084377e98c3b56c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 16:41:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 21:41:40 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516916500.96.0.467229070634.issue32667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 6996f284d4d90aa05c46d9fe6f38d1030454b224 by Victor Stinner in branch '2.7':
bpo-32667: Fix tests when $PATH contains a file (#5324)
https://github.com/python/cpython/commit/6996f284d4d90aa05c46d9fe6f38d1030454b224


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 16:42:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 21:42:20 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516916540.91.0.467229070634.issue32667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Thank you Jay Yin for your bug report. I fixed the bug in Python 2.7, 3.6 and master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 16:43:15 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 25 Jan 2018 21:43:15 +0000
Subject: [issue32667] test_subprocess and test_dtrace fails if the last entry
 of $PATH is a file
In-Reply-To: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>
Message-ID: <1516916595.42.0.467229070634.issue32667@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

no problem, thanks for helping and fixing the issue, I can now help contribute to python =D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 16:50:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 21:50:49 +0000
Subject: =?utf-8?q?=5Bissue32670=5D_Enforce_PEP_479=E2=80=94StopIteration_and_gene?=
 =?utf-8?q?rators=E2=80=94in_Python_3=2E7_by_default?=
Message-ID: <1516917049.09.0.467229070634.issue32670@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

As per PEP 479, in Python 3.7 it should be a RuntimeError when a StopIteration exception is raised manually in a generator, a coroutine, or an async generator.

----------
assignee: yselivanov
components: Interpreter Core
messages: 310712
nosy: gvanrossum, ncoghlan, ned.deily, yselivanov
priority: release blocker
severity: normal
status: open
title: Enforce PEP 479?StopIteration and generators?in Python 3.7 by default
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32670>
_______________________________________

From report at bugs.python.org  Thu Jan 25 17:04:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 22:04:38 +0000
Subject: =?utf-8?q?=5Bissue32670=5D_Enforce_PEP_479=E2=80=94StopIteration_and_gene?=
 =?utf-8?q?rators=E2=80=94in_Python_3=2E7_by_default?=
In-Reply-To: <1516917049.09.0.467229070634.issue32670@psf.upfronthosting.co.za>
Message-ID: <1516917878.02.0.467229070634.issue32670@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5172
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32670>
_______________________________________

From report at bugs.python.org  Thu Jan 25 17:05:01 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jan 2018 22:05:01 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <20180125151753.GY22500@ando.pearwood.info>
Message-ID: <20180125220457.839DC1B10002@webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

On Thu, 25 Jan 2018 15:18:01 +0000, Steven D'Aprano <report at bugs.python.org> wrote:
> On Thu, Jan 25, 2018 at 02:28:17PM +0000, R. David Murray wrote:
> The docstring for send_message does say 
> 
>     If the sender or any of the recipient addresses contain non-ASCII
>     and the server advertises the SMTPUTF8 capability, the policy is
>     cloned with utf8 set to True for the serialization, and SMTPUTF8
>     and BODY=8BITMIME are asserted on the send.

"Asserted" means sent with the SMTP commands.  It could be reworded to
be clearer.

> which I don't really understand, but I thought that perhaps it was a 
> typo for *inserted* on the send, in the sense of inserted into the mail 
> options:
> 
>     mail_options += ['SMTPUTF8', 'BODY=8BITMIME']

Even if that had been true, it would still be a bug to do it to the
mutable argument :)

> So are we agreed this is a bug? What about the default for rcpt_options 
> being a dict?

I didn't look at that, but it probably is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 17:34:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 22:34:05 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516919645.41.0.467229070634.issue32630@psf.upfronthosting.co.za>


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


----------
nosy: +ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 17:44:38 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 25 Jan 2018 22:44:38 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516920278.68.0.467229070634.issue32630@psf.upfronthosting.co.za>


Change by Stefan Krah <stefan at bytereef.org>:


----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 17:48:04 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 22:48:04 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516920484.57.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Stefan, I do think that this is a release blocker.  We want to get this change as early as possible to ensure that it's well tested.

AFAIK Guido also wants decimal to be updated and well supported in async/await code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 17:53:23 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 25 Jan 2018 22:53:23 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516920484.57.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <20180125225311.GA22914@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Sure, and *I* am the one running the extended decimal test suite as we speak,
not Guido.

You are playing power games here, and you did that from the start by choosing
the nosy list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:03:39 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 23:03:39 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516921419.39.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Sure, and *I* am the one running the extended decimal test suite as we speak, not Guido.

Thank you.

> You are playing power games here, and you did that from the start by choosing the nosy list.

Please.  I thought it was pretty much decided that we will update decimal if there is no significant performance degradation, so there's no need for a conspiracy.  I put Guido to the nosy-list not because I want to force something, but just because we've discussed decimal and PEP 567/550 with him numerous times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:05:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jan 2018 23:05:36 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516921536.81.0.467229070634.issue32630@psf.upfronthosting.co.za>


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


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:08:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 23:08:11 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516921691.71.0.467229070634.issue32662@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset c9070d03f5169ad6e171e641b7fa8feab18bf229 by Yury Selivanov in branch 'master':
bpo-32662: Implement Server.start_serving() and Server.serve_forever() (#5312)
https://github.com/python/cpython/commit/c9070d03f5169ad6e171e641b7fa8feab18bf229


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:08:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 23:08:25 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516921705.96.0.467229070634.issue32662@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:10:19 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 25 Jan 2018 23:10:19 +0000
Subject: [issue31698] Add REQ_NAME to the node.h API
In-Reply-To: <1507177705.75.0.213398074469.issue31698@psf.upfronthosting.co.za>
Message-ID: <1516921819.14.0.467229070634.issue31698@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31698>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:45:51 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 23:45:51 +0000
Subject: [issue32574] asyncio.Queue, put() leaks memory if the queue is full
In-Reply-To: <1516132419.05.0.467229070634.issue32574@psf.upfronthosting.co.za>
Message-ID: <1516923951.56.0.467229070634.issue32574@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset c47dacb69054f6fe1c2465df585985430f7fe366 by Yury Selivanov (Jos? Melero Fern?ndez) in branch 'master':
bpo-32574: Fix leaks in asyncio.Queue.put() and .get() (#5208)
https://github.com/python/cpython/commit/c47dacb69054f6fe1c2465df585985430f7fe366


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32574>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:46:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 23:46:23 +0000
Subject: [issue32574] asyncio.Queue, put() leaks memory if the queue is full
In-Reply-To: <1516132419.05.0.467229070634.issue32574@psf.upfronthosting.co.za>
Message-ID: <1516923983.61.0.467229070634.issue32574@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32574>
_______________________________________

From report at bugs.python.org  Thu Jan 25 18:58:39 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Jan 2018 23:58:39 +0000
Subject: [issue32660] Solaris should support constants like termios' FIONREAD
In-Reply-To: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>
Message-ID: <1516924719.1.0.467229070634.issue32660@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Solaris has two personalities: System V and BSD. This is not usually an issue but sometimes some constants have a different value in a mode or the other.

By default, when including <sys/ioctl.h> Solaris is in System V mode. We can force BSD mode defining symbol "BSD_COMP". This greatly expand the names available but, unfortunately, some values change.

The comment in <sys/ioctl.h> is quite clear:

"""
 *      There are some inherent problems in having a single file
 *      ioctl.h, with both System V and BSD flags. Introducing
 *      BSD flags into this file creates compilation problems
 *      with flags such as ECHO, NL1 etc., if termio.h and ioctl.h
 *      are included by the same file. Since these two files can
 *      be only included by System V applications, /usr/inclule/sys/ioctl.h
 *      will be System V mode and all the BSD flags will be turned off
 *      using #ifdef BSD_COMP. This file will also exist in
 *      /usr/ucbinclude/sys/ioctl.h for BSD applications but without the
 *      BSD flags turned off. System V appliactions can use ioctl.h without
 *      any changes, System V applications requiring BSD flags should
 *      -D BSD_COMP when compiling (and be warned about the common
 *      flags between System V and BSD) and BSD applications should
 *      use /usr/ucbinclude/sys/ioctl.h.
"""

Using "gcc -dM -E" we can observe defined symbols.

Ambiguous values when defininf "BSD_COMP" are: BS0, BS1, CR0, CR1, CR2, CR3, ECHO, FF0, FF1, FLUSHO, NL0, NL1, NOFLSH, PENDIN, TAB0, TAB1, TAB2, TOSTOP, XTABS.

Sounds quite important, actually.

Since I am no aiming to perfection, I would be satisfied making quite a few new symbols available, not all of them. A simple approach would be to include <sys/filio.h> and <sys/sockio.h>. In those header files there are only constants, not functions or data structures.

Just including those headers we get these new symbols (none overlapping other):

_FIO_COMPRESSED
_FIO_COUNT_FILLED
_FIO_GET_TOP_STATS
_FIO_SEEK_DATA
_FIO_SEEK_HOLE
_FIO_SET_LUFS_DEBUG
_FIO_SET_LUFS_ERROR
_FIOAI
_FIODIRECTIO
_FIOFFS
_FIOGDIO
_FIOGETMAXPHYS
_FIOGETSUPERBLOCK
_FIOIO
_FIOISBUSY
_FIOISLOG
_FIOISLOGOK
_FIOLFS
_FIOLFSS
_FIOLOGDISABLE
_FIOLOGENABLE
_FIOLOGRESET
_FIOOBSOLETE67
_FIOSATIME
_FIOSDIO
_FIOSNAPSHOTCREATE
_FIOSNAPSHOTCREATE_MULTI
_FIOSNAPSHOTDELETE
_FIOTUNE
_IO(x,y)
_IOR(x,y,t)
_IORN(x,y,t)
_IOW(x,y,t)
_IOWN(x,y,t)
_IOWR(x,y,t)
_IOWRN(x,y,t)
_SIOCSOCKFALLBACK
_SYS_FILIO_H
_SYS_IOCCOM_H
_SYS_SOCKIO_H
FIOASYNC
FIOCLEX
FIOGETOWN
FIONBIO
FIONCLEX
FIONREAD
FIOSETOWN
IF_UNITSEL
IOC_IN
IOC_INOUT
IOC_OUT
IOC_VOID
IOCPARM_MASK
O_SIOCGIFCONF
O_SIOCGLIFCONF
SIOCADDMULTI
SIOCADDRT
SIOCATMARK
SIOCDARP
SIOCDELMULTI
SIOCDELRT
SIOCDXARP
SIOCGARP
SIOCGDSTINFO
SIOCGENADDR
SIOCGENPSTATS
SIOCGETLSGCNT
SIOCGETNAME
SIOCGETPEER
SIOCGETPROP
SIOCGETSGCNT
SIOCGETSYNC
SIOCGETVIFCNT
SIOCGHIWAT
SIOCGIFADDR
SIOCGIFBRDADDR
SIOCGIFCONF
SIOCGIFDSTADDR
SIOCGIFFLAGS
SIOCGIFHWADDR
SIOCGIFINDEX
SIOCGIFMEM
SIOCGIFMETRIC
SIOCGIFMTU
SIOCGIFMUXID
SIOCGIFNETMASK
SIOCGIFNUM
SIOCGIP6ADDRPOLICY
SIOCGIPMSFILTER
SIOCGLIFADDR
SIOCGLIFBINDING
SIOCGLIFBRDADDR
SIOCGLIFCONF
SIOCGLIFDADSTATE
SIOCGLIFDSTADDR
SIOCGLIFFLAGS
SIOCGLIFGROUPINFO
SIOCGLIFGROUPNAME
SIOCGLIFHWADDR
SIOCGLIFINDEX
SIOCGLIFLNKINFO
SIOCGLIFMETRIC
SIOCGLIFMTU
SIOCGLIFMUXID
SIOCGLIFNETMASK
SIOCGLIFNUM
SIOCGLIFSRCOF
SIOCGLIFSUBNET
SIOCGLIFTOKEN
SIOCGLIFUSESRC
SIOCGLIFZONE
SIOCGLOWAT
SIOCGMSFILTER
SIOCGPGRP
SIOCGSTAMP
SIOCGXARP
SIOCIFDETACH
SIOCILB
SIOCLIFADDIF
SIOCLIFDELND
SIOCLIFGETND
SIOCLIFREMOVEIF
SIOCLIFSETND
SIOCLOWER
SIOCSARP
SIOCSCTPGOPT
SIOCSCTPPEELOFF
SIOCSCTPSOPT
SIOCSENABLESDP
SIOCSETPROP
SIOCSETSYNC
SIOCSHIWAT
SIOCSIFADDR
SIOCSIFBRDADDR
SIOCSIFDSTADDR
SIOCSIFFLAGS
SIOCSIFINDEX
SIOCSIFMEM
SIOCSIFMETRIC
SIOCSIFMTU
SIOCSIFMUXID
SIOCSIFNAME
SIOCSIFNETMASK
SIOCSIP6ADDRPOLICY
SIOCSIPMSFILTER
SIOCSLGETREQ
SIOCSLIFADDR
SIOCSLIFBRDADDR
SIOCSLIFDSTADDR
SIOCSLIFFLAGS
SIOCSLIFGROUPNAME
SIOCSLIFINDEX
SIOCSLIFLNKINFO
SIOCSLIFMETRIC
SIOCSLIFMTU
SIOCSLIFMUXID
SIOCSLIFNAME
SIOCSLIFNETMASK
SIOCSLIFPREFIX
SIOCSLIFSUBNET
SIOCSLIFTOKEN
SIOCSLIFUSESRC
SIOCSLIFZONE
SIOCSLOWAT
SIOCSLSTAT
SIOCSMSFILTER
SIOCSPGRP
SIOCSPROMISC
SIOCSQPTR
SIOCSSDSTATS
SIOCSSESTATS
SIOCSXARP
SIOCTMYADDR
SIOCTMYSITE
SIOCTONLINK
SIOCUPPER
SIOCX25RCV
SIOCX25TBL
SIOCX25XMT
SIOCXPROTO

Not all those symbols are going to be exported in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32660>
_______________________________________

From report at bugs.python.org  Thu Jan 25 19:02:05 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Jan 2018 00:02:05 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1516924925.63.0.467229070634.issue32304@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset 2fc98ae115e2a2095a0bcf388c27a878aafdb454 by ?ric Araujo (Bo Bayles) in branch 'master':
bpo-32304: Fix distutils upload for sdists ending with \x0d (GH-5264)
https://github.com/python/cpython/commit/2fc98ae115e2a2095a0bcf388c27a878aafdb454


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Thu Jan 25 19:05:50 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 26 Jan 2018 00:05:50 +0000
Subject: [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1516925150.27.0.467229070634.issue11023@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Moved to the PEP issue tracker.
https://github.com/python/peps/issues/557

----------
nosy: +csabella
resolution:  -> later
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Thu Jan 25 19:16:47 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 26 Jan 2018 00:16:47 +0000
Subject: [issue32660] Solaris should support constants like termios' FIONREAD
In-Reply-To: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>
Message-ID: <1516925807.27.0.467229070634.issue32660@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

After doing this change, I see FIVE new symbols in Python's termios:

"""
FIONREAD, FIONCLEX, FIOCLEX, FIOASYNC, FIONBIO.
"""

Good enough for now and me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32660>
_______________________________________

From report at bugs.python.org  Thu Jan 25 19:38:31 2018
From: report at bugs.python.org (Bert JW Regeer)
Date: Fri, 26 Jan 2018 00:38:31 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
 mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1516927111.22.0.467229070634.issue4963@psf.upfronthosting.co.za>


Change by Bert JW Regeer <bertjw at regeer.org>:


----------
nosy: +X-Istence

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Thu Jan 25 19:40:47 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 26 Jan 2018 00:40:47 +0000
Subject: [issue32660] Solaris should support constants like termios' FIONREAD
In-Reply-To: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>
Message-ID: <1516927247.28.0.467229070634.issue32660@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

With this change, a SmarOS native zone exports 206 symbols in Python termios. Before it export 201. By comparison, a Linux Ubuntu 16.04 Python provides 244 symbols.

Some references for the future:

http://www.verycomputer.com/168_45f4bd8c333a252f_1.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32660>
_______________________________________

From report at bugs.python.org  Thu Jan 25 19:47:48 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 26 Jan 2018 00:47:48 +0000
Subject: [issue32660] Solaris should support constants like termios' FIONREAD
In-Reply-To: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>
Message-ID: <1516927668.76.0.467229070634.issue32660@psf.upfronthosting.co.za>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
keywords: +patch
pull_requests: +5173
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32660>
_______________________________________

From report at bugs.python.org  Thu Jan 25 20:17:25 2018
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 26 Jan 2018 01:17:25 +0000
Subject: [issue32671] redesign Windows  os.getlogin, and add os.getuser
Message-ID: <1516929444.23.0.467229070634.issue32671@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

os.getlogin() is supposed to return the name of the user logged in on the "controlling terminal" of the process. Windows doesn't have POSIX terminals; however, every process does belong to a terminal/desktop session that can be connected either to the physical console or a remote desktop. A standard user can call WTSQuerySessionInformation (an RPC to the Local Session Manager) to get the user name (i.e. WTSUserName) for the current session. ISTM that this is the closest analog to POSIX getlogin() that exists in Windows.

A caveat is that session 0 ("services") is never connected to the physical console. Thus there's no associated user account name.

os.getlogin() currently calls GetUserName (an RPC to the Local Security Authority), which returns the user name from the caller's effective token. If os.getlogin() is changed to return the session user, posixmodule.c could still wrap GetUserName privately as nt._getusername(). 

If the calling thread is impersonating, nt._getusername should temporarily revert to the process token (i.e. the real user), since this will usually be consistent with USERNAME. That said, getting the effective user can be useful for logging, so there should also be an option to return the effective user instead of the real user.

Note that the user name of the SYSTEM logon (and thus the USERNAME environment variable in a SYSTEM process) is actually "%COMPUTERNAME%$". It's noteworthy that GetUserName instead returns "SYSTEM" for this case. The "NETWORK SERVICE" logon also uses "%COMPUTERNAME%$", but in this case GetUserName returns "%COMPUTERNAME%$" instead of "NETWORK SERVICE".

A pair of high-level Python functions named getuser() and geteuser() could be added in os.py. These functions would return the real and effective user name of the caller, respectively. In Windows, os.getuser() would return the USERNAME environment variable and otherwise fall back on nt._getusername(). In POSIX, it would return the value of the first defined variable among LOGNAME, USER, and LNAME, and otherwise fall back on pwd.getpwuid(os.getuid()).pw_name. In Windows, os.geteuser() would return nt_getusername(effective=True). In POSIX it would return pwd.getpwuid(os.geteuid()).pw_name.

Currently getpass.getuser() always looks for environment variables named LOGNAME, USER, LNAME, and finally USERNAME. This is an odd choice on Windows. I wouldn't expect Windows users to know about and respect the special status of the first 3 variable names. getpass.getuser() also falls back on using the pwd module, which is another odd choice on Windows. It isn't worth removing or modifying this function, but the docs could encourage using the proposed os.getuser() and os.geteuser() functions on Windows and new code.

----------
components: Library (Lib), Windows
messages: 310724
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: redesign Windows  os.getlogin, and add os.getuser
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32671>
_______________________________________

From report at bugs.python.org  Thu Jan 25 20:51:02 2018
From: report at bugs.python.org (Jay Yin)
Date: Fri, 26 Jan 2018 01:51:02 +0000
Subject: [issue27931] Email parse IndexError <""@wiarcom.com>
In-Reply-To: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>
Message-ID: <1516931462.08.0.467229070634.issue27931@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


----------
pull_requests: +5174
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27931>
_______________________________________

From report at bugs.python.org  Thu Jan 25 20:53:35 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 01:53:35 +0000
Subject: [issue32596] Lazy import concurrent.futures.process and thread
In-Reply-To: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>
Message-ID: <1516931615.73.0.467229070634.issue32596@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 4666ec597c38eea06a22bcfb4157d92a0abf891c by INADA Naoki in branch 'master':
bpo-32596: Make lazy-load portable (GH-5316)
https://github.com/python/cpython/commit/4666ec597c38eea06a22bcfb4157d92a0abf891c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:01:36 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Fri, 26 Jan 2018 02:01:36 +0000
Subject: [issue31972] Inherited docstrings for pathlib classes are confusing
In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za>
Message-ID: <1516932096.01.0.467229070634.issue31972@psf.upfronthosting.co.za>


Change by Chason Chaffin <chason at gmail.com>:


----------
nosy: +chason

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31972>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:01:41 2018
From: report at bugs.python.org (bbayles)
Date: Fri, 26 Jan 2018 02:01:41 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1516932101.22.0.467229070634.issue32304@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
pull_requests: +5175

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:02:58 2018
From: report at bugs.python.org (bbayles)
Date: Fri, 26 Jan 2018 02:02:58 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1516932178.45.0.467229070634.issue32304@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
pull_requests: +5176

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:07:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 02:07:48 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516932468.97.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The following snippet crashes with SIGABRT:

    import asyncio
    async def f(): pass
    asyncio.gather(f())

llvm tells that the crash is in _PyGen_Finalize/_PyErr_WarnUnawaitedCoroutine

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:07:56 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 02:07:56 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516932476.17.0.467229070634.issue32591@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:27:01 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Fri, 26 Jan 2018 02:27:01 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1516933621.6.0.467229070634.issue32657@psf.upfronthosting.co.za>


Chason Chaffin <chason at gmail.com> added the comment:

I'm writing a PR for this right now. Is it worth it to write a test to make sure that mail_options isn't being mutated or is it enough just to update the code to use non-mutable defaults? Interesting side effect of looking into this is #32663 where I found the tests for the UTF8 code weren't being run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:31:18 2018
From: report at bugs.python.org (Jay Yin)
Date: Fri, 26 Jan 2018 02:31:18 +0000
Subject: [issue2793] Dictionary fails to index when adding list when in a
 deeply nested loop
In-Reply-To: <1210276965.56.0.576720171368.issue2793@psf.upfronthosting.co.za>
Message-ID: <1516933878.08.0.467229070634.issue2793@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


----------
pull_requests: +5177

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2793>
_______________________________________

From report at bugs.python.org  Thu Jan 25 21:59:15 2018
From: report at bugs.python.org (Dean Liao)
Date: Fri, 26 Jan 2018 02:59:15 +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: <1516935555.95.0.467229070634.issue23078@psf.upfronthosting.co.za>


Dean Liao <deanliao at gmail.com> added the comment:

I planned to upgrade Chromium OS's mock module to 2.0.0. I also encountered the issue that classmethod cannot be patched as callable mock.

Reviewers, can we start the review process?

----------
nosy: +deanliao

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Thu Jan 25 22:18:49 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 26 Jan 2018 03:18:49 +0000
Subject: [issue27931] Email parse IndexError <""@wiarcom.com>
In-Reply-To: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>
Message-ID: <1516936729.98.0.467229070634.issue27931@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
type:  -> behavior
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27931>
_______________________________________

From report at bugs.python.org  Thu Jan 25 22:29:38 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 03:29:38 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516937378.69.0.467229070634.issue32571@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5178

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Thu Jan 25 22:30:50 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 26 Jan 2018 03:30:50 +0000
Subject: [issue32640] Python 2.7 str.join documentation is incorrect
In-Reply-To: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>
Message-ID: <1516937450.72.0.467229070634.issue32640@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
keywords: +patch
pull_requests: +5179
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Thu Jan 25 22:33:10 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 26 Jan 2018 03:33:10 +0000
Subject: [issue32640] Python 2.7 str.join documentation is incorrect
In-Reply-To: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>
Message-ID: <1516937590.87.0.467229070634.issue32640@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

GH-5333 clarifies that str.join can return a Unicode object if iterable contains a Unicode object, and that it will raise TypeError if there is any non string or non unicode object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Thu Jan 25 22:40:35 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Fri, 26 Jan 2018 03:40:35 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1516938035.24.0.467229070634.issue32657@psf.upfronthosting.co.za>


Change by Chason Chaffin <chason at gmail.com>:


----------
keywords: +patch
pull_requests: +5180
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:04:25 2018
From: report at bugs.python.org (dancollins34)
Date: Fri, 26 Jan 2018 04:04:25 +0000
Subject: [issue32672] .then execution of actions following a future's
 completion
Message-ID: <1516939465.12.0.467229070634.issue32672@psf.upfronthosting.co.za>


New submission from dancollins34 <dancollins34 at gmail.com>:

To my knowledge, python currently has no capability to chain future execution, requiring another future to begin executing with the result from the first.

I have submitted a pr to enable this functionality with a .then(self, fn) method on the concurrent.futures.Future object.

-dancollins34

----------
components: Interpreter Core
messages: 310730
nosy: dancollins34
priority: normal
pull_requests: 5181
severity: normal
status: open
title: .then execution of actions following a future's completion
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32672>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:09:32 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Jan 2018 04:09:32 +0000
Subject: [issue32672] .then execution of actions following a future's
 completion
In-Reply-To: <1516939465.12.0.467229070634.issue32672@psf.upfronthosting.co.za>
Message-ID: <1516939772.52.0.467229070634.issue32672@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think this requires a discussion on the python-ideas mailing list, since API changes to Future need consideration in the asyncio context as well.

----------
components: +Library (Lib) -Interpreter Core
nosy: +r.david.murray
type:  -> enhancement
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32672>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:17:55 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Jan 2018 04:17:55 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1516940275.84.0.467229070634.issue32657@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's probably enough to fix it.  I fear that if we also change them in sendmail we'll break someone's code, but maybe we should do that anyway, for 3.7 only.

----------
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:22:28 2018
From: report at bugs.python.org (dancollins34)
Date: Fri, 26 Jan 2018 04:22:28 +0000
Subject: [issue32672] .then execution of actions following a future's
 completion
In-Reply-To: <1516939465.12.0.467229070634.issue32672@psf.upfronthosting.co.za>
Message-ID: <1516940548.33.0.467229070634.issue32672@psf.upfronthosting.co.za>


Change by dancollins34 <dancollins34 at gmail.com>:


----------
keywords: +patch
pull_requests: +5182
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32672>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:24:18 2018
From: report at bugs.python.org (dancollins34)
Date: Fri, 26 Jan 2018 04:24:18 +0000
Subject: [issue32672] .then execution of actions following a future's
 completion
In-Reply-To: <1516939465.12.0.467229070634.issue32672@psf.upfronthosting.co.za>
Message-ID: <1516940658.52.0.467229070634.issue32672@psf.upfronthosting.co.za>


dancollins34 <dancollins34 at gmail.com> added the comment:

Okay, I'll post something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32672>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:43:17 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Fri, 26 Jan 2018 04:43:17 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1516941797.65.0.467229070634.issue32657@psf.upfronthosting.co.za>


Chason Chaffin <chason at gmail.com> added the comment:

> It's probably enough to fix it.  I fear that if we also change them in sendmail we'll break someone's code, but maybe we should do that anyway, for 3.7 only.

Should I make a separate issue for that, or attach it to this PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:49:58 2018
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 26 Jan 2018 04:49:58 +0000
Subject: [issue29237] Create enum for pstats sorting options
In-Reply-To: <1484098294.24.0.117553666266.issue29237@psf.upfronthosting.co.za>
Message-ID: <1516942198.81.0.467229070634.issue29237@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 863b1e4d0e95036bca4e97c1b8b2ca72c19790fb by Ethan Furman (mwidjaja) in branch 'master':
bpo-29237: Create enum for pstats sorting options (GH-5103)
https://github.com/python/cpython/commit/863b1e4d0e95036bca4e97c1b8b2ca72c19790fb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29237>
_______________________________________

From report at bugs.python.org  Fri Jan 26 00:09:18 2018
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 26 Jan 2018 05:09:18 +0000
Subject: [issue29237] Create enum for pstats sorting options
In-Reply-To: <1484098294.24.0.117553666266.issue29237@psf.upfronthosting.co.za>
Message-ID: <1516943358.14.0.467229070634.issue29237@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +5183

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29237>
_______________________________________

From report at bugs.python.org  Fri Jan 26 00:27:00 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 26 Jan 2018 05:27:00 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516944420.04.0.467229070634.issue32591@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Right, I *knew* I should be nervous about calling into Python from a C-level destructor... what's happening is:

- Somehow, that coroutine object is managing to survive until the very, very end of the shutdown sequence (PyImport_Cleanup). I'm not sure how exactly; Yury suspects it somehow involves _asynciomodule.c holding a reference.

- At the very end of PyImport_Cleanup, there's a final call to the cycle collector, which destroys the coroutine object

- _PyGen_Finalize notices it's unawaited, and calls _PyErr_WarnUnawaitedCoroutine

- _PyErr_WarnUnawaitedCoroutine attempts to call warnings._warn_unawaited_coroutine, in a very careful and defensive manner

- But it doesn't matter how careful and defensive you are, because at this stage in the shutdown, we have sys.module = None, which freaks out the import system so badly that when we try to look up the warnings module, it doesn't even raise an error, it just abort()s the whole interpreter.

We can get a similar crash by doing:

import sys
async def f(): pass
sys.corocycle = [f]
sys.corocycle.append(sys.corocycle)

If you run the same code on 3.6, then it gets collected at the same time, and it issues a warning using the regular PyErr_WarnEx. It turns out that code is even *more* careful and defensive and notices that the interpreter is being shutdown, so it just skips printing the warning entirely.

I guess what we have to do is add a similar check to _PyErr_WarnUnawaitedCoroutine.

You can imagine how excited I am that I started working on this patch so I could make sure people get more reliable notice of unawaited coroutines (bpo-30491), and not only has that been rejected, but now I'm writing code to explicitly hide unawaited coroutine warnings. Just saying'...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 00:37:50 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 26 Jan 2018 05:37:50 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516945070.26.0.467229070634.issue32591@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
pull_requests: +5184
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 00:38:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 05:38:38 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516945118.88.0.467229070634.issue32662@psf.upfronthosting.co.za>


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


----------
pull_requests: +5185

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:10:52 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 26 Jan 2018 06:10:52 +0000
Subject: [issue32673] update tutorial dict part to reflect dict is ordered
Message-ID: <1516947052.29.0.467229070634.issue32673@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

Ordered builtin dict is the rule in 3.7, the tutorial part about dict[1] needs updating.

[1] https://docs.python.org/3.7/tutorial/datastructures.html#dictionaries

----------
assignee: docs at python
components: Documentation
messages: 310737
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: needs patch
status: open
title: update tutorial dict part to reflect dict is ordered
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32673>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:22:18 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Fri, 26 Jan 2018 06:22:18 +0000
Subject: [issue32673] update tutorial dict part to reflect dict is ordered
In-Reply-To: <1516947052.29.0.467229070634.issue32673@psf.upfronthosting.co.za>
Message-ID: <1516947738.94.0.467229070634.issue32673@psf.upfronthosting.co.za>


Change by Chason Chaffin <chason at gmail.com>:


----------
nosy: +chason

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32673>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:23:22 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 06:23:22 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516947802.04.0.467229070634.issue32630@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

You guys both need to calm down.

Stefan, what's your objection against this, assuming the crash is fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:29:16 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 06:29:16 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516948156.09.0.467229070634.issue32591@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Maybe it's better to roll this back and take a deep breath. The feature freeze should not be treated as an excuse to cram in things at the last minute. Before this week I had never heard of this proposal. And the sarcasm is a bad start of your stint as a core dev, Nathaniel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:31:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 06:31:05 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516948265.57.0.467229070634.issue32662@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 4112c5b97d9c1c7b034653d0e017ffa894a45c74 by Yury Selivanov in branch 'master':
bpo-32662: Try making test_asyncio.test_server more reliable (#5338)
https://github.com/python/cpython/commit/4112c5b97d9c1c7b034653d0e017ffa894a45c74


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:41:42 2018
From: report at bugs.python.org (Qian Yun)
Date: Fri, 26 Jan 2018 06:41:42 +0000
Subject: [issue32674] minor documentation fix for '__import__'
Message-ID: <1516948902.25.0.467229070634.issue32674@psf.upfronthosting.co.za>


New submission from Qian Yun <oldk1331 at gmail.com>:

This is a minor documentation for builtin function '__import__'.

----------
assignee: docs at python
components: Documentation
messages: 310741
nosy: Qian Yun, docs at python
priority: normal
severity: normal
status: open
title: minor documentation fix for '__import__'
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32674>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:46:51 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 06:46:51 +0000
Subject: [issue32674] minor documentation fix for '__import__'
In-Reply-To: <1516948902.25.0.467229070634.issue32674@psf.upfronthosting.co.za>
Message-ID: <1516949211.98.0.467229070634.issue32674@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

minor documentation?

I don't understand, the documentation of __import__ is well done, could you explain ?

https://docs.python.org/3/library/functions.html#__import__

thank you

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32674>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:47:53 2018
From: report at bugs.python.org (Qian Yun)
Date: Fri, 26 Jan 2018 06:47:53 +0000
Subject: [issue32674] minor documentation fix for '__import__'
In-Reply-To: <1516948902.25.0.467229070634.issue32674@psf.upfronthosting.co.za>
Message-ID: <1516949273.42.0.467229070634.issue32674@psf.upfronthosting.co.za>


Change by Qian Yun <oldk1331 at gmail.com>:


----------
keywords: +patch
pull_requests: +5186
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32674>
_______________________________________

From report at bugs.python.org  Fri Jan 26 02:00:14 2018
From: report at bugs.python.org (Qian Yun)
Date: Fri, 26 Jan 2018 07:00:14 +0000
Subject: [issue32674] minor documentation fix for '__import__'
In-Reply-To: <1516948902.25.0.467229070634.issue32674@psf.upfronthosting.co.za>
Message-ID: <1516950014.04.0.467229070634.issue32674@psf.upfronthosting.co.za>


Qian Yun <oldk1331 at gmail.com> added the comment:

Sorry, a typo, it's "minor documentation fix".

See https://github.com/python/cpython/pull/5339

diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
index d8971bef2a..80b4f9447c 100644
--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -317,7 +317,7 @@ PyDoc_STRVAR(import_doc,
 "__import__(name, globals=None, locals=None, fromlist=(), level=0) -> module\n\
 \n\
 Import a module. Because this function is meant for use by the Python\n\
-interpreter and not for general use it is better to use\n\
+interpreter and not for general use, it is better to use\n\
 importlib.import_module() to programmatically import a module.\n\
 \n\
 The globals argument is only used to determine the context;\n\
@@ -326,8 +326,8 @@ should be a list of names to emulate ``from name import ...'', or an\n\
 empty list to emulate ``import name''.\n\
 When importing a module from a package, note that __import__('A.B', ...)\n\
 returns package A when fromlist is empty, but its submodule B when\n\
-fromlist is not empty.  Level is used to determine whether to perform \n\
-absolute or relative imports. 0 is absolute while a positive number\n\
+fromlist is not empty.  The level argument is used to determine whether to\n\
+perform absolute or relative imports, 0 is absolute while a positive number\n\
 is the number of parent directories to search relative to the current module.");

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32674>
_______________________________________

From report at bugs.python.org  Fri Jan 26 02:16:29 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 26 Jan 2018 07:16:29 +0000
Subject: [issue32673] update tutorial dict part to reflect dict is ordered
In-Reply-To: <1516947052.29.0.467229070634.issue32673@psf.upfronthosting.co.za>
Message-ID: <1516950989.05.0.467229070634.issue32673@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

See Issue 32337

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32673>
_______________________________________

From report at bugs.python.org  Fri Jan 26 02:16:47 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 07:16:47 +0000
Subject: [issue32674] minor documentation fix for '__import__'
In-Reply-To: <1516950014.04.0.467229070634.issue32674@psf.upfronthosting.co.za>
Message-ID: <20180126071643.GA16431@xps>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Don't worry, but in fact, I did not understand because when you post
your issue, there was no associated PR.

Now, I do understand.

Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32674>
_______________________________________

From report at bugs.python.org  Fri Jan 26 02:22:53 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 07:22:53 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516951373.64.0.467229070634.issue32571@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset e76daebc0c8afa3981a4c5a8b54537f756e805de by INADA Naoki in branch 'master':
bpo-32571: Fix reading uninitialized memory (GH-5332)
https://github.com/python/cpython/commit/e76daebc0c8afa3981a4c5a8b54537f756e805de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Fri Jan 26 02:39:38 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 26 Jan 2018 07:39:38 +0000
Subject: [issue32673] update tutorial dict part to reflect dict is ordered
In-Reply-To: <1516947052.29.0.467229070634.issue32673@psf.upfronthosting.co.za>
Message-ID: <1516952378.41.0.467229070634.issue32673@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Thanks for reminding, Martin.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Dict order is now guaranteed, so add tests and doc for it

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32673>
_______________________________________

From report at bugs.python.org  Fri Jan 26 04:56:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 09:56:43 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516960603.38.0.467229070634.issue32662@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

test_asyncio.test_start_server_1() hangs on "s390x Debian 3.x" buildbot:
http://buildbot.python.org/all/#builders/13/builds/579

test_set_nodelay (test.test_asyncio.test_selector_events.TestSelectorUtils) ... ok
test_start_server_1 (test.test_asyncio.test_server.ProactorStartServerTests) ... skipped 'Windows only'
Exception in thread test-client:
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/functional.py", line 193, in run
    self._prog(TestSocketWrapper(self._sock))
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_server.py", line 44, in <lambda>
    with self.tcp_client(lambda sock: client(sock, addr)):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_server.py", line 19, in client
    sock.connect(addr)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/functional.py", line 195, in run
    self._test._abort_socket_test(ex)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/functional.py", line 122, in _abort_socket_test
    self.fail(ex)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 680, in fail
    raise self.failureException(msg)
AssertionError: [Errno 111] Connection refused

Timeout (0:15:00)!
Thread 0x000003fffcdcd710 (most recent call first):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/selectors.py", line 468 in select
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/asyncio/base_events.py", line 1555 in _run_once
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/asyncio/base_events.py", line 450 in run_forever
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/asyncio/base_events.py", line 482 in run_until_complete
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_server.py", line 45 in test_start_server_1
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 615 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 663 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/runner.py", line 176 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/support/__init__.py", line 1861 in _run_suite
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/support/__init__.py", line 1951 in run_unittest
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 175 in test_runner
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 176 in runtest_inner
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 291 in rerun_failed_tests
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 540 in _main
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 510 in main
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 585 in main
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/runpy.py", line 85 in _run_code
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/runpy.py", line 193 in _run_module_as_main
test_start_server_1 (test.test_asyncio.test_server.SelectorStartServerTests) ... Makefile:1090: recipe for target 'buildbottest' failed
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=2050.270461

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Fri Jan 26 04:58:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 09:58:39 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516960719.46.0.467229070634.issue32662@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The test fails differently on s390x SLES 3.x:
http://buildbot.python.org/all/#/builders/16/builds/576

...
test_force_close (test.test_asyncio.test_selector_events.SelectorTransportTests) ... ok
test_set_nodelay (test.test_asyncio.test_selector_events.TestSelectorUtils) ... ok
test_start_server_1 (test.test_asyncio.test_server.ProactorStartServerTests) ... skipped 'Windows only'
test_start_server_1 (test.test_asyncio.test_server.SelectorStartServerTests) ... Exception in thread test-client:
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/functional.py", line 193, in run
    self._prog(TestSocketWrapper(self._sock))
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/test_server.py", line 44, in <lambda>
    with self.tcp_client(lambda sock: client(sock, addr)):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/test_server.py", line 19, in client
    sock.connect(addr)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/functional.py", line 195, in run
    self._test._abort_socket_test(ex)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/functional.py", line 122, in _abort_socket_test
    self.fail(ex)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/unittest/case.py", line 680, in fail
    raise self.failureException(msg)
AssertionError: [Errno 111] Connection refused

/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/test_server.py:45: ResourceWarning: unclosed <socket.socket fd=8, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 56340)>
  self.loop.run_until_complete(main_task)
ERROR
test_start_unix_server_1 (test.test_asyncio.test_server.SelectorStartServerTests) ... ok
test_start_tls_client_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests) ... skipped 'Windows only'
test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests) ... skipped 'Windows only'
test_start_tls_wrong_args (test.test_asyncio.test_sslproto.ProactorStartTLSTests) ... skipped 'Windows only'
test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... /home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/collections/__init__.py:404: ResourceWarning: unclosed <socket.socket fd=7, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('127.0.0.1', 42302)>
  result = _self._make(map(kwds.pop, field_names, _self))
Unhandled error in exception handler
context: {'message': 'Task was destroyed but it is pending!', 'task': <Task pending coro=<BaseStartServer.test_start_server_1.<locals>.main() done, defined at /home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/test_server.py:31> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x3fff979bbf8>()]>>}
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/asyncio/base_events.py", line 1459, in call_exception_handler
    self._exception_handler(self, context)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/functional.py", line 22, in loop_exception_handler
    self.loop.default_exception_handler(context)
AttributeError: 'NoneType' object has no attribute 'default_exception_handler'
ok
test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok
test_start_tls_wrong_args (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok
test_cancel_handshake (test.test_asyncio.test_sslproto.SslProtoHandshakeTests) ... ok
test_close_during_handshake (test.test_asyncio.test_sslproto.SslProtoHandshakeTests) .
...

======================================================================
ERROR: test_start_server_1 (test.test_asyncio.test_server.SelectorStartServerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_asyncio/test_server.py", line 45, in test_start_server_1
    self.loop.run_until_complete(main_task)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/asyncio/base_events.py", line 493, in run_until_complete
    raise RuntimeError('Event loop stopped before Future completed.')
RuntimeError: Event loop stopped before Future completed.
----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Fri Jan 26 05:00:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 10:00:41 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516960841.46.0.467229070634.issue32662@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Just to be complete, the test also fails on x86 Gentoo Non-Debug with X 3.x:
http://buildbot.python.org/all/#/builders/99/builds/564

...
test_start_server_1 (test.test_asyncio.test_server.SelectorStartServerTests) ... Exception in thread test-client:
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/functional.py", line 193, in run
    self._prog(TestSocketWrapper(self._sock))
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_server.py", line 44, in <lambda>
    with self.tcp_client(lambda sock: client(sock, addr)):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_server.py", line 19, in client
    sock.connect(addr)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/functional.py", line 195, in run
    self._test._abort_socket_test(ex)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/functional.py", line 122, in _abort_socket_test
    self.fail(ex)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/unittest/case.py", line 680, in fail
    raise self.failureException(msg)
AssertionError: [Errno 111] Connection refused

Timeout (0:15:00)!
Thread 0xb7d69700 (most recent call first):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/selectors.py", line 468 in select
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/base_events.py", line 1555 in _run_once
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/base_events.py", line 450 in run_forever
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/base_events.py", line 482 in run_until_complete
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_server.py", line 45 in test_start_server_1
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Fri Jan 26 05:43:55 2018
From: report at bugs.python.org (xitop)
Date: Fri, 26 Jan 2018 10:43:55 +0000
Subject: [issue32675] dict.__contains__(unhashable) raises TypeError where
 False was expected
Message-ID: <1516963435.48.0.467229070634.issue32675@psf.upfronthosting.co.za>


New submission from xitop <reg.bugs at poti.sk>:

The `dict.__contains()` function does not fully comply with the description in the "Data Model" section of the official documentation, which states:
  "__contains__(self, item) ... Should return true if item is in self, false otherwise."

Basically the same is written in "Mapping Types - dict": "key in d - Return True if d has a key key, else False."

According to that, testing a presence of an unhashable object in a dict should return False. But it raises a TypeError instead.

Example:
  >>> () in {}
  False
but:
  >>> [] in {}
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unhashable type: 'list'

There is a related SO question:
  https://stackoverflow.com/questions/48444079/unexpected-behaviour-of-dictionary-membership-check
currently without a clear answer whether it is a bug or desired behaviour supposed to expose programming errors. In the latter case, it seems to be not documented.

----------
components: Interpreter Core
messages: 310751
nosy: xitop
priority: normal
severity: normal
status: open
title: dict.__contains__(unhashable) raises TypeError where False was expected
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32675>
_______________________________________

From report at bugs.python.org  Fri Jan 26 05:44:05 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Jan 2018 10:44:05 +0000
Subject: [issue30622] Fix NPN guard for OpenSSL 1.1
In-Reply-To: <1497107294.71.0.653300932954.issue30622@psf.upfronthosting.co.za>
Message-ID: <1516963445.09.0.467229070634.issue30622@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5187

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30622>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:03:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 11:03:13 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1516964593.55.0.467229070634.issue32441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The change introduced a warning. Can someone please take a look (and maybe fix it)?

./Modules/posixmodule.c: In function 'os_dup2_impl':
./Modules/posixmodule.c:7785:9: warning: 'res' may be used uninitialized in this function [-Wmaybe-uninitialized]
     int res;
         ^~~

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:07:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 11:07:29 +0000
Subject: [issue32676] test_asyncio emits many warnings when run in debug mode
Message-ID: <1516964849.79.0.467229070634.issue32676@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

vstinner at apu$ ./python -u -X dev -m test -v test_asyncio 2>&1|tee log

Tests which emit warnings:

test__sock_sendfile_native_failure (test.test_asyncio.test_base_events.BaseLoopSendfileTests) ...
/home/vstinner/prog/python/master/Lib/asyncio/selector_events.py:648: ResourceWarning: unclosed transport <_SelectorSocketTransport fd=11>
  source=self)
ok

test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ...
Executing <Handle <TaskWakeupMethWrapper object at 0x7f85fab75838>(<Future finis...events.py:304>) created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_sslproto.py:202> took 0.205 seconds
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTask_CFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_context_3 (test.test_asyncio.test_tasks.CTask_PyFuture_Tests) ...
Executing <Handle <TaskWakeupMethWrapper object at 0x7f860261ce98>(<Future finis...events.py:304>) created at /home/vstinner/prog/python/master/Lib/asyncio/futures.py:288> took 5.753 seconds
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTask_PyFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_CFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

----------
components: Tests, asyncio
messages: 310753
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio emits many warnings when run in debug mode
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32676>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:09:08 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 11:09:08 +0000
Subject: [issue32677] Add str.isascii()
Message-ID: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

int() and str.is*** functions accepts other than ASCII.
But we want to accept only ASCII in some cases.  (e.g. ipaddress module)

We can use try-except to check ASCII, but it's inefficient.

try:
    s.encode('ascii')
except UnicodeEncodeError:
    ascii = False
else:
    ascii = True

CPython can check string is ASCII efficiently.

(Voting on python-ideas ML now)

----------
components: Interpreter Core
messages: 310754
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Add str.isascii()
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:09:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 11:09:44 +0000
Subject: [issue32677] Add str.isascii()
In-Reply-To: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>
Message-ID: <1516964984.98.0.467229070634.issue32677@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> (Voting on python-ideas ML now)

https://mail.python.org/pipermail/python-ideas/2018-January/048737.html

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:10:25 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 11:10:25 +0000
Subject: [issue32677] Add str.isascii()
In-Reply-To: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>
Message-ID: <1516965025.36.0.467229070634.issue32677@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +5188
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:15:23 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Jan 2018 11:15:23 +0000
Subject: [issue30622] Fix NPN guard for OpenSSL 1.1
In-Reply-To: <1497107294.71.0.653300932954.issue30622@psf.upfronthosting.co.za>
Message-ID: <1516965323.86.0.467229070634.issue30622@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5189

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30622>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:32:42 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 11:32:42 +0000
Subject: [issue32675] dict.__contains__(unhashable) raises TypeError where
 False was expected
In-Reply-To: <1516963435.48.0.467229070634.issue32675@psf.upfronthosting.co.za>
Message-ID: <1516966362.58.0.467229070634.issue32675@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

"Key must be hashable" is precondition of dict operations.

All operations for dict will raise TypeError for unhashable keys.
For example, d[k] will raise TypeError too, but document doesn't
mention about it:

"""
Return the item of d with key key. Raises a KeyError if key is not in the map.
"""
https://docs.python.org/3/library/stdtypes.html#dict

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32675>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:54:11 2018
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 26 Jan 2018 11:54:11 +0000
Subject: [issue32378] test_npn_protocols broken with LibreSSL 2.6.1+
In-Reply-To: <1513709944.02.0.213398074469.issue32378@psf.upfronthosting.co.za>
Message-ID: <1516967651.48.0.467229070634.issue32378@psf.upfronthosting.co.za>


Bernard Spil <python at bachfreund.nl> added the comment:

See also https://github.com/python/cpython/pull/5343

Note: I am Sp1l on Github, spil here, CLA has been signed.

----------
nosy: +spil
pull_requests: +5190

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32378>
_______________________________________

From report at bugs.python.org  Fri Jan 26 07:02:58 2018
From: report at bugs.python.org (qb-cea)
Date: Fri, 26 Jan 2018 12:02:58 +0000
Subject: [issue32665] pathlib.Path._from_parsed_parts should call
 cls.__new__(cls)
In-Reply-To: <1516883245.2.0.467229070634.issue32665@psf.upfronthosting.co.za>
Message-ID: <1516968178.14.0.467229070634.issue32665@psf.upfronthosting.co.za>


qb-cea <quentin.bouget at cea.fr> added the comment:

Typo in the code of the previous comment:

- __slots__ = ("new_attr",)
+ __slots__ = ("_new_attr",)

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32665>
_______________________________________

From report at bugs.python.org  Fri Jan 26 07:30:50 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 12:30:50 +0000
Subject: [issue32678] Lazy import ast in inspect
Message-ID: <1516969850.22.0.467229070634.issue32678@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

inspect imports ast but it's used only for creating signature.

But asyncio uses inspect module for unwrap(), isgenerator(), etc...
And ast module is relatively heavy for import.

This is output of python -Ximporttime -c 'import asyncio':

import time:       147 |        147 |     asyncio.constants
import time:      1456 |       1456 |           _ast
import time:       363 |       1818 |         ast
...
import time:      1890 |       5152 |       inspect
...
import time:       303 |       5984 |     asyncio.coroutines
...
import time:       731 |      37941 |   asyncio.base_events
...
import time:       375 |      41383 | asyncio

----------
components: Library (Lib)
messages: 310759
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Lazy import ast in inspect
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32678>
_______________________________________

From report at bugs.python.org  Fri Jan 26 07:32:52 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 12:32:52 +0000
Subject: [issue32678] Lazy import ast in inspect
In-Reply-To: <1516969850.22.0.467229070634.issue32678@psf.upfronthosting.co.za>
Message-ID: <1516969972.27.0.467229070634.issue32678@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +5191
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32678>
_______________________________________

From report at bugs.python.org  Fri Jan 26 08:24:50 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 26 Jan 2018 13:24:50 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516973090.23.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Here's where I am on what methods are added under which circumstances. Hopefully these tables don't get mangled.

The more I think about what to do with hash and raising exceptions, the more I think that the right answer is to not raise any exceptions, and just follow the rule of "don't overwrite an attribute that the user specified". The uses of hash=True or hash=None are so specialized that users can be expected to understand the implications. The interaction among hash=, eq=, and frozen= are sufficiently complicated (see the last table below) that we don't need to add any more rules.

There are only 2 places below where exceptions are raised:

1. frozen=True and the user supplied __setattr__ or __delattr__. These methods are crucial for frozen-ness, so we must be able to add them.

2. order=True and the user supplied at least one of __lt__, __le__, __ge__, or __gt__. This is at Nick's request (see msg310464 in this issue). I'm not so sure about this one: if the user wants to explicitly ask that these methods be added (by specifying order=True, which is not the default), and they also specify some of the ordering function, then why not let them, and have dataclass add the missing ones as we normally would? But I'm not heavily invested in the outcome, as I don't see any reason to write such code, anyway. The only reason I'd suggest leaving it out is to avoid having to explain it in the documentation.

I have this all coded up and ready to create a PR, modulo a few more tests. I'll get it committed before Beta 1. Hopefully these tables answers the questions about the new proposal.

# Conditions for adding methods:
# added = method is added
#       = no action: method is not added
# raise = TypeError is raised
# None  = attribute is set to None

# __init__
#
#   +--- init= parameter
#   |
#   v    |   yes   |   no    |  <--- class has __init__?
# -------+---------+---------+
#  False |         |         |
# -------+---------+---------+
#  True  |         | added   |  <- the default
# -------+---------+---------+

# __repr__
#
#   +--- repr= parameter
#   |
#   v    |   yes   |   no    |  <--- class has __repr__?
# -------+---------+---------+
#  False |         |         |
# -------+---------+---------+
#  True  |         | added   |  <- the default
# -------+---------+---------+

# __setattr__
# __delattr__
#
#   +--- frozen= parameter
#   |
#   v    |   yes   |   no    |  <--- class has __setattr__ or __delattr__?
# -------+---------+---------+
#  False |         |         |  <- the default
# -------+---------+---------+
#  True  | raise * | added   |
# -------+---------+---------+
#
# * Raise because not adding these methods
#    would break the "frozen-ness" of the class.

# __eq__
#
#   +--- eq= parameter
#   |
#   v    |   yes   |   no    |  <--- class has __eq__?
# -------+---------+---------+
#  False |         |         |
# -------+---------+---------+
#  True  |         | added   |  <- the default
# -------+---------+---------+

# __lt__
# __le__
# __gt__
# __ge__
#
#   +--- order= parameter
#   |
#   v    |   yes   |   no    |  <--- class has any comparison method?
# -------+---------+---------+
#  False |         |         |  <- the default
# -------+---------+---------+
#  True  | raise * | added   |
# -------+---------+---------+
#
# * Raise because to allow this case would interfere with using
#    functools.total_ordering.

# __hash__

#   +------------------- hash= parameter
#   |       +----------- eq= parameter
#   |       |       +--- frozen= parameter
#   |       |       |
#   v    |  v    |  v    |  yes  |  no   |  <--- class has __hash__?
# -------+-------+-------+-------+-------+
#  False | False | False |       |       |
# -------+-------+-------+-------+-------+
#  False | False | True  |       |       |
# -------+-------+-------+-------+-------+
#  False | True  | False |       |       |
# -------+-------+-------+-------+-------+
#  False | True  | True  |       |       |
# -------+-------+-------+-------+-------+
#  True  | False | False |       | added | Has no __eq__, but hashable
# -------+-------+-------+-------+-------+
#  True  | False | True  |       | added | Has no __eq__, but hashable
# -------+-------+-------+-------+-------+
#  True  | True  | False |       | added | Not frozen, but hashable
# -------+-------+-------+-------+-------+
#  True  | True  | True  |       | added | Frozen, so hashable
# -------+-------+-------+-------+-------+
#  None  | False | False |       |       | No __eq__, use the base class __hash__
# -------+-------+-------+-------+-------+
#  None  | False | True  |       |       | No __eq__, use the base class __hash__
# -------+-------+-------+-------+-------+
#  None  | True  | False |       | None  | <-- the default, not hashable
# -------+-------+-------+-------+-------+
#  None  | True  | True  |       | added | Frozen, so hashable
# -------+-------+-------+-------+-------+
#
# For boxes that are blank, __hash__ is untouched and therefore
#  inherited from the base class.  If the base is object, then
#  id-based hashing is used.
# Note that a class may have already __hash__=None if it specified an
#  __eq__ method in the class body (not one that was created by
#  dataclass).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Fri Jan 26 09:13:42 2018
From: report at bugs.python.org (Jay Yin)
Date: Fri, 26 Jan 2018 14:13:42 +0000
Subject: [issue27931] Email parse IndexError <""@wiarcom.com>
In-Reply-To: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>
Message-ID: <1516976022.25.0.467229070634.issue27931@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

https://github.com/python/cpython/pull/5329
this is the pending pull request for this

----------
nosy: +jayyin11043

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27931>
_______________________________________

From report at bugs.python.org  Fri Jan 26 09:14:07 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 26 Jan 2018 14:14:07 +0000
Subject: [issue2793] Dictionary fails to index when adding list when in a
 deeply nested loop
In-Reply-To: <1210276965.56.0.576720171368.issue2793@psf.upfronthosting.co.za>
Message-ID: <1516976047.52.0.467229070634.issue2793@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
pull_requests:  -5177

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2793>
_______________________________________

From report at bugs.python.org  Fri Jan 26 09:23:30 2018
From: report at bugs.python.org (Jonas H.)
Date: Fri, 26 Jan 2018 14:23:30 +0000
Subject: [issue32679] concurrent.futures should store full sys.exc_info()
Message-ID: <1516976610.0.0.467229070634.issue32679@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

Use case: Try to get a future's result using concurrent.futures.Future.result(), and log the full exception if there was any.

Currently, only "excinst" (sys.exc_info()[1]) is provided with the Future.exception() method.

Proposal: Add new Future.exc_info() method that returns the full sys.exc_info() at the time of the exception.

----------
components: Library (Lib)
messages: 310762
nosy: jonash
priority: normal
severity: normal
status: open
title: concurrent.futures should store full sys.exc_info()
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32679>
_______________________________________

From report at bugs.python.org  Fri Jan 26 09:24:10 2018
From: report at bugs.python.org (Jonas H.)
Date: Fri, 26 Jan 2018 14:24:10 +0000
Subject: [issue32679] concurrent.futures should store full sys.exc_info()
In-Reply-To: <1516976610.0.0.467229070634.issue32679@psf.upfronthosting.co.za>
Message-ID: <1516976650.81.0.467229070634.issue32679@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

See also https://stackoverflow.com/questions/19309514/getting-original-line-number-for-exception-in-concurrent-futures for other people having the same problem

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32679>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:26:15 2018
From: report at bugs.python.org (Romuald Brunet)
Date: Fri, 26 Jan 2018 15:26:15 +0000
Subject: [issue32680] smtplib SMTP instances missing a default sock attribute
Message-ID: <1516980375.64.0.467229070634.issue32680@psf.upfronthosting.co.za>


New submission from Romuald Brunet <romuald.brunet at gmail.com>:

SMTP instances from the smtplib module are not creating their sock attribute consistently after __init__

When host is sent as parameter a sock object is created (and hopefully, connected)

When the host is not sent, the sock attribute doesn't exist at all

----------
messages: 310764
nosy: Romuald
priority: normal
severity: normal
status: open
title: smtplib SMTP instances missing a default sock attribute

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32680>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:31:26 2018
From: report at bugs.python.org (Romuald Brunet)
Date: Fri, 26 Jan 2018 15:31:26 +0000
Subject: [issue32680] smtplib SMTP instances missing a default sock attribute
In-Reply-To: <1516980375.64.0.467229070634.issue32680@psf.upfronthosting.co.za>
Message-ID: <1516980686.04.0.467229070634.issue32680@psf.upfronthosting.co.za>


Change by Romuald Brunet <romuald.brunet at gmail.com>:


----------
keywords: +patch
pull_requests: +5192
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32680>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:34:10 2018
From: report at bugs.python.org (Romuald Brunet)
Date: Fri, 26 Jan 2018 15:34:10 +0000
Subject: [issue32680] smtplib SMTP instances missing a default sock attribute
In-Reply-To: <1516980375.64.0.467229070634.issue32680@psf.upfronthosting.co.za>
Message-ID: <1516980850.17.0.467229070634.issue32680@psf.upfronthosting.co.za>


Romuald Brunet <romuald.brunet at gmail.com> added the comment:

My use case:

try:
  s = SMTP('myhost')
  s.do_some_sending()
finaly:
  if s is not None and s.sock is not None:
    s.quit()

But I realize just now that in that case, if s was initialized correctly, its sock was inevitably set

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32680>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:34:17 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 15:34:17 +0000
Subject: [issue32681] Fix uninitialized variable in os_dup2_impl
Message-ID: <20180126153414.GA604@xps>


New submission from St?phane Wirtel <stephane at wirtel.be>:

With the last revision, I get this warning from the compiler.

gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration   -I. -I./Include    -DPy_BUILD_CORE  -c ./Modules/_collectionsmodule.c -o Modules/_collectionsmodule.o
./Modules/posixmodule.c: In function ?os_dup2_impl?:
./Modules/posixmodule.c:7785:9: warning: ?res? may be used uninitialized in this function [-Wmaybe-uninitialized]
     int res;
         ^~~

----------
messages: 310767
nosy: matrixise
priority: normal
severity: normal
status: open
title: Fix uninitialized variable in os_dup2_impl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:35:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 15:35:08 +0000
Subject: [issue32681] Fix uninitialized variable in os_dup2_impl
In-Reply-To: <20180126153414.GA604@xps>
Message-ID: <1516980908.76.0.467229070634.issue32681@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I already reported the issue at:
https://bugs.python.org/issue32441#msg310752

I suggest to close this issue as a duplicate.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:38:21 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 15:38:21 +0000
Subject: [issue32681] Fix uninitialized variable in os_dup2_impl
In-Reply-To: <20180126153414.GA604@xps>
Message-ID: <1516981101.8.0.467229070634.issue32681@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +5194
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:43:35 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 26 Jan 2018 15:43:35 +0000
Subject: [issue23080] BoundArguments.arguments should be unordered
In-Reply-To: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za>
Message-ID: <1516981415.31.0.467229070634.issue23080@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I know there are other issues to remove OrderedDicts, so should this patch be used for BoundArguments?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23080>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:44:00 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 26 Jan 2018 15:44:00 +0000
Subject: [issue23080] BoundArguments.arguments should be unordered
In-Reply-To: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za>
Message-ID: <1516981440.59.0.467229070634.issue23080@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23080>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:46:04 2018
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 26 Jan 2018 15:46:04 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516981564.21.0.467229070634.issue18533@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset d7773d92bd11640a8c950d6c36a9cef1cee36f96 by Senthil Kumaran (bennorth) in branch 'master':
bpo-18533: Avoid RecursionError from repr() of recursive dictview (#4823)
https://github.com/python/cpython/commit/d7773d92bd11640a8c950d6c36a9cef1cee36f96


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:49:39 2018
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 26 Jan 2018 15:49:39 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516981779.39.0.467229070634.issue18533@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I merged this one.  All the requirements were met.

@Terry / @ Cheryl - could you please review if I did it right?  Should this be backported to other Python versions?

----------
resolution:  -> fixed
versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:51:01 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 15:51:01 +0000
Subject: [issue32681] Fix uninitialized variable in os_dup2_impl
In-Reply-To: <1516980908.76.0.467229070634.issue32681@psf.upfronthosting.co.za>
Message-ID: <20180126154212.GA3014@xps>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Yes, you can close it, but I don't understand why there is no fix for
this warning. my issue has a small PR, but the other issue on b.p.o, I
am not really sure about my fix... I just set the 'res' variable to 0
and avoid this kind of message. Is there an other way if I want to fix
it ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:55:24 2018
From: report at bugs.python.org (pmpp)
Date: Fri, 26 Jan 2018 15:55:24 +0000
Subject: [issue32682] test_zlib improve version parsing
Message-ID: <1516982124.56.0.467229070634.issue32682@psf.upfronthosting.co.za>


New submission from pmpp <pmpp.pub at gmail.com>:

On some OS like android 4.0+, system libz.so gives funny versions number that prevent test_zlib from correctly parse it from zlib.ZLIB_RUNTIME_VERSION

https://patch-diff.githubusercontent.com/raw/vstinner/cpython/pull/1.patch

seems to fix "1.2.8-linuxfoundation-mods-v1" and "1.2.8.f-linuxfoundation-mods-v1" cases as already encountered on an popular operating system and maybe others yet unknown.

----------
components: Tests
messages: 310773
nosy: pmpp
priority: normal
severity: normal
status: open
title: test_zlib improve version parsing
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32682>
_______________________________________

From report at bugs.python.org  Fri Jan 26 11:03:00 2018
From: report at bugs.python.org (pmpp)
Date: Fri, 26 Jan 2018 16:03:00 +0000
Subject: [issue32682] test_zlib improve version parsing
In-Reply-To: <1516982124.56.0.467229070634.issue32682@psf.upfronthosting.co.za>
Message-ID: <1516982580.96.0.467229070634.issue32682@psf.upfronthosting.co.za>


Change by pmpp <pmpp.pub at gmail.com>:


----------
keywords: +patch
pull_requests: +5195
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32682>
_______________________________________

From report at bugs.python.org  Fri Jan 26 11:08:52 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 16:08:52 +0000
Subject: [issue32681] Fix uninitialized variable in os_dup2_impl
In-Reply-To: <20180126153414.GA604@xps>
Message-ID: <1516982932.74.0.467229070634.issue32681@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Fri Jan 26 11:10:58 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 16:10:58 +0000
Subject: [issue32680] smtplib SMTP instances missing a default sock attribute
In-Reply-To: <1516980686.04.0.467229070634.issue32680@psf.upfronthosting.co.za>
Message-ID: <20180126160201.GA5267@xps>


St?phane Wirtel <stephane at wirtel.be> added the comment:

You are right, but...

if there is an exception in the connect method before the init of
self.sock, the sock attribute will not exist and in this case, and only
in this case, there will be an exception in the close method.

your code will work fine if you use a try/finally but not in the case
where we use the with statement, for example.

with SMTP('myhost') as smtp:
   smtp.do_something()

If there is an exception in the __init__ of SMTP and self.sock is not
initialized -> traceback.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32680>
_______________________________________

From report at bugs.python.org  Fri Jan 26 11:24:32 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 26 Jan 2018 16:24:32 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1516983872.86.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm working on a better formulation of the __hash__ issue, so don't invest much time in this until I post my next message. I'm going to re-organize the various tables to make them easier to read.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Fri Jan 26 11:30:13 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 16:30:13 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1516983872.86.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJL3neT4cZ+Dr4aRJUB7ES4u0SixfVp7_WFkhkWLSU9AeQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Can you also clarify that this *never* looks at whether the method is
implemented in a superclass?

And clarify what happens with the __hash__ = None that's automatically
created when you define __eq__.

Please also repeat the default value of the flag in each case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Fri Jan 26 11:33:32 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 26 Jan 2018 16:33:32 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1516984412.12.0.467229070634.issue32206@psf.upfronthosting.co.za>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Fri Jan 26 11:44:31 2018
From: report at bugs.python.org (Matej Cepl)
Date: Fri, 26 Jan 2018 16:44:31 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1516985071.03.0.467229070634.issue3177@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at redhat.com>:


----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Fri Jan 26 12:06:03 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 17:06:03 +0000
Subject: [issue32677] Add.isascii() to str, bytes and bytearray
In-Reply-To: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>
Message-ID: <1516986363.59.0.467229070634.issue32677@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
title: Add str.isascii() -> Add.isascii() to str, bytes and bytearray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Fri Jan 26 12:15:18 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 26 Jan 2018 17:15:18 +0000
Subject: [issue25330] Docs for pkgutil.get_data inconsistent with semantics
In-Reply-To: <1444187174.4.0.432847594977.issue25330@psf.upfronthosting.co.za>
Message-ID: <1516986918.46.0.467229070634.issue25330@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I'm not sure if this warrants a separate issue, but I also notice this in the documentation:

> If the package cannot be located or loaded, or it uses a loader which does not support get_data, then None is returned. In particular, the loader for namespace packages does not support get_data.

But in reality this seems to raise a FileNotFoundError:


    >>> import pkgutil
    >>> data = pkgutil.get_data('dateutil.zoneinfo', 'dateutil-zoneinfo.tar.gz')
    >>> len(data)
    139671
    >>> data = pkgutil.get_data('dateutil.zoneinfo', 'foo-bar.tar.gz')
    FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/python3.6/site-packages/dateutil/zoneinfo/foo-bar.tar.gz'


Am I misunderstanding the documentation, or should the failure mode be corrected to specify that it raises an error?

----------
nosy: +p-ganssle
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25330>
_______________________________________

From report at bugs.python.org  Fri Jan 26 12:55:18 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 26 Jan 2018 17:55:18 +0000
Subject: [issue32640] Python 2.7 str.join documentation is incorrect
In-Reply-To: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>
Message-ID: <1516989318.12.0.467229070634.issue32640@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset f5e8f71fe339fe5e47c4d24ac2e5177fa3c02922 by Mariatta in branch '2.7':
[2.7] bpo-32640: Clarify the behavior of str.join and unicode object (GH-5333)
https://github.com/python/cpython/commit/f5e8f71fe339fe5e47c4d24ac2e5177fa3c02922


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Fri Jan 26 12:55:48 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 26 Jan 2018 17:55:48 +0000
Subject: [issue32640] Python 2.7 str.join documentation is incorrect
In-Reply-To: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>
Message-ID: <1516989348.61.0.467229070634.issue32640@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Fri Jan 26 13:10:03 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 26 Jan 2018 18:10:03 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1516990203.5.0.467229070634.issue32206@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks for creating this functionality. I'm so excited to use it that I've published a backport [https://pypi.org/project/backports.pdb], which seems to work for at least the basic use cases on Python 2.7+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Fri Jan 26 13:56:12 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 26 Jan 2018 18:56:12 +0000
Subject: [issue32579] UUID module fix, uuid1 python module function
In-Reply-To: <1516188845.07.0.467229070634.issue32579@psf.upfronthosting.co.za>
Message-ID: <1516992972.44.0.467229070634.issue32579@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +barry
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32579>
_______________________________________

From report at bugs.python.org  Fri Jan 26 14:04:59 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Jan 2018 19:04:59 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1516993499.98.0.467229070634.issue32493@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Fri Jan 26 14:28:39 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 19:28:39 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516994919.07.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset dba976b8a28d6e5daa66ef31a6a7c694a9193f6a by Yury Selivanov (Nathaniel J. Smith) in branch 'master':
bpo-32591: fix abort in _PyErr_WarnUnawaitedCoroutine during shutdown (#5337)
https://github.com/python/cpython/commit/dba976b8a28d6e5daa66ef31a6a7c694a9193f6a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 14:32:12 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 19:32:12 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516995132.58.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Nathaniel's latest PR looks good and fixes the crash.

FWIW losing some warnings during interpreter shutdown isn't exactly a new problem, therefore I think there's nothing wrong with the new API here.  For instance, I've seen asyncio's CoroWrapper losing warnings in the exact same fashion.

So I've merged Nathaniel's PR.  I think we can rollback the new API if we discover more problems during the beta-1 period.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 14:32:21 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 19:32:21 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516995141.81.0.467229070634.issue32591@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 14:47:53 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Jan 2018 19:47:53 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516996073.31.0.467229070634.issue18533@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5196

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Fri Jan 26 14:56:47 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 19:56:47 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516995141.83.0.714561066657.issue32591@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+koj1JPf4xwVpf9axeQyWnxMjjS+d0tU6fAGw=5O_LPA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

OK. I hope both of you keep an eye on this and actively try to test and
break it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 14:57:21 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 19:57:21 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1516996641.32.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> OK. I hope both of you keep an eye on this and actively try to test and
break it!

That's the plan!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Fri Jan 26 15:00:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 20:00:18 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1516996818.61.0.467229070634.issue18533@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for checking and merging.  In the future, we will be reminded to change '#' to 'GH-' in the title.  I only found out a couple of days ago that this is desired.

David, in msg193651, and Raymond, in msg193779, already suggested backporting.  I added the 'needs backport' tags.

The auto backport for 3.6 worked.  You might want to checked the diff as well as test results.

As I expected from the fact that Ben once did a separate 2.7 version,  the auto backport for 2.7 failed.  Ben, since you know what code changes are needed, can you prepare a backport (cherry pick) PR?

----------
assignee:  -> orsenthil
stage: patch review -> needs patch
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Fri Jan 26 15:07:07 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 20:07:07 +0000
Subject: [issue32662] Implement Server.serve_forever and corresponding APIs
In-Reply-To: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>
Message-ID: <1516997226.99.0.467229070634.issue32662@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I think these failures were on the previous version of the test; i've fixed it last night and it shouldn't timeout this way anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Fri Jan 26 15:08:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 20:08:05 +0000
Subject: [issue32571] Speed up and clean up getting optional attributes in C
 code
In-Reply-To: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>
Message-ID: <1516997285.88.0.467229070634.issue32571@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Closing this one now.  Thanks Serhiy and Inada-san!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Fri Jan 26 15:18:39 2018
From: report at bugs.python.org (Matt Ripley)
Date: Fri, 26 Jan 2018 20:18:39 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1516997919.31.0.467229070634.issue32545@psf.upfronthosting.co.za>


Matt Ripley <matt.ripley at yahoo.co.uk> added the comment:

Hi Terry, Thanks for getting back to me on this. I tried all of the suggestions on the link that you sent to me and the python installer still will not install for me. I get the same errors.
I can install the conda python distributions. I only have these installation errors with the python.org installers. Other installers (not from python.org) install without error?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Fri Jan 26 15:24:31 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 20:24:31 +0000
Subject: =?utf-8?q?=5Bissue32670=5D_Enforce_PEP_479=E2=80=94StopIteration_and_gene?=
 =?utf-8?q?rators=E2=80=94in_Python_3=2E7_by_default?=
In-Reply-To: <1516917049.09.0.467229070634.issue32670@psf.upfronthosting.co.za>
Message-ID: <1516998271.81.0.467229070634.issue32670@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 43c47fe09640c579462978ec16f81295f5857cde by Yury Selivanov in branch 'master':
bpo-32670: Enforce PEP 479. (#5327)
https://github.com/python/cpython/commit/43c47fe09640c579462978ec16f81295f5857cde


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32670>
_______________________________________

From report at bugs.python.org  Fri Jan 26 15:24:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 20:24:59 +0000
Subject: =?utf-8?q?=5Bissue32670=5D_Enforce_PEP_479=E2=80=94StopIteration_and_gene?=
 =?utf-8?q?rators=E2=80=94in_Python_3=2E7_by_default?=
In-Reply-To: <1516917049.09.0.467229070634.issue32670@psf.upfronthosting.co.za>
Message-ID: <1516998299.24.0.467229070634.issue32670@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32670>
_______________________________________

From report at bugs.python.org  Fri Jan 26 15:36:19 2018
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Jan 2018 20:36:19 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1516998979.03.0.467229070634.issue32630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Tests
-----

I ran some of my own tests (not even close to all), they seem fine.

However, I could not find any tests for the added feature (safe
use with async) though. We would be adding a new feature without
tests.


Performance
-----------

I'm getting a large slowdown:

./python Modules/_decimal/tests/bench.py

bench.py
________

patched:    [0.199, 0.206, 0.198, 0.199, 0.197, 0.202, 0.198, 0.201, 0.213, 0.199]
status-quo: [0.187, 0.184, 0.185, 0.183, 0.184, 0.188, 0.184, 0.183, 0.183, 0.185]

slowdown: > 10%


xwith.py
--------

patched:    [0.535, 0.541, 0.523]
status-quo: [0.412, 0.393, 0.375]

slowdown: > 30%



Given the performance issues I'm -1 for adding the feature at
this point.

----------
Added file: https://bugs.python.org/file47410/xwith.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:06:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 21:06:38 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517000798.83.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> However, I could not find any tests for the added feature (safe
> use with async) though. We would be adding a new feature without
> tests.

This is no problem, I can add a few async/await tests.


> I'm getting a large slowdown:
> ./python Modules/_decimal/tests/bench.py
> [..]
> patched:    [0.199, 0.206, 0.198, 0.199, 0.197, 0.202, 0.198, 0.201, 0.213, 0.199]
> status-quo: [0.187, 0.184, 0.185, 0.183, 0.184, 0.188, 0.184, 0.183, 0.183, 0.185]

I'd like you to elaborate a bit more here.  First, bench.py produces a completely different output from what you've quoted.  How exactly did you compile these results?  Are those numbers results of Pi calculation or factorial?  Can you upload the actual script you used here (if there's one)?

Second, here's my run of bench.py with contextvars and without: https://gist.github.com/1st1/1187fc58dfdef86e3cad8874e0894938

I don't see any difference, left alone 10% slowdown.


> xwith.py
> --------
>
> patched:    [0.535, 0.541, 0.523]
> status-quo: [0.412, 0.393, 0.375]

This benchmark is specially constructed to profile creating decimal contexts and doing almost nothing with them.

I've optimized PEP 567 for contextvar.get() operation, not contextvar.set (it's hard to make hamt.set() as fast as dict.set()).  That way, if you have an some decimal code that performs actual calculations with decimal objects, the operation of looking up the current context is cheap.

It's hard to imagine a situation, where a real decimal-related code just creates decimal contexts and does nothing else with them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:10:29 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 21:10:29 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
In-Reply-To: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>
Message-ID: <1517001029.36.0.467229070634.issue32611@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Win10, with 3.5.4, 3.6.4, 3.7.0a4, the pinned IDLE icons on my taskbar look normal, with the notebook and snake icon.  Running

import tkinter as tk
r = tk.Tk()

stacks the edge of a shadow icon behind the IDLE icon.  When I mouse over the pair, the tkinter icon expand to a box with tk feather icon and 'tk' on the top title line and a blank white box.  Adding

tk.Label(r, text='jsfjlskjflsjflksjflkjsflkjsfljsfljslfjfs').pack()

shrinks the window to fit the label and the expanded icon has a shrunken box also.  Everything looks normal to me.

What windows version are you using?  What exact code do you run to get the effect you describe?  Can you describe what you see better?

----------
components: +Tkinter
nosy: +serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:10:40 2018
From: report at bugs.python.org (Dan Snider)
Date: Fri, 26 Jan 2018 21:10:40 +0000
Subject: [issue32683] isinstance is calling ob.__getattribute__ as a fallback
 instead of object.__class__.__get__
Message-ID: <1517001040.56.0.467229070634.issue32683@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

It doesn't even care if the result it gets from ob.__getattribute__("__class__") isn't a type.

Surely `isinstance` is intended to do what it is named and be guaranteed to return True if an object `ob` is an instance of class `cls`. There are already ways to trick `isinstance` into thinking objects are instances of types not present in its __mro__, ie with abstract base classes. All this does is introduce the possibility of bugs.

`inspect.isclass` in particular is affected. If there's some obscure use case for breaking `isinstance` in this manner, surely it shouldn't apply to `inspect.isclass` which according to its documentation, "Return true if the object is a class."

from inspect import isclass
class Liar:
    def __getattribute__(self, attr):
        if attr == '__class__':
            return type
        return object.__getattribute__(self, attr)

>>> islcass(Liar())
True

----------
components: Interpreter Core, Library (Lib)
messages: 310793
nosy: bup
priority: normal
severity: normal
status: open
title: isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32683>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:12:40 2018
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Jan 2018 21:12:40 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1517000798.83.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <20180126211225.GA10681@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

On Fri, Jan 26, 2018 at 09:06:38PM +0000, Yury Selivanov wrote:
> This benchmark is specially constructed to profile creating decimal contexts and doing almost nothing with the

It is not constructed at all.  It was the first thing I wrote down trying
to play a bit with speed.

Even the telco benchmark (where there's a lot of other stuff going
on) slows down by around 7-8%.

I did not hunt for these benchmarks. They are the first things I tried out.  I
cannot believe that you never saw a slowdown as claimed in your OP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:17:07 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 21:17:07 +0000
Subject: [issue32613] Use PEP 397 py launcher in windows faq
In-Reply-To: <1516572429.98.0.467229070634.issue32613@psf.upfronthosting.co.za>
Message-ID: <1517001427.31.0.467229070634.issue32613@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32613>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:17:54 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 21:17:54 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <20180126211225.GA10681@bytereef.org>
Message-ID: <CAP7+vJJ+CKhTcNgNHCpr3-FNT19fYVg17UwmZpgTCAn0y_8ZQw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Guys. Please stop with the editorializing. "I cannot believe ..." (used
essentially by both of you) is not constructive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:21:40 2018
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Jan 2018 21:21:40 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517001700.84.0.467229070634.issue32630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Guido, I have the feeling that the feature -- about which I was actually
positive in the first place -- is being pushed aggressively with no
respect for the module author.

BTW, prec is changed quite frequently in decimal code, so if people
want infix notation they also have to use many with-statements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:24:37 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 21:24:37 +0000
Subject: [issue32613] Use PEP 397 py launcher in windows faq
In-Reply-To: <1516572429.98.0.467229070634.issue32613@psf.upfronthosting.co.za>
Message-ID: <1517001877.94.0.467229070634.issue32613@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am inclined to believe.  The answer to "How do I run a Python program under Windows?" should include how to use 'py'.  'python' will not work unless the install directory has been added to the path. Of course, 'py' does not work if its installation is unchecked.

The answer also has a box with a useless link (503 Service Unavailable) to a video 'Python Development on XP' that includes adding 'python' to the path.  3.5+ do not run on xp.  This should be removed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32613>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:25:01 2018
From: report at bugs.python.org (Jay Yin)
Date: Fri, 26 Jan 2018 21:25:01 +0000
Subject: [issue32446] ResourceLoader.get_data() should accept a PathLike
In-Reply-To: <1514561599.46.0.213398074469.issue32446@psf.upfronthosting.co.za>
Message-ID: <1517001901.73.0.467229070634.issue32446@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

I'm taking a look now, this looks interesting

----------
nosy: +jayyin11043

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32446>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:25:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 21:25:06 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1517001906.92.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
pull_requests: +5197

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:27:21 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 21:27:21 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1517001700.84.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ9bVeCopP=u441Y4qUso3RUkqduZgp7Ys367brq3uu6g@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Stefan, I don't think a module author should retain veto over everything
affecting their code forever. (We've had spectacular process failures with
this in the past.) Please take a deep breath and patiently answer Yury's
questions. If you two can't agree on this, the status quo wins, but it will
be a blemish on your reputation if you just block it unilaterally. At the
very least help Yury reproduce your timing results -- at this point the
burden is on you since nobody else can reproduce them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:30:55 2018
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Jan 2018 21:30:55 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517002255.71.0.467229070634.issue32630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I have run about 1000 times more decimal benchmarks than both Yury and you.  You attempt to hurt my reputation is laughable.

Show me some top-performance code that you have written.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:31:36 2018
From: report at bugs.python.org (Jay Yin)
Date: Fri, 26 Jan 2018 21:31:36 +0000
Subject: [issue32446] ResourceLoader.get_data() should accept a PathLike
In-Reply-To: <1514561599.46.0.213398074469.issue32446@psf.upfronthosting.co.za>
Message-ID: <1517002296.15.0.467229070634.issue32446@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

this would extend to set and get data right?, also would it be good to use the current get_data() (one that reads only string) function for the overloaded one and extract the string path from the os.path object? or would we want the os.path object to be handled separately?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32446>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:36:33 2018
From: report at bugs.python.org (Jay Yin)
Date: Fri, 26 Jan 2018 21:36:33 +0000
Subject: [issue32446] ResourceLoader.get_data() should accept a PathLike
In-Reply-To: <1514561599.46.0.213398074469.issue32446@psf.upfronthosting.co.za>
Message-ID: <1517002593.82.0.467229070634.issue32446@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

nvm I temporarily forgot I was working with python here, I'd need to use "is" to check what the entered "path" is huh?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32446>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:37:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 21:37:35 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517002655.98.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Sorry Stefan, I never wanted this to look like "I'm pushing this without listening to Stefan".  I apologize if it looked that way.

I ran bm_telco on my machine before submitting the PR, and I indeed did not see any performance impact.  I'll try again.  I also have a idea of a micro-optimization that might make it a tiny bit faster.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:41:19 2018
From: report at bugs.python.org (Jay Yin)
Date: Fri, 26 Jan 2018 21:41:19 +0000
Subject: [issue32446] ResourceLoader.get_data() should accept a PathLike
In-Reply-To: <1514561599.46.0.213398074469.issue32446@psf.upfronthosting.co.za>
Message-ID: <1517002879.24.0.467229070634.issue32446@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

I hope this isn't a dumb question but where is ResourceLoader.get_data() implemented, using ATOM to search the whole project and I can't seem to find it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32446>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:45:19 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 21:45:19 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1517002655.98.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+nt8JPGqiWTkMBso95D5U_nDv-mg=QtVVHuk+mr1Sq6A@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Stefan this is unacceptable abuse. Please read the code of conduct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:52:31 2018
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Jan 2018 21:52:31 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517003550.99.0.467229070634.issue32630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Yury, would you be willing to work this out by email? -- I think it
was you who I discussed the context-subclassing with and that was
quite a pleasant experience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:59:17 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 21:59:17 +0000
Subject: [issue32614] Fix documentation examples of using re with escape
 sequences
In-Reply-To: <1516574858.82.0.467229070634.issue32614@psf.upfronthosting.co.za>
Message-ID: <1517003957.73.0.467229070634.issue32614@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Definitely.  x.y code, including doc examples, should free of such warnings.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32614>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:02:44 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Jan 2018 22:02:44 +0000
Subject: [issue32675] dict.__contains__(unhashable) raises TypeError where
 False was expected
In-Reply-To: <1516963435.48.0.467229070634.issue32675@psf.upfronthosting.co.za>
Message-ID: <1517004164.12.0.467229070634.issue32675@psf.upfronthosting.co.za>


Change by R. David Murray <rdmurray at bitdance.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32675>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:04:33 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Jan 2018 22:04:33 +0000
Subject: [issue32446] ResourceLoader.get_data() should accept a PathLike
In-Reply-To: <1514561599.46.0.213398074469.issue32446@psf.upfronthosting.co.za>
Message-ID: <1517004273.09.0.467229070634.issue32446@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi Jay.  Thanks for your interest in contributing to Python!

Actually, I'm going to close this issue since we ultimately decided to deprecate the ResourceLoader ABC:

https://docs.python.org/3.7/library/importlib.html?highlight=resourceloader#importlib.abc.ResourceLoader

I'd also suggest that if you're interested in answering your questions for the curiosity, or want to contribute to Python in other areas, you should join the python-dev mailing list.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32446>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:13:17 2018
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Jan 2018 22:13:17 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517004797.78.0.467229070634.issue32630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Guido, I apologize for the outburst.  I had the impression that
msg310799 implicitly asserted my incompetence in benchmarking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:21:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 22:21:00 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1517005260.03.0.467229070634.issue32615@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I did take the code, and it would not run because of the indent.  With that fixed, it still did not run because the the indent in the quoted code fed to exec.  This does run:

import builtins
class K(dict):
    def __getitem__(self, k):
            if k not in builtins.__dict__:
                    print("get %s" % k)
            return dict.__getitem__(self, k)
    def __setitem__(self, k, v):
            print("set %s" % k)
            dict.__setitem__(self, k, v)
exec("""
foo = "bar"
foo
try:
    qyz
except NameError:
    pass
class K:
    baz = foo
    def f(ggg=foo): pass
def g(ggg=foo):
    global f
    f = 87
    f
g()
""", K())

When I run in IDLE, which execs the entire code, so none is run at module level, I get the same result.  The same is true running directly in Python after wrapping the entire code with

exec('''
# and
''')

In this case, nothing other than the outer exec is run at module level.  So I am not sure there is a bug.  If you don't get a more definitive response here, I suggest posting to python-list for opinions on whether bug or feature.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:24:08 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 26 Jan 2018 22:24:08 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517005448.12.0.467229070634.issue32630@psf.upfronthosting.co.za>


Elvis Pranskevichus <elvis at magic.io> added the comment:

FWIW, I ran bm_telco with pyperformance on a benchmark-tuned system and did not observe the slowdown.  Benchmarks were done on a release build (--enable-optimizations)

$ sudo (which python3) -m perf system tune

MASTER:

$ pyperformance run --python=envs/3.7-master-pgo-lto/prefix/bin/python3.7m --affinity=2,3 --rigorous --benchmarks=telco -o json/3.7-master.json
Python benchmark suite 0.6.1

[1/1] telco...
INFO:root:Running `/home/elvis/dev/python/performance/venv/cpython3.7-8cfe759dd297/bin/python -u /home/elvis/dev/python/performance/performance/benchmarks/bm_telco.py --rigorous --affinity=2,3 --output /tmp/tmpgszxc792`
.........................................
telco: Mean +- std dev: 9.17 ms +- 0.32 ms


MASTER + contextvars patch:

$ pyperformance run --python=envs/3.7-master-pgo+lto+decimal-contextvars/prefix/bin/python3.7m --affinity=2,3 --rigorous --benchmarks=telco -o json/3.7-contextvars.json
Python benchmark suite 0.6.1

[1/1] telco...
INFO:root:Running `/home/elvis/dev/python/performance/venv/cpython3.7-8a6fbdee5a5b/bin/python -u /home/elvis/dev/python/performance/performance/benchmarks/bm_telco.py --rigorous --affinity=2,3 --output /tmp/tmp8y4mivnp`
.........................................
telco: Mean +- std dev: 9.29 ms +- 0.19 ms


COMPARISON:

### telco ###
Mean +- std dev: 9.17 ms +- 0.32 ms -> 9.29 ms +- 0.19 ms: 1.01x slower
Not significant

----------
nosy: +Elvis.Pranskevichus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:24:54 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Jan 2018 22:24:54 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1517005494.91.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 226e50049da43097d89e9e99f9c55f212d1f7bd5 by Yury Selivanov in branch 'master':
bpo-32436: Make PyContextVar_Get a little bit faster (#5350)
https://github.com/python/cpython/commit/226e50049da43097d89e9e99f9c55f212d1f7bd5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:28:48 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Jan 2018 22:28:48 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1517005728.18.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 29a7df78277447cf6b898dfa0b1b42f8da7abc0c by Christian Heimes in branch 'master':
bpo-32521: nis libnsl (#5190)
https://github.com/python/cpython/commit/29a7df78277447cf6b898dfa0b1b42f8da7abc0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:32:23 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Jan 2018 22:32:23 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1517005943.18.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5198

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:36:07 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Jan 2018 22:36:07 +0000
Subject: [issue32683] isinstance is calling ob.__getattribute__ as a fallback
 instead of object.__class__.__get__
In-Reply-To: <1517001040.56.0.467229070634.issue32683@psf.upfronthosting.co.za>
Message-ID: <1517006167.24.0.467229070634.issue32683@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think this is a bug.  There are many ways to lie in Python.  If your object lies, it is on your head when things break :)  On the flip side, the ability to lie is very handy in many circumstances, and is often a case of duck typing rather than lying.  Unless I'm missing something, __getattribute__ is how attributes are accessed, so there would have to be a strong reason to deviate from that.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32683>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:36:35 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Jan 2018 22:36:35 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1517006195.09.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5199

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:40:55 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 26 Jan 2018 22:40:55 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517006455.38.0.467229070634.issue32630@psf.upfronthosting.co.za>


Elvis Pranskevichus <elvis at magic.io> added the comment:

Likewise, on the same builds, running _decimal/tests/bench.py does not show a significant difference: https://gist.github.com/elprans/fb31510ee28a3aa091aee3f42fe65e00

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:41:06 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 26 Jan 2018 22:41:06 +0000
Subject: [issue15115] Duplicated Content-Transfer-Encoding header when
 applying email.encoders
In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>
Message-ID: <1517006466.81.0.467229070634.issue15115@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5200
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15115>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:42:44 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 26 Jan 2018 22:42:44 +0000
Subject: [issue15115] Duplicated Content-Transfer-Encoding header when
 applying email.encoders
In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>
Message-ID: <1517006564.62.0.467229070634.issue15115@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi David, 

I've made a pull request for the way I think you wanted this documented.  Please take a look and let me know if it's even close to what you were suggesting.  Thanks!   :-)

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15115>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:52:30 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Jan 2018 22:52:30 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1517004797.78.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLRjtBOc1aecaE=Lnm5ToYuVejzrDNXLj+n4dM=_tQ3pA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Apologies accepted. I did not imply that -- I was simply stating that Yury
needed your help reproducing your result so he could do something about it.
It seems you two are taking this offline so I trust that there will be no
more barbs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 17:59:07 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 22:59:07 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1517007547.5.0.467229070634.issue32545@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Can one of the Windows experts look at the attached log?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:06:03 2018
From: report at bugs.python.org (ppperry)
Date: Fri, 26 Jan 2018 23:06:03 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1517007963.68.0.467229070634.issue32615@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

Uh, I'm not undertsanding the relevance of whether the code is run at module-level or not. It can't possibly be a feature that * some code * uses the overrides and *other code* doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:10:25 2018
From: report at bugs.python.org (pmpp)
Date: Fri, 26 Jan 2018 23:10:25 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1517008225.5.0.467229070634.issue32615@psf.upfronthosting.co.za>


Change by pmpp <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:11:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 23:11:00 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517008260.68.0.467229070634.issue32630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Since the root of the discussion is a performance regression, let me take a look since I also care of not regressing in term of performance. We (CPython core developers, as as team) spent a lot of time on optimizing CPython to make benchmarks like telco faster at each release. The good news is that Python 3.7 *is* faster than Python 3.6 on telco. If I recall correctly, it's not because of recent optimizations in the decimal module, but more general changes like CALL_METHOD optimization!

Python master vs 3.6 (normalized on 3.6):

https://speed.python.org/comparison/?exe=12%2BL%2Bmaster%2C12%2BL%2B3.6&ben=670&env=1%2C2&hor=false&bas=12%2BL%2B3.6&chart=normal+bars

Graph of telco performance on master since April 2014 to January 2017:
https://speed.python.org/timeline/#/?exe=12&ben=telco&env=1&revs=50&equid=off&quarts=on&extr=on

20.2 ms => 14.1 ms, well done!

If you are curious of reasons why Python became faster, see my documentation:
http://pyperformance.readthedocs.io/cpython_results_2017.html

Or even my talk at Pycon 2017:
https://www.youtube.com/watch?v=d65dCD3VH9Q&t=957s

Sorry, I moved off topic. Let's move back to this measuring the performance of this issue...

--

I rewrote  xwith.py using my perf module to use CPU pinning (on my isolated CPUs), automatic calibration of the number of loops, ignore the first "warmup" value, spawn 20 processes, compute the average and standard deviation, etc. => see attached xwidth2.py

Results on my laptop with 2 physical cores isolated for best benchmark stability (*):

vstinner at apu$ ./python -m perf compare_to master.json pr5278.json 
Mean +- std dev: [master] 1.86 us +- 0.03 us -> [pr5278] 2.27 us +- 0.04 us: 1.22x slower (+22%)

Note: master is the commit 29a7df78277447cf6b898dfa0b1b42f8da7abc0c and I rebased PR 5278 on top on this commit.

(*) http://perf.readthedocs.io/en/latest/run_benchmark.html#how-to-get-reproductible-benchmark-results

This is obvious the *worst* case: a *micro* benchmark using local contexts and modifying this local context. In this case, I understand that this microbenchmark basically measures the overhead of contextvars on modying a context.

The question here is if the bottleneck of applications using decimal is the code modifying the context or the code computing numbers (a+b, a*b, a/b, etc.).

Except for a few small projects, I rarely use decimal, so I'm unable to judge that.

But just to add my 2 cents, I never used "with localcontext()", I don't see the point of this tool in my short applications. I prefer to modify directly the current context (getcontext()), and only modify this context *once*, at startup. For example, set the rounding mode and set the precision, and that's all.

--

The Python benchmark suite does have a benchmark dedicated to the decimal module:
http://pyperformance.readthedocs.io/benchmarks.html#telco

I ran this benchmark on PR 5278:

vstinner at apu$ ./python -m perf compare_to telco_master.json telco_pr5278.json 
Benchmark hidden because not significant (1): telco

... not significant. Honestly, I'm not surprised at all:

* telco benchmark doesn't modify the context in the hot code, only *outside* the benchmark
* telco likely spends most of its runtime in computing numbers (sum += x; d = d.quantize(...), etc.) and converting Decimal to string. I don't know the decimal module, but I guess that it requires to *read* the current context. But getting the context is likely efficient and not significant compared to the cost of other operations.

FYI timings can be seen in verbose mode:

vstinner at apu$ ./python -m perf compare_to telco_master.json telco_pr5278.json -v
Mean +- std dev: [telco_master] 10.7 ms +- 0.4 ms -> [telco_pr5278] 10.7 ms +- 0.4 ms: 1.00x faster (-0%)
Not significant!

----------
nosy: +vstinner -Elvis.Pranskevichus
Added file: https://bugs.python.org/file47411/xwith2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:16:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 23:16:30 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517008590.46.0.467229070634.issue32630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Likewise, on the same builds, running _decimal/tests/bench.py does not show a significant difference: https://gist.github.com/elprans/fb31510ee28a3aa091aee3f42fe65e00

Note: it may be interesting to rewrite this benchmark my perf module to be able to easily check if a benchmark result is significant.

http://perf.readthedocs.io/en/latest/cli.html#perf-compare-to

"perf determines whether two samples differ significantly using a Student?s two-sample, two-tailed t-test with alpha equals to 0.95."

=> https://en.wikipedia.org/wiki/Student's_t-test


Usually, I consider that between 5% slower and 5% faster is not significant. But it depends how the benchmark was run, it depends on the type of benchmark, etc. Here I don't know bench.py so I cannot judge.

For example, for an optimization, I'm more interested by an optimization making a benchmark 10% faster ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:24:33 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 23:24:33 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1517009073.25.0.467229070634.issue32615@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I was referring back to your original a) and b) items.

Perhaps 'accidental' versus 'intentional, for whatever reason', would be the better contrast.

The weekly new issue report comes out on Fridays around noon eastern US.  I hope someone else clicks on this one.

I suggested the possibility of python-list because there would usually be people 'competing' to explain the puzzling behavior and check for obscure clauses on the reference.  In any case, some analysis would have to precede action.

----------
nosy:  -pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:50:58 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 23:50:58 +0000
Subject: [issue32616] Significant performance problems with Python 2.7 built
 with clang 3.x or 4.x
In-Reply-To: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>
Message-ID: <1517010658.88.0.467229070634.issue32616@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:53:08 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 23:53:08 +0000
Subject: [issue32621] Problem of consistence in collection.abc documentation
In-Reply-To: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za>
Message-ID: <1517010788.23.0.467229070634.issue32621@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32621>
_______________________________________

From report at bugs.python.org  Fri Jan 26 18:53:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jan 2018 23:53:42 +0000
Subject: [issue32621] Problem of consistence in collection.abc documentation
In-Reply-To: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za>
Message-ID: <1517010822.22.0.467229070634.issue32621@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32621>
_______________________________________

From report at bugs.python.org  Fri Jan 26 19:00:05 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 27 Jan 2018 00:00:05 +0000
Subject: [issue32683] isinstance is calling ob.__getattribute__ as a fallback
 instead of object.__class__.__get__
In-Reply-To: <1517001040.56.0.467229070634.issue32683@psf.upfronthosting.co.za>
Message-ID: <1517011205.23.0.467229070634.issue32683@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Dan, I don't understand what you think the code snippet shows: you're calling isclass on an object which *actually is a class* and show that it returns True. What did you expect it to return? How does the code snippet you give demonstrate a problem?

You say:

"isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__"

but why do you think that is wrong, and what makes you think that object.__class__.__get__ is the right way to do it? You seem to think it is self-evident, but it isn't (at least not to me).

"It doesn't even care if the result it gets from ob.__getattribute__("__class__") isn't a type."

Should it care?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32683>
_______________________________________

From report at bugs.python.org  Fri Jan 26 19:06:55 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jan 2018 00:06:55 +0000
Subject: [issue32626] Subscript unpacking raises SyntaxError
In-Reply-To: <1516660799.03.0.467229070634.issue32626@psf.upfronthosting.co.za>
Message-ID: <1517011615.84.0.467229070634.issue32626@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tuples often need parentheses when embedded in expressions.  So often that beginners often think that they are required.  I believe this should be closed as 'not a bug'.  I nosied the two authors of the implementation for their opinion.

----------
nosy: +Joshua.Landau, neil.g, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32626>
_______________________________________

From report at bugs.python.org  Fri Jan 26 19:11:28 2018
From: report at bugs.python.org (Ben Burrill)
Date: Sat, 27 Jan 2018 00:11:28 +0000
Subject: [issue32626] Subscript unpacking raises SyntaxError
In-Reply-To: <1516660799.03.0.467229070634.issue32626@psf.upfronthosting.co.za>
Message-ID: <1517011888.14.0.467229070634.issue32626@psf.upfronthosting.co.za>


Ben Burrill <bburrill98 at gmail.com> added the comment:

Yeah, but in this case, you don't need parentheses unless you use unpacking.  That is unexpected behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32626>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:10:10 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 27 Jan 2018 01:10:10 +0000
Subject: [issue32678] Lazy import ast in inspect
In-Reply-To: <1516969850.22.0.467229070634.issue32678@psf.upfronthosting.co.za>
Message-ID: <1517015410.79.0.467229070634.issue32678@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 37420deb80dcf0fc41a728838b0340b93ca01d90 by INADA Naoki in branch 'master':
bpo-32678: inspect: Import ast lazily (GH-5344)
https://github.com/python/cpython/commit/37420deb80dcf0fc41a728838b0340b93ca01d90


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32678>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:10:36 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 27 Jan 2018 01:10:36 +0000
Subject: [issue32678] Lazy import ast in inspect
In-Reply-To: <1516969850.22.0.467229070634.issue32678@psf.upfronthosting.co.za>
Message-ID: <1517015436.18.0.467229070634.issue32678@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32678>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:34:34 2018
From: report at bugs.python.org (Nitish)
Date: Sat, 27 Jan 2018 01:34:34 +0000
Subject: [issue32668] deepcopy() fails on ArgumentParser instances
In-Reply-To: <1516898380.94.0.467229070634.issue32668@psf.upfronthosting.co.za>
Message-ID: <1517016874.02.0.467229070634.issue32668@psf.upfronthosting.co.za>


Nitish <nitishch at protonmail.com> added the comment:

This seems to have been fixed in the latest master.

Commit I tested: 37420deb80dcf0fc41a728838b0340b93ca01d90

----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32668>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:35:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Jan 2018 01:35:37 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517016937.48.0.467229070634.issue31368@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I set the priority to release blocker to make sure that I don't forget to merge the PR before Python 3.7b1 (next monday?). The PR is *almost* ready, remaining issues are mostly related to documentation and coding style.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:39:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Jan 2018 01:39:04 +0000
Subject: [issue31368] Support asynchronous,
 non-blocking buffered reads (RWF_NONBLOCK)
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517017144.56.0.467229070634.issue31368@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Antoine Pitrou: "In any case, I think this would take the form of new low-level calls in the posix module, i.e. add thin wrappers around the new system / libc calls."

"new system / libc calls"... well, preadv() is available on FreeBSD since FreeBSD 6 :-) And preadv() and pwritev() first appeared in Linux 2.6.30; library support was added in glibc 2.10. It's not really something "new".

It seems like the two functions became more interesting for Python since Linux implemented the new RWF_NONBLOCK flag. aiofiles can be used to bypass its thread-pool, for better performances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:47:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Jan 2018 01:47:06 +0000
Subject: [issue31368] Add os.preadv() and os.pwritev()
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517017626.3.0.467229070634.issue31368@psf.upfronthosting.co.za>


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


----------
title: Support asynchronous, non-blocking buffered reads (RWF_NONBLOCK) -> Add os.preadv() and os.pwritev()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:52:18 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 27 Jan 2018 01:52:18 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1517017938.73.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I apologize for the length of this, but I want to be as precise as
possible.  I've no doubt made some mistakes, so corrections and
discussion are welcomed.

I'm adding the commented text at the end of this message to
dataclasses.py. I'm repeating it here for discussion.  These tables
are slightly different from previous versions on this issue, and I've
added line numbers to the __hash__ table to make it easier to discuss.
So any further comments and discussion should reference the tables in
this message.

I think the __init__, __repr__, __set/delattr__, __eq__, and ordering
tables are not controversial.

** hash

For __hash__, the 99.9% use case is that the default value of
hash=None is sufficient.  This is rows 1-4 of that table.  It's
unfortunate that I have to spend so much of the following text
describing cases that I think will rarely be used, but I think it's
important that in these special cases we don't do anything surprising.

**** hash=None

First, let's discuss hash=None, which is the default.  This is lines
1-4 of the __hash__ table.

Here's an example of line 1:

@dataclass(hash=None, eq=False, frozen=False)
class A:
    i: int

The user doesn't want an __eq__, and the class is not frozen.  Whether
or not the user supplied a __hash__, no hash will be added by
@dataclass.  In the absense of __hash__, the base class (in this case,
object) __hash__.  object.__hash__ and object.__eq__ are based on
object identity.

Here's an example of line 2:

@dataclass(hash=None, eq=False, frozen=True)
class A:
    i: int

This is a frozen class, where the user doesn't want an __eq__.  The
same logic is used as for line 1: no __hash__ is added.

Here's an example of line 3, "no" column (no __hash__).  Note that
this line shows the default values for hash=, eq=, frozen=:

@dataclass(hash=None, eq=True, frozen=False)
class A:
    i: int

In this case, if the user doesn't provide __hash__ (the "no" column),
we'll set __hash__=None.  That's because it's a non-frozen class with
an __eq__, it should not be hashable.

Here's an example of the line 3, "yes" column (__hash__ defined):

@dataclass(hash=None, eq=True, frozen=False)
class A:
    i: int
    def __hash__(self): pass

Since a __hash__ exists, it will not be overwritten.  Note that this
is also true if __hash__ were set to None.  We're just checking that
__hash__ exists, not it's value.

Here's an example of line 4, "no" column:

@dataclass(hash=None, eq=True, frozen=True)
class A:
    i: int

In this case the action is "add", and a __hash__ method will be
created.

And finally, consider line 4, "yes" column.  This case is hash=None,
eq=True, frozen=True.  Here we also apply the auto-hash test, just
like we do in the hash=True case (line 12, "yes" column).  We want to
make the frozen instances hashable, so we add our __hash__ method,
unless the user has directly implemented __hash__.

**** hash=False

Next, consider hash=False (rows 5-8).  In this case, @dataclass will
never add a __hash__ method, and if one exists it is not modified.

**** hash=True

Lastly, consider hash=True.  This is rows 9-12 of the __hash__ table.
The user is saying they always want a __hash__ method on the class.
If __hash__ does not already exist (the "no" column), then @dataclass
will add a __hash__ method.  If __hash__ does already exist in the
class's __dict__, @dataclass will overwrite it if and only if the
current value of __hash__ is None, and if the class has an __eq__ in
the class definition.  Let's call this condition the "auto-hash test".
The assumption is that the only reason a class has a __hash__ of None
and an __eq__ method is that the __hash__ was automatically added by
Python's class creation machinery.  And if the hash was auto-added,
then by the user specifying hash=True, they're saying they want the
__hash__ = None overridden by a generated __hash__ method.

I'll give examples from line 9 of the __hash__ table, but this
behavior is the same for rows 9-12.  Consider:

@dataclass(hash=True, eq=False, frozen=False)
class A:
    i: int
    __hash__ = None

This is line 9, "yes" column, action="add*", which says to add a
__hash__ method if the class passes the auto-hash test.  In this case
the class fails the test because it doesn't have an __eq__ in the
class definition.  __hash__ will not be overwritten.

Now consider:

@dataclass(hash=True, eq=False, frozen=False)
class A:
    i: int
    def __eq__(self, other): ...

This again is line 9, "yes" column, action="add*".  In this case, the
user is saying to add a __hash__, but it already exists because Python
automatically added __hash__=None when it created the class.  So, the
class passes the auto-hash test.  So even though there is a __hash__,
we'll overwrite it with a generated method.

Now consider:

@dataclass(hash=True, eq=False, frozen=False)
class A:
    i: int
    def __eq__(self, other): ...
    def __hash__(self): ...

Again, this is line 9, "yes" column, action="add*". The existing
__hash__ is not None, so we don't overwrite the user's __hash__
method.

Note that a class can pass the auto-hash test but not have an
auto-generated __hash__=None.  There's no way for @dataclass to
actually know that __hash__=False was auto-generated, it just assumes
that that's the case.  For example, this class passes the auth-hash
test and __hash__ will be overwritten:

@dataclass(hash=True, eq=False, frozen=False)
class A:
    i: int
    def __eq__(self, other): ...
    __hash__=None

A special case to consider is lines 11 and 12 from the table.  Here's an
example of line 11, but line 12 is the same for the purposes of this
discussion:

@dataclass(hash=True, eq=True, frozen=False)
class A:
    i: int
    __hash__=None

The class will have a generated __eq__, because eq=True.  However, the
class still fails the auto-hash test, because the class's __dict__ did
not have an __eq__ that was added by the class definition.  Instead,
it was added by @dataclass.  So this class fails the auto-hash test
and the __hash__ value will not be overwritten.


Tables follow:

# Conditions for adding methods.  The boxes indicate what action the
#  dataclass decorator takes.  For all of these tables, when I talk
#  about init=, repr=, eq=, order=, hash=, or frozen=, I'm referring
#  to the arguments to the @dataclass decorator.  When checking if a
#  dunder method already exists, I mean check for an entry in the
#  class's __dict__.  I never check to see if an attribute is defined
#  in a base class.

# Key:
# +=========+=========================================+
# + Value   | Meaning                                 |
# +=========+=========================================+
# | <blank> | No action: no method is added.          |
# +---------+-----------------------------------------+
# | add     | Generated method is added.              |
# +---------+-----------------------------------------+
# | add*    | Generated method is added only if the   |
# |         |  existing attribute is None and if the  |
# |         |  user supplied a __eq__ method in the   |
# |         |  class definition.                      |
# +---------+-----------------------------------------+
# | raise   | TypeError is raised.                    |
# +---------+-----------------------------------------+
# | None    | Attribute is set to None.               |
# +=========+=========================================+

# __init__
#
#   +--- init= parameter
#   |
#   v     |       |       |
#         |  no   |  yes  |  <--- class has __init__ in __dict__?
# +=======+=======+=======+
# | False |       |       |
# +-------+-------+-------+
# | True  | add   |       |  <- the default
# +=======+=======+=======+

# __repr__
#
#    +--- repr= parameter
#    |
#    v    |       |       |
#         |  no   |  yes  |  <--- class has __repr__ in __dict__?
# +=======+=======+=======+
# | False |       |       |
# +-------+-------+-------+
# | True  | add   |       |  <- the default
# +=======+=======+=======+


# __setattr__
# __delattr__
#
#    +--- frozen= parameter
#    |
#    v    |       |       |
#         |  no   |  yes  |  <--- class has __setattr__ or __delattr__ in __dict__?
# +=======+=======+=======+
# | False |       |       |  <- the default
# +-------+-------+-------+
# | True  | add   | raise |
# +=======+=======+=======+
# Raise because not adding these methods would break the "frozen-ness"
#  of the class.

# __eq__
#
#    +--- eq= parameter
#    |
#    v    |       |       |
#         |  no   |  yes  |  <--- class has __eq__ in __dict__?
# +=======+=======+=======+
# | False |       |       |
# +-------+-------+-------+
# | True  | add   |       |  <- the default
# +=======+=======+=======+

# __lt__
# __le__
# __gt__
# __ge__
#
#    +--- order= parameter
#    |
#    v    |       |       |
#         |  no   |  yes  |  <--- class has any comparison method in __dict__?
# +=======+=======+=======+
# | False |       |       |  <- the default
# +-------+-------+-------+
# | True  | add   | raise |
# +=======+=======+=======+
# Raise because to allow this case would interfere with using
#  functools.total_ordering.

# __hash__

#      +------------------- hash= parameter
#      |       +----------- eq= parameter
#      |       |       +--- frozen= parameter
#      |       |       |
#      v       v       v    |        |        |
#                           |   no   |  yes   |  <--- class has __hash__ in __dict__?
# +=========+=======+=======+========+========+
# | 1 None  | False | False |        |        | No __eq__, use the base class __hash__
# +---------+-------+-------+--------+--------+
# | 2 None  | False | True  |        |        | No __eq__, use the base class __hash__
# +---------+-------+-------+--------+--------+
# | 3 None  | True  | False | None   |        | <-- the default, not hashable
# +---------+-------+-------+--------+--------+
# | 4 None  | True  | True  | add    | add*   | Frozen, so hashable
# +---------+-------+-------+--------+--------+
# | 5 False | False | False |        |        |
# +---------+-------+-------+--------+--------+
# | 6 False | False | True  |        |        |
# +---------+-------+-------+--------+--------+
# | 7 False | True  | False |        |        |
# +---------+-------+-------+--------+--------+
# | 8 False | True  | True  |        |        |
# +---------+-------+-------+--------+--------+
# | 9 True  | False | False | add    | add*   | Has no __eq__, but hashable
# +---------+-------+-------+--------+--------+
# |10 True  | False | True  | add    | add*   | Has no __eq__, but hashable
# +---------+-------+-------+--------+--------+
# |11 True  | True  | False | add    | add*   | Not frozen, but hashable
# +---------+-------+-------+--------+--------+
# |12 True  | True  | True  | add    | add*   | Frozen, so hashable
# +=========+=======+=======+========+========+
# For boxes that are blank, __hash__ is untouched and therefore
#  inherited from the base class.  If the base is object, then
#  id-based hashing is used.
# Note that a class may have already __hash__=None if it specified an
#  __eq__ method in the class body (not one that was created by
#  @dataclass).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Fri Jan 26 20:53:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Jan 2018 01:53:17 +0000
Subject: [issue31368] Add os.preadv() and os.pwritev()
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517017997.76.0.467229070634.issue31368@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

FYI in 2013 I proposed to use writev() in the io module, but it was inefficient: bpo-17655.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Fri Jan 26 21:19:00 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Jan 2018 02:19:00 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1517019540.87.0.467229070634.issue32304@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset 995c60d2656c022359aac3fe713d8464c8db5716 by ?ric Araujo (Bo Bayles) in branch '3.6':
[3.6] bpo-32304: Fix distutils upload for tar files ending with b'\r' (GH-5264) (GH-5330)
https://github.com/python/cpython/commit/995c60d2656c022359aac3fe713d8464c8db5716


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Fri Jan 26 21:40:54 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Jan 2018 02:40:54 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1517020854.28.0.467229070634.issue27505@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 85527cf50a9a4eecaca4022f7c6cb9e0bae1fa5f by Nick Coghlan (Cheryl Sabella) in branch 'master':
bpo-27505: Add change notes in module attribute docs (GH-5320)
https://github.com/python/cpython/commit/85527cf50a9a4eecaca4022f7c6cb9e0bae1fa5f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Fri Jan 26 21:45:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Jan 2018 02:45:27 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1517021127.11.0.467229070634.issue27505@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 8f68cb7db37322cfeeb8338e78474e5f25d930c5 by Nick Coghlan (Cheryl Sabella) in branch '3.6':
[3.6] bpo-27505: Retrofit module __class__ documentation from 3.7 (GH-5321)
https://github.com/python/cpython/commit/8f68cb7db37322cfeeb8338e78474e5f25d930c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Fri Jan 26 21:46:59 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Jan 2018 02:46:59 +0000
Subject: [issue27505] Missing documentation for setting module __class__
 attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1517021219.0.0.467229070634.issue27505@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the PRs!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Fri Jan 26 21:58:34 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Jan 2018 02:58:34 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1517021914.24.0.467229070634.issue32513@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Eric's current proposal sounds sensible to me, but I'll note that if we deem it necessary, the code that implicitly sets `__hash__ = None` to override object.__hash__ when __eq__ is defined could also set some other marker to make it more explicit that that happened.

I think Eric's proposed heuristic will be sufficient, though - for subclasses that inherit both __hash__ and __eq__ from a base class the dataclass decorator won't pay any attention to either of them, and if a base class has set __hash__ to something, then the type creation machinery won't inject "__hash__ = None" into the class being defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Fri Jan 26 23:39:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jan 2018 04:39:19 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1517027959.48.0.467229070634.issue32664@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Agreed, like there is a bar between NameError and OSError.

The 2.7 version does not have the problem.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:03:43 2018
From: report at bugs.python.org (KINEBUCHI Tomohiko)
Date: Sat, 27 Jan 2018 05:03:43 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1517029423.7.0.467229070634.issue32664@psf.upfronthosting.co.za>


Change by KINEBUCHI Tomohiko <cocoatomo77 at gmail.com>:


----------
keywords: +patch
pull_requests: +5201
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:05:11 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jan 2018 05:05:11 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1517029511.05.0.467229070634.issue32664@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PR-1173 fixed this for 3.7, but it was not backported then.  I added a comment there.

----------
keywords:  -patch
stage: patch review -> backport needed
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:06:23 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 27 Jan 2018 05:06:23 +0000
Subject: [issue32677] Add.isascii() to str, bytes and bytearray
In-Reply-To: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>
Message-ID: <1517029583.91.0.467229070634.issue32677@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset a49ac9902903a798fab4970ccf563c531199c3f8 by INADA Naoki in branch 'master':
bpo-32677: Add .isascii() to str, bytes and bytearray (GH-5342)
https://github.com/python/cpython/commit/a49ac9902903a798fab4970ccf563c531199c3f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:09:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jan 2018 05:09:21 +0000
Subject: [issue32644] unittest.mock.call len() error
In-Reply-To: <1516776758.4.0.467229070634.issue32644@psf.upfronthosting.co.za>
Message-ID: <1517029761.58.0.467229070634.issue32644@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please either upload or include in a post a minimal testcase that reproduces the problem.  We can neither debug the problem or know if we fix it without one.

----------
nosy: +michael.foord, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32644>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:18:36 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jan 2018 05:18:36 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517030316.54.0.467229070634.issue32645@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I ran f:\dev\3x>python -m test -j5 test_asyncio test_asyncio test_asyncio test_asyncio test_asyncio on fresh Win10 build and got 
...
0:01:02 [5/5] test_asyncio passed (62 sec)
F:\dev\3x\lib\asyncio\selector_events.py:648: ResourceWarning: unclosed transport <_SelectorSocketTransport fd=620>
  source=self)
F:\dev\3x\lib\asyncio\selector_events.py:648: ResourceWarning: unclosed transport <_SelectorSocketTransport fd=896>
  source=self)
F:\dev\3x\lib\asyncio\sslproto.py:318: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x05841EE0>
  source=self)
All 5 tests OK.
(1 test also gave resource warnings.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:28:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jan 2018 05:28:00 +0000
Subject: [issue32666] Valgrind documentation seems to need updating
In-Reply-To: <1516886985.24.0.467229070634.issue32666@psf.upfronthosting.co.za>
Message-ID: <1517030880.79.0.467229070634.issue32666@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Christian or Brett, do either of you know who maintains the Valgrind stuff?  There is no listing in the Expert's index.

----------
nosy: +brett.cannon, christian.heimes, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32666>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:38:09 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 27 Jan 2018 05:38:09 +0000
Subject: [issue32677] Add.isascii() to str, bytes and bytearray
In-Reply-To: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>
Message-ID: <1517031489.31.0.467229070634.issue32677@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5202

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:38:11 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 27 Jan 2018 05:38:11 +0000
Subject: [issue32684] asyncio.gather(...,
 return_exceptions=True) swallows cancellation
Message-ID: <1517031491.22.0.467229070634.issue32684@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

Proof:

================
import asyncio

async def test():
    while True:
        print('sleeping 1')
        await asyncio.gather(asyncio.sleep(1), return_exceptions=True)

async def amain():
    print('creating task')
    qwe = asyncio.Task(test())
    print('sleeping 2')
    await asyncio.sleep(2)
    print('cancelling task')
    qwe.cancel()
    print('waiting task for completion')
    try:
        await qwe
    except Exception as e:
        print('task complete: %r', e)

loop = asyncio.get_event_loop()
loop.run_until_complete(amain())

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

This program will never complete.

This case should be either fixed, or documented.

----------
components: asyncio
messages: 310843
nosy: asvetlov, socketpair, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.gather(..., return_exceptions=True) swallows cancellation
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32684>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:38:33 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jan 2018 05:38:33 +0000
Subject: [issue32668] deepcopy() fails on ArgumentParser instances
In-Reply-To: <1516898380.94.0.467229070634.issue32668@psf.upfronthosting.co.za>
Message-ID: <1517031513.49.0.467229070634.issue32668@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Hi, you seem to be in luck, regardless of version.

Python 3.7.0a4+ (heads/master:a49ac99029, Jan 27 2018, 00:11:50) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> from copy import deepcopy
>>> parser = argparse.ArgumentParser()
>>> deepcopy(parser)
ArgumentParser(prog='', usage=None, description=None, formatter_class=<class 'argparse.HelpFormatter'>, conflict_handler='error', add_help=True)

Fresh 3.6.4+ build also runs, but without enhanced repr.
...
<class 'argparse.ArgumentParser'>

(Note: 'crash' here means segfault rather than Python exception.)

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32668>
_______________________________________

From report at bugs.python.org  Sat Jan 27 01:36:25 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Jan 2018 06:36:25 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1517034985.58.0.467229070634.issue26219@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

With the 3.7 beta deadline just around the corner, 3.8 will be the next opportunity to reconsider this idea.

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

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

From report at bugs.python.org  Sat Jan 27 02:04:29 2018
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Jan 2018 07:04:29 +0000
Subject: [issue32684] asyncio.gather(...,
 return_exceptions=True) swallows cancellation
In-Reply-To: <1517031491.22.0.467229070634.issue32684@psf.upfronthosting.co.za>
Message-ID: <1517036669.52.0.467229070634.issue32684@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 26923, but I think this problem is different.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32684>
_______________________________________

From report at bugs.python.org  Sat Jan 27 03:39:18 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 08:39:18 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1517042358.44.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 12ae40766ea39f09c2ddf6842017ee80f7f3d00b by Christian Heimes in branch '3.6':
[3.6] bpo-32521: nis libnsl (GH-5190) (#5352)
https://github.com/python/cpython/commit/12ae40766ea39f09c2ddf6842017ee80f7f3d00b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Sat Jan 27 03:39:41 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 08:39:41 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1517042381.42.0.467229070634.issue32521@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 38487a05cce32536b49dd6c89df7dc85b96eaef4 by Christian Heimes in branch '2.7':
[2.7] bpo-32521: nis libnsl (GH-5190) (#5353)
https://github.com/python/cpython/commit/38487a05cce32536b49dd6c89df7dc85b96eaef4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Sat Jan 27 03:53:46 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 08:53:46 +0000
Subject: [issue32433] Provide optimized HMAC digest
In-Reply-To: <1514401228.33.0.213398074469.issue32433@psf.upfronthosting.co.za>
Message-ID: <1517043226.87.0.467229070634.issue32433@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 2f050c7e1b36bf641e7023f7b28b451454c6b98a by Christian Heimes in branch 'master':
bpo-32433: Optimized HMAC digest (#5023)
https://github.com/python/cpython/commit/2f050c7e1b36bf641e7023f7b28b451454c6b98a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32433>
_______________________________________

From report at bugs.python.org  Sat Jan 27 03:54:15 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 08:54:15 +0000
Subject: [issue32454] Add socket.close(fd) function
In-Reply-To: <1514626643.82.0.213398074469.issue32454@psf.upfronthosting.co.za>
Message-ID: <1517043255.06.0.467229070634.issue32454@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset d0e31b980f18101738d0ec518cb991a5fb73fe93 by Christian Heimes in branch 'master':
bpo-32454: socket closefd (#5048)
https://github.com/python/cpython/commit/d0e31b980f18101738d0ec518cb991a5fb73fe93


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32454>
_______________________________________

From report at bugs.python.org  Sat Jan 27 03:57:00 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 08:57:00 +0000
Subject: [issue32521] NIS module fails to build due to the removal of
 interfaces related to Sun RPC from glibc.
In-Reply-To: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>
Message-ID: <1517043420.66.0.467229070634.issue32521@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Sat Jan 27 03:57:12 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 08:57:12 +0000
Subject: [issue32433] Provide optimized HMAC digest
In-Reply-To: <1514401228.33.0.213398074469.issue32433@psf.upfronthosting.co.za>
Message-ID: <1517043432.59.0.467229070634.issue32433@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32433>
_______________________________________

From report at bugs.python.org  Sat Jan 27 03:57:21 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 08:57:21 +0000
Subject: [issue32454] Add socket.close(fd) function
In-Reply-To: <1514626643.82.0.213398074469.issue32454@psf.upfronthosting.co.za>
Message-ID: <1517043441.9.0.467229070634.issue32454@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32454>
_______________________________________

From report at bugs.python.org  Sat Jan 27 04:48:27 2018
From: report at bugs.python.org (Ben North)
Date: Sat, 27 Jan 2018 09:48:27 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1517046507.24.0.467229070634.issue18533@psf.upfronthosting.co.za>


Change by Ben North <ben at redfrontdoor.org>:


----------
pull_requests: +5203
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Sat Jan 27 04:54:00 2018
From: report at bugs.python.org (Ben North)
Date: Sat, 27 Jan 2018 09:54:00 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1517046840.51.0.467229070634.issue18533@psf.upfronthosting.co.za>


Ben North <ben at redfrontdoor.org> added the comment:

Terry in msg310785:
> As I expected from the fact that Ben once did a separate 2.7
> version, the auto backport for 2.7 failed.  Ben, since you know what
> code changes are needed, can you prepare a backport (cherry pick)
> PR?

Yes, that's right, there were some differences between the approaches
in Py2 and Py3.  I've created PR5357 for the 2.7 backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Sat Jan 27 05:31:56 2018
From: report at bugs.python.org (Mayank Singhal)
Date: Sat, 27 Jan 2018 10:31:56 +0000
Subject: [issue32685] Erroneous suggestion in print statement
Message-ID: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>


New submission from Mayank Singhal <17mayanksinghal at gmail.com>:

The suggestion given when a for and print with the syntax for python 2.x are used together seems erroneous.

Steps to reproduce:
Just type following in the python interpreter (3.x):


for p in some_list: print p


The error produced is:

SyntaxError: Missing parentheses in call to 'print'. Did you mean print(in some_list: print p)?

I am also attaching a small file, that produces the error when run with:

python3 printBug.py

----------
components: Interpreter Core
files: printBug.py
messages: 310852
nosy: storymode7
priority: normal
severity: normal
status: open
title: Erroneous suggestion in print statement
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47412/printBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sat Jan 27 06:13:27 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 27 Jan 2018 11:13:27 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517051607.84.0.467229070634.issue32685@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Thank you for the report.  The change to the exception message was added in #30597, but it looks like it may be too greedy.  Adding the developer to the nosy list.

----------
nosy: +CuriousLearner, csabella, ncoghlan
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sat Jan 27 06:14:58 2018
From: report at bugs.python.org (Minion Jim)
Date: Sat, 27 Jan 2018 11:14:58 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
In-Reply-To: <1517001029.36.0.467229070634.issue32611@psf.upfronthosting.co.za>
Message-ID: <1517051697668.9919@ranelagh.bracknell-forest.sch.uk>


Minion Jim <epaine13 at ranelagh.bracknell-forest.sch.uk> added the comment:

Hi, thanks for your email. I hope to get round to sending you a screenshot by the end of today but I am quite busy right now.

Many thanks,
Elisha
________________________________
 Elisha Paine
Ranelagh School

Confidentiality and Disclaimer: This email and its attachments are intended for the addressee only and may be confidential or the subject of legal privilege. The views expressed in this email are those of the individual and not necessarily the views or opinions of Ranelagh School. If this email and its attachments have come to you in error you must notify the school network manager, and immediately delete them. Email: administrator at ranelagh.bracknell-forest.sch.uk. You should not copy, distribute or show them to anyone else. This email and any attached files have been scanned for the presence of computer viruses. However, you are advised that you open any attachments at your own risk. Please note that electronic mail may be monitored in accordance with the Telecommunications (Lawful Business Practices) (Interception of Communications) Regulations 2000

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Sat Jan 27 06:20:50 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Sat, 27 Jan 2018 11:20:50 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517052050.43.0.467229070634.issue32685@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Thanks for the report Mayank!

As we discussed offline, it is indeed reproducible if someone uses `print` on the same line (such as in this case, where a loop is used).

I will look into this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sat Jan 27 07:34:33 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 12:34:33 +0000
Subject: [issue31853] Use super().method instead of socket.method in SSLSocket
In-Reply-To: <1508790377.43.0.213398074469.issue31853@psf.upfronthosting.co.za>
Message-ID: <1517056473.49.0.467229070634.issue31853@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 746cc75541f31278864a10b995e7d009bd2ff053 by Christian Heimes (Mads Jensen) in branch 'master':
bpo-31853: Replaced socket.method calls with super() in SSLSocket. (#4048)
https://github.com/python/cpython/commit/746cc75541f31278864a10b995e7d009bd2ff053


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Sat Jan 27 07:35:05 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 12:35:05 +0000
Subject: [issue31853] Use super().method instead of socket.method in SSLSocket
In-Reply-To: <1508790377.43.0.213398074469.issue31853@psf.upfronthosting.co.za>
Message-ID: <1517056505.38.0.467229070634.issue31853@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Sat Jan 27 08:20:04 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Jan 2018 13:20:04 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517059204.27.0.467229070634.issue32685@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Re-reading the code for _set_legacy_print_statement_msg, I noticed that we're not currently taking the "start" parameter into account, and that's the offset the compiler passes in to tell us where on the line it found the text "print ". Oops :)

We're also currently going to mishandle code like "x = 1; print x; pass" as well: the suggestion for that is "print(x)", but we would currently suggest "print(print x; pass)".

Fixing the left offset shouldn't be too difficult, as I believe the correct value for that is just "PRINT_OFFSET + start".

For the right offset, I think we'll want to drop the initial XStrip call added for bpo-32028 entirely, and instead calculate the right offset as a PyUnicode_FindChar search for ";" (replacing it with the length of the input string if the separator isn't found).

Any trailing whitespace (either before the ";", if one is present, or before the end of the line otherwise) will then be stripped by the remaining XStrip call (the one after the PyUnicode_Substring call).

(Even with those improvements, there will still be cases where the heuristic gives an incorrect suggestion due to a syntax error within the expression to be displayed, like "print value:", but there isn't anything simple we can do about those short of trying to compile the calculated suggestion, and I'm not prepared to go that far yet)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sat Jan 27 08:46:56 2018
From: report at bugs.python.org (7stud)
Date: Sat, 27 Jan 2018 13:46:56 +0000
Subject: [issue32686] python3.6.4 install hangs
Message-ID: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>


New submission from 7stud <7stud at excite.com>:

I tried to install python3.6.4 on OSX 10.13.2.  I followed the Build Instructions in the README.rst:

    ./configure
    make
    make test
    sudo make install

After ./configure step, the end of the output said:

---
If you want a release build with all stable optimizations active (PGO, etc),
please run ./configure --enable-optimizations
---

So I did:

~/Downloads/Python-3.6.4$ ./configure --enable-optimizations

Next, I did:

~/Downloads/Python-3.6.4$ make

But the make step always hangs on the line:
       
      ...
      ...
      0:00:18 load avg: 2.10 [ 23/406] test_asyncgen
      0:00:19 load avg: 2.10 [ 24/406] test_asynchat
      0:00:21 load avg: 2.01 [ 25/406] test_asyncio


During the make step, OSX prompts me whether to allow incoming connections.  I've tried it both ways: Deny and Allow, but the install allows hangs on the test_asyncio line.  I hit Ctrl+C to quit the install.  One time, I waited over an hour and the install was still hanging.

----------
components: asyncio
messages: 310858
nosy: 7stud, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: python3.6.4 install hangs
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Sat Jan 27 08:49:29 2018
From: report at bugs.python.org (7stud)
Date: Sat, 27 Jan 2018 13:49:29 +0000
Subject: [issue32686] python3.6.4 install hangs
In-Reply-To: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>
Message-ID: <1517060969.58.0.467229070634.issue32686@psf.upfronthosting.co.za>


7stud <7stud at excite.com> added the comment:

Oh, yeah, I'm using Python-3.6.4.tgz for the install.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Sat Jan 27 08:53:00 2018
From: report at bugs.python.org (7stud)
Date: Sat, 27 Jan 2018 13:53:00 +0000
Subject: [issue32686] python3.6.4 install hangs
In-Reply-To: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>
Message-ID: <1517061180.37.0.467229070634.issue32686@psf.upfronthosting.co.za>


7stud <7stud at excite.com> added the comment:

My os is OSX 10.13.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Sat Jan 27 09:34:05 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 14:34:05 +0000
Subject: [issue32532] improve sys.settrace and sys.setprofile documentation
In-Reply-To: <1515651956.68.0.467229070634.issue32532@psf.upfronthosting.co.za>
Message-ID: <1517063645.79.0.467229070634.issue32532@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +patch
pull_requests: +5204
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32532>
_______________________________________

From report at bugs.python.org  Sat Jan 27 09:39:56 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Jan 2018 14:39:56 +0000
Subject: [issue32686] python3.6.4 build with --enable-optimzations hangs on
 macOS 10.13
In-Reply-To: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>
Message-ID: <1517063996.35.0.467229070634.issue32686@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

That sounds like the problem documented in Issue32517.  As a temporary workaround, try building without using --enable-optimazations.

----------
nosy: +ned.deily
title: python3.6.4 install hangs -> python3.6.4 build with --enable-optimzations hangs on macOS 10.13

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Sat Jan 27 09:51:41 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Jan 2018 14:51:41 +0000
Subject: [issue31399] Let OpenSSL verify hostname and IP address
In-Reply-To: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
Message-ID: <1517064701.04.0.467229070634.issue31399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 61d478c71c5341cdc54e6bfb4ace4252852fd972 by Christian Heimes in branch 'master':
bpo-31399: Let OpenSSL verify hostname and IP address (#3462)
https://github.com/python/cpython/commit/61d478c71c5341cdc54e6bfb4ace4252852fd972


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31399>
_______________________________________

From report at bugs.python.org  Sat Jan 27 10:04:49 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 15:04:49 +0000
Subject: [issue32532] improve sys.settrace and sys.setprofile documentation
In-Reply-To: <1515651956.68.0.467229070634.issue32532@psf.upfronthosting.co.za>
Message-ID: <1517065489.19.0.467229070634.issue32532@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 60da99b8e2f7bf497569ae4d6c218866575729bf by Xiang Zhang in branch 'master':
bpo-32532: Improve documentation of settrace and setprofile (#5359)
https://github.com/python/cpython/commit/60da99b8e2f7bf497569ae4d6c218866575729bf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32532>
_______________________________________

From report at bugs.python.org  Sat Jan 27 10:05:37 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 15:05:37 +0000
Subject: [issue32532] improve sys.settrace and sys.setprofile documentation
In-Reply-To: <1515651956.68.0.467229070634.issue32532@psf.upfronthosting.co.za>
Message-ID: <1517065537.42.0.467229070634.issue32532@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32532>
_______________________________________

From report at bugs.python.org  Sat Jan 27 10:09:06 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Jan 2018 15:09:06 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1517008260.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <20180127150853.GA2678@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

On Fri, Jan 26, 2018 at 11:11:00PM +0000, STINNER Victor wrote:
> vstinner at apu$ ./python -m perf compare_to master.json pr5278.json 
> Mean +- std dev: [master] 1.86 us +- 0.03 us -> [pr5278] 2.27 us +- 0.04 us: 1.22x slower (+22%)
> 
> Note: master is the commit 29a7df78277447cf6b898dfa0b1b42f8da7abc0c and I rebased PR 5278 on top on this commit.

Thank you and Elvis for running the benchmarks. Yes, the exact version does seem
important -- I have been getting some differences based on the checkout.

> This is obvious the *worst* case: a *micro* benchmark using local contexts and modifying this local context. In this case, I understand that this microbenchmark basically measures the overhead of contextvars on modying a context.
> 
> The question here is if the bottleneck of applications using decimal is the code modifying the context or the code computing numbers (a+b, a*b, a/b, etc.).

Yes, that's the big question. In the generator discussions people were advised
to use "with" whenever possible, so I assume short blocks *will* be used.

I would use the context functions, which would not require PEP-567 at all.
This means that I'm somewhat okay with excessive with-statements being a
bit slower.

> vstinner at apu$ ./python -m perf compare_to telco_master.json telco_pr5278.json -v
> Mean +- std dev: [telco_master] 10.7 ms +- 0.4 ms -> [telco_pr5278] 10.7 ms +- 0.4 ms: 1.00x faster (-0%)
> Not significant!

Okay. In my above reference to telco, I ran the "telco.py full" command
from http://www.bytereef.org/mpdecimal/quickstart.html#telco-benchmark .

The numbers I posted weren't cooked, but I have a hard time reproducing
them myself now consistently with the latest revisions, so let's declare
telco.py and bench.py a tie.

This means that I no longer have any objections, so Yury, please go ahead
and merge the PR!

Stefan Krah

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Sat Jan 27 10:09:52 2018
From: report at bugs.python.org (ppperry)
Date: Sat, 27 Jan 2018 15:09:52 +0000
Subject: [issue32621] Problem of consistency in collection.abc documentation
In-Reply-To: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za>
Message-ID: <1517065792.71.0.467229070634.issue32621@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: Problem of consistence in collection.abc documentation -> Problem of consistency in collection.abc documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32621>
_______________________________________

From report at bugs.python.org  Sat Jan 27 10:39:23 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 15:39:23 +0000
Subject: [issue32649] complete C API doc debug and profile part with new
 PyTrace_OPCODE
In-Reply-To: <1516798950.57.0.467229070634.issue32649@psf.upfronthosting.co.za>
Message-ID: <1517067563.18.0.467229070634.issue32649@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +patch
pull_requests: +5205
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32649>
_______________________________________

From report at bugs.python.org  Sat Jan 27 10:58:19 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 15:58:19 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
Message-ID: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

The meaning of arg for PyTrace_Line and PyTrace_CALL is wrong, it is not always NULL but always Py_None.

----------
assignee: docs at python
components: Documentation
messages: 310865
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: wrong meaning of arg in Py_tracefunc doc
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:03:53 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 16:03:53 +0000
Subject: [issue32688] weird comment out line of code
Message-ID: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

I find one line[1] is weirdly commented out. But I don't think profile here is any different with trace. In 2.7, this line is not commented out and the change happens in b94767ff, fixing clang warnings.

----------
messages: 310866
nosy: brett.cannon, xiang.zhang
priority: normal
severity: normal
status: open
title: weird comment out line of code
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:10:38 2018
From: report at bugs.python.org (William Pickard)
Date: Sat, 27 Jan 2018 16:10:38 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1517069438.32.0.467229070634.issue25095@psf.upfronthosting.co.za>


William Pickard <lollol222gg at gmail.com> added the comment:

Ok, I found another way to apply the solution to this issue, that is by adding the "Connection" header (with value of "close") to the client's request instead of the server's response.

I'm going to use this other method as the client is expected to expect the server to shutdown the connection (as it asked the server to).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:12:40 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 16:12:40 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <1517069560.1.0.467229070634.issue32688@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Sorry, forget links, it's https://github.com/python/cpython/blob/master/Python/ceval.c#L3528 , and the commit is b94767ff44edf5d461d7cb1c8eb5160f83886358.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:16:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Jan 2018 16:16:39 +0000
Subject: [issue31368] Add os.preadv() and os.pwritev()
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517069799.33.0.467229070634.issue31368@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 4defba3b95ec0f52ce75b8466831d30fb5d333f3 by Victor Stinner (Pablo Galindo) in branch 'master':
bpo-31368: Expose preadv and pwritev in the os module (#5239)
https://github.com/python/cpython/commit/4defba3b95ec0f52ce75b8466831d30fb5d333f3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:29:45 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 16:29:45 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
In-Reply-To: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>
Message-ID: <1517070585.37.0.467229070634.issue32687@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +patch
pull_requests: +5206
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:32:34 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 27 Jan 2018 16:32:34 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1517021914.24.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJwqC6TXwsvXe-Yay9nAmhHGxKv1Qcz1fVab+89xHCBJg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

If Nick says it's okay it is okay. I think it's okay too but my brain
doesn't want to start up today -- I suggest not waiting for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:36:15 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 27 Jan 2018 16:36:15 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1517070975.44.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm completely burned out on it, too. I'll get the code checked in today, then update the PEP later. I don't really want to add all of this reasoning to the PEP, but I guess I should.

I think the gist of it is correct, in any event. We can fix some corner cases during the betas, if need be.

Thanks Guido and Nick for looking at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sat Jan 27 12:34:35 2018
From: report at bugs.python.org (Minion Jim)
Date: Sat, 27 Jan 2018 17:34:35 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
In-Reply-To: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>
Message-ID: <1517074475.84.0.467229070634.issue32611@psf.upfronthosting.co.za>


Minion Jim <epaine13 at ranelagh.bracknell-forest.sch.uk> added the comment:

Please see the attached gif for a demonstration (I am using Windows 10 Home)

----------
Added file: https://bugs.python.org/file47413/tkinter glitch.gif

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:00:26 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 18:00:26 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1517076026.46.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
pull_requests: +5207

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:24:22 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 18:24:22 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1517077462.66.0.467229070634.issue32436@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset bc4123b0b380edda774b8bff2fa1bcc96453b440 by Yury Selivanov in branch 'master':
bpo-32436: Use PyThreadState_GET() in all hot paths (GH-5363)
https://github.com/python/cpython/commit/bc4123b0b380edda774b8bff2fa1bcc96453b440


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:31:22 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 27 Jan 2018 18:31:22 +0000
Subject: [issue8881] socket.getaddrinfo() should return named tuples
In-Reply-To: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>
Message-ID: <1517077882.6.0.467229070634.issue8881@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

This one looks to be partly done due to #18720 and enums.

>>> for item in socket.getaddrinfo(None, 0):
...     print(item)
... 
(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('::1', 0, 0, 0))
(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('::1', 0, 0, 0))
(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_RAW: 3>, 0, '', ('::1', 0, 0, 0))
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('127.0.0.1', 0))
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('127.0.0.1', 0))
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_RAW: 3>, 0, '', ('127.0.0.1', 0))

Is there a reason that Protocols weren't converted to be enums?  I added quick code to socket.py and it turned the above into:

(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_STREAM: 1>, <Protocol.IPPROTO_TCP: 6>, '', ('::1', 0, 0, 0))
(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, <Protocol.IPPROTO_UDP: 17>, '', ('::1', 0, 0, 0))
(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_RAW: 3>, <Protocol.IPPROTO_HOPOPTS: 0>, '', ('::1', 0, 0, 0))
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, <Protocol.IPPROTO_TCP: 6>, '', ('127.0.0.1', 0))
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, <Protocol.IPPROTO_UDP: 17>, '', ('127.0.0.1', 0))
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_RAW: 3>, <Protocol.IPPROTO_HOPOPTS: 0>, '', ('127.0.0.1', 0))

Would that be a responsible change to include?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8881>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:46:03 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 18:46:03 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517078763.12.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thank you, Stefan.  I've updated the PR with an asyncio+decimal test and run tests in refleak mode to make sure there's no regression there.

If during the beta/rc period we see that contextvars isn't stable enough or something I'll revert this change before 3.7.0 myself, so that decimal users will not be disturbed.

I'll merge the PR once the CI is green.

> Yes, that's the big question. In the generator discussions people were advised to use "with" whenever possible, so I assume short blocks *will* be used.

Yes, I used decimal examples all the time to showcase how context is supposed to work with generators.  Most of those examples were specifically constructed to illustrate some point, but I don't think that real-world code uses a 'with localcontext()' statement in every function.

Unfortunately there's no way (at least known to me) to make 'ContextVar.set()' faster than it is now.  I use HAMT which guarantees that all set operations will have O(log n) performance; the other known approach is to use copy-on-write (as in .NET), but that has an O(n) ContextVar.set() performance.  So I guess a slightly slower 'with localcontext()' is the price to pay to make decimal easier to use for async/await code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:46:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 18:46:48 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517078808.97.0.467229070634.issue32630@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset f13f12d8daa587b5fcc66fe3ed1090a5dadab289 by Yury Selivanov in branch 'master':
bpo-32630: Use contextvars in decimal (GH-5278)
https://github.com/python/cpython/commit/f13f12d8daa587b5fcc66fe3ed1090a5dadab289


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:47:18 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 18:47:18 +0000
Subject: [issue32630] Migrate decimal to use PEP 567 context variables
In-Reply-To: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>
Message-ID: <1517078838.06.0.467229070634.issue32630@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:50:59 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 27 Jan 2018 18:50:59 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <1517079059.83.0.467229070634.issue32688@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't remember why that line was commented out to make the analyzer happy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:51:38 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 27 Jan 2018 18:51:38 +0000
Subject: [issue32666] Valgrind documentation seems to need updating
In-Reply-To: <1516886985.24.0.467229070634.issue32666@psf.upfronthosting.co.za>
Message-ID: <1517079098.31.0.467229070634.issue32666@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't think there is anyone specific who maintains it. Just whomever wants to use it next and needs to fix it to make it work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32666>
_______________________________________

From report at bugs.python.org  Sat Jan 27 13:53:45 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 27 Jan 2018 18:53:45 +0000
Subject: [issue25330] Docs for pkgutil.get_data inconsistent with semantics
In-Reply-To: <1444187174.4.0.432847594977.issue25330@psf.upfronthosting.co.za>
Message-ID: <1517079225.81.0.467229070634.issue25330@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Notice that the returning of None only has to do with searching for the *package*, not the *data file*. So I think the docs are still correct according to your example, Paul.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25330>
_______________________________________

From report at bugs.python.org  Sat Jan 27 14:22:49 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 27 Jan 2018 19:22:49 +0000
Subject: [issue32622] Implement loop.sendfile
Message-ID: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:


New changeset 7c684073f951dd891021676ecfd86ffc18b8895e by Andrew Svetlov in branch 'master':
bpo-32622: Implement loop.sendfile() (#5271)
https://github.com/python/cpython/commit/7c684073f951dd891021676ecfd86ffc18b8895e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 14:22:50 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Sat, 27 Jan 2018 19:22:50 +0000
Subject: [issue31368] Add os.preadv() and os.pwritev()
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517080970.13.0.467229070634.issue31368@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

Thank you Pablo Galindo for your amazingly hard work. Also Victor Stinner for your guidance, thanks you :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Sat Jan 27 14:34:36 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Jan 2018 19:34:36 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1517081676.17.0.467229070634.issue32206@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Adopting the backport, I believe I've found a defect. I filed the defect with the backport as [backports.pdb 1](https://github.com/jaraco/backports.pdb/issues/1).

Essentially, the issue is that `__package__` gets set to the module name instead of the package name, causing issues with `from .mod` imports.

Feel free to take the relevant parts of the fix in the backport to adjust the implementation here, and definitely let me know if you think the adjustment I've made is somehow incorrect.

Full disclosure, I have not tested the canonical implementation in Python 3.7, only the backport in Python 3.6 and 2.7.

Please let me know if you would like me to file a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sat Jan 27 14:38:22 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sat, 27 Jan 2018 19:38:22 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1517081902.74.0.467229070634.issue32206@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Hi Jason, thanks a lot! 

I?ll have a look to the bug you reported on Monday. Out for holidays atm ^^

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sat Jan 27 14:49:51 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 27 Jan 2018 19:49:51 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1517082591.92.0.467229070634.issue17044@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Since PEP 422 was withdrawn in favor of PEP 487, should this issue be closed?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sat Jan 27 14:53:40 2018
From: report at bugs.python.org (William Pickard)
Date: Sat, 27 Jan 2018 19:53:40 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1517082820.23.0.467229070634.issue25095@psf.upfronthosting.co.za>


William Pickard <lollol222gg at gmail.com> added the comment:

Alright, the PR is ready for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Sat Jan 27 15:03:47 2018
From: report at bugs.python.org (ppperry)
Date: Sat, 27 Jan 2018 20:03:47 +0000
Subject: [issue17852] Built-in module _io can lose data from buffered files in
 reference cycles
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1517083427.33.0.467229070634.issue17852@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: Built-in module _io can lose data from buffered files at exit -> Built-in module _io can lose data from buffered files in reference cycles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Sat Jan 27 15:11:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 20:11:41 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517083901.5.0.467229070634.issue32622@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 15:33:14 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 20:33:14 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517085194.59.0.467229070634.issue32622@psf.upfronthosting.co.za>


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


----------
pull_requests: +5208

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 15:50:30 2018
From: report at bugs.python.org (Neil Girdhar)
Date: Sat, 27 Jan 2018 20:50:30 +0000
Subject: [issue32626] Subscript unpacking raises SyntaxError
In-Reply-To: <1516660799.03.0.467229070634.issue32626@psf.upfronthosting.co.za>
Message-ID: <1517086230.21.0.467229070634.issue32626@psf.upfronthosting.co.za>


Neil Girdhar <mistersheik at gmail.com> added the comment:

This came up already on python-ideas: https://groups.google.com/forum/#!topic/python-ideas/YOpT9fDQyFk

I think this was an oversight, and I'm with Ben that it's unexpected.  That said, this is usually the kind of thing that Guido likes to comment on.  My suggestion is to first check to see if you can change the grammar, and then ask Guido what he thinks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32626>
_______________________________________

From report at bugs.python.org  Sat Jan 27 15:52:54 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 20:52:54 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517086374.27.0.467229070634.issue32622@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b1a6ac4c4026d648b3d948945b734a4d0f175a3c by Yury Selivanov in branch 'master':
bpo-32622: Enforce sendfile fallback policy for FALLBACK transports (#5364)
https://github.com/python/cpython/commit/b1a6ac4c4026d648b3d948945b734a4d0f175a3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 15:59:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 27 Jan 2018 20:59:22 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1517086762.89.0.467229070634.issue32513@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5209

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sat Jan 27 16:04:37 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 27 Jan 2018 21:04:37 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517087077.41.0.467229070634.issue32622@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +5210

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 16:33:22 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Sat, 27 Jan 2018 21:33:22 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517088802.87.0.467229070634.issue32622@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
pull_requests: +5211

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 16:34:12 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Jan 2018 21:34:12 +0000
Subject: [issue32665] pathlib.Path._from_parsed_parts should call
 cls.__new__(cls)
In-Reply-To: <1516883245.2.0.467229070634.issue32665@psf.upfronthosting.co.za>
Message-ID: <1517088852.48.0.467229070634.issue32665@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This behaviour is because "parent" descriptor ends calling:

    @classmethod
    def _from_parsed_parts(cls, drv, root, parts, init=True):
        self = object.__new__(cls)
        self._drv = drv
        self._root = root
        self._parts = parts
        if init:
            self._init()
        return self

and this calls object.__new__ and this call raises AttributeError: new_attr. Notice that object.__new__(cls) will not raise as this snippet shows:

   >>>: class A:
   ...:     def __new__(*args):
   ...:         raise ZeroDivisionError()
   ...:

>>> A()
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
<python> in <module>()
----> 1 A()

<python> in __new__(*args)
      1 class A:
      2     def __new__(*args):
----> 3         raise ZeroDivisionError()
      4

ZeroDivisionError:

>>> object.__new__(A)
>>> <__main__.A at 0x7f6239c17860>

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32665>
_______________________________________

From report at bugs.python.org  Sat Jan 27 16:35:11 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Jan 2018 21:35:11 +0000
Subject: [issue32665] pathlib.Path._from_parsed_parts should call
 cls.__new__(cls)
In-Reply-To: <1516883245.2.0.467229070634.issue32665@psf.upfronthosting.co.za>
Message-ID: <1517088911.18.0.467229070634.issue32665@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Sorry, the exception of object.__new__(cls) is AttributeError: _drv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32665>
_______________________________________

From report at bugs.python.org  Sat Jan 27 16:38:03 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 27 Jan 2018 21:38:03 +0000
Subject: [issue32665] pathlib.Path._from_parsed_parts should call
 cls.__new__(cls)
In-Reply-To: <1516883245.2.0.467229070634.issue32665@psf.upfronthosting.co.za>
Message-ID: <1517089083.78.0.467229070634.issue32665@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Antoine, is the reason of calling object.__new__(cls) in `_from_parsed_parts` that the code does not raise on creation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32665>
_______________________________________

From report at bugs.python.org  Sat Jan 27 16:52:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 21:52:37 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517089957.33.0.467229070634.issue32622@psf.upfronthosting.co.za>


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


----------
pull_requests: +5212

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:04:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Jan 2018 22:04:13 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517090653.93.0.467229070634.issue32622@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

s390x Debian 3.x buildbot failed:
http://buildbot.python.org/all/#/builders/13/builds/601

Exmaple:

======================================================================
ERROR: test_sendfile_ssl_pre_and_post_data (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_events.py", line 2277, in test_sendfile_ssl_pre_and_post_data
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:04:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 22:04:44 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517090684.14.0.467229070634.issue32622@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> AttributeError: 'NoneType' object has no attribute 'SSLContext'

We've just pushed a fix for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:11:12 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 22:11:12 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517091072.58.0.467229070634.issue32622@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset ee72ac0683e685b134f67cb0c6612c664ecadb65 by Yury Selivanov (Elvis Pranskevichus) in branch 'master':
bpo-32622: Fix AbstractEventLoop.sendfile signature in documentation. (GH-5368)
https://github.com/python/cpython/commit/ee72ac0683e685b134f67cb0c6612c664ecadb65


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:20:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 22:20:53 +0000
Subject: [issue32221] Converting ipv6 address to string representation using
 getnameinfo() is wrong.
In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>
Message-ID: <1517091653.15.0.467229070634.issue32221@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 47c0b1f7d4115e6f15e6776c1f91d28e7d96fe0c by Yury Selivanov (????????? ????) in branch 'master':
bpo-32221: makeipaddr(): remove interface part + speedup (GH-4724)
https://github.com/python/cpython/commit/47c0b1f7d4115e6f15e6776c1f91d28e7d96fe0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:21:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 22:21:37 +0000
Subject: [issue32221] Converting ipv6 address to string representation using
 getnameinfo() is wrong.
In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>
Message-ID: <1517091697.75.0.467229070634.issue32221@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Merged.  Thanks, Mark!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:22:03 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 22:22:03 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517091723.49.0.467229070634.issue32622@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 2a2247ce5e1984eb2f2c41b269b38dbb795a60cf by Yury Selivanov in branch 'master':
bpo-32622: Normalize ENOTCONN to ConnectionError on macOS (GH-5369)
https://github.com/python/cpython/commit/2a2247ce5e1984eb2f2c41b269b38dbb795a60cf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:44:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 22:44:53 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517093093.45.0.467229070634.issue32622@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I think we've fixed everything. Closing this for now, Victor please reopen if buildbots misbehave.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Sat Jan 27 17:45:52 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 27 Jan 2018 22:45:52 +0000
Subject: [issue32436] Implement PEP 567
In-Reply-To: <1516666281.22.0.467229070634.issue32436@psf.upfronthosting.co.za>
Message-ID: <1517093152.14.0.467229070634.issue32436@psf.upfronthosting.co.za>


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


----------
pull_requests: +5213

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32436>
_______________________________________

From report at bugs.python.org  Sat Jan 27 18:14:40 2018
From: report at bugs.python.org (Philippe)
Date: Sat, 27 Jan 2018 23:14:40 +0000
Subject: [issue30670] pprint for dict in sorted order or insert order?
In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za>
Message-ID: <1517094879.99.0.467229070634.issue30670@psf.upfronthosting.co.za>


Philippe <pombredanne at gmail.com> added the comment:

IMHO since Guido said that dictionary order is guaranteed going forward [1], the order should now be preserved in 3.6+ 

Getting a sorted pprint'ed dict in a Py3.6.1 was a surprise to me coming from Python2.

The default ordered dict is to me the killer feature of 3 and a major driver to migrate from 2.

[1] https://mail.python.org/pipermail/python-dev/2017-December/151286.html

----------
nosy: +pombreda

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30670>
_______________________________________

From report at bugs.python.org  Sat Jan 27 18:49:50 2018
From: report at bugs.python.org (Nitish)
Date: Sat, 27 Jan 2018 23:49:50 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517096990.03.0.467229070634.issue32685@psf.upfronthosting.co.za>


Nitish <nitishch at protonmail.com> added the comment:

> For the right offset, I think we'll want to drop the initial XStrip call added for bpo-32028 entirely, and instead calculate the right offset as a PyUnicode_FindChar search for ";" (replacing it with the length of the input string if the separator isn't found).

Are ';' and whitespace the only allowed characters following the print expression?

----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sat Jan 27 19:01:24 2018
From: report at bugs.python.org (Craig Holmquist)
Date: Sun, 28 Jan 2018 00:01:24 +0000
Subject: [issue32689] shutil.move raises AttributeError if first argument is a
 pathlib.Path object and destination is a directory
Message-ID: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>


New submission from Craig Holmquist <craigholm at gmail.com>:

>>> import os, pathlib, shutil
>>> os.mkdir('test1')
>>> os.mkdir('test2')
>>> path = pathlib.Path('test1')
>>> shutil.move(path, 'test2')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/shutil.py", line 540, in move
    real_dst = os.path.join(dst, _basename(src))
  File "/usr/lib/python3.6/shutil.py", line 504, in _basename
    return os.path.basename(path.rstrip(sep))
AttributeError: 'PosixPath' object has no attribute 'rstrip'

----------
components: Library (Lib)
messages: 310900
nosy: craigh
priority: normal
severity: normal
status: open
title: shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Sat Jan 27 19:07:42 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Jan 2018 00:07:42 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1517098062.28.0.467229070634.issue32513@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset ea8fc52e75363276db23c6a8d7a689f79efce4f9 by Eric V. Smith in branch 'master':
bpo-32513: Make it easier to override dunders in dataclasses. (GH-5366)
https://github.com/python/cpython/commit/ea8fc52e75363276db23c6a8d7a689f79efce4f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sat Jan 27 19:09:26 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Jan 2018 00:09:26 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1517098166.56.0.467229070634.issue32513@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sat Jan 27 19:59:15 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 28 Jan 2018 00:59:15 +0000
Subject: [issue32677] Add.isascii() to str, bytes and bytearray
In-Reply-To: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>
Message-ID: <1517101155.23.0.467229070634.issue32677@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset bea57060c863d0c3474c79350bd9c557f2ff0e7c by INADA Naoki in branch 'master':
bpo-32677: Optimize str.isascii() (GH-5356)
https://github.com/python/cpython/commit/bea57060c863d0c3474c79350bd9c557f2ff0e7c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Sat Jan 27 20:01:04 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 28 Jan 2018 01:01:04 +0000
Subject: [issue32677] Add.isascii() to str, bytes and bytearray
In-Reply-To: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>
Message-ID: <1517101264.25.0.467229070634.issue32677@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Sat Jan 27 20:01:36 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Jan 2018 01:01:36 +0000
Subject: [issue32546] Unusual TypeError with dataclass decorator
In-Reply-To: <1515878783.18.0.467229070634.issue32546@psf.upfronthosting.co.za>
Message-ID: <1517101296.69.0.467229070634.issue32546@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This has been fixed as part of #32513.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32546>
_______________________________________

From report at bugs.python.org  Sat Jan 27 21:23:46 2018
From: report at bugs.python.org (Nitish)
Date: Sun, 28 Jan 2018 02:23:46 +0000
Subject: [issue32606] Email Header Injection Protection Bypass
In-Reply-To: <1516513252.62.0.467229070634.issue32606@psf.upfronthosting.co.za>
Message-ID: <1517106226.46.0.467229070634.issue32606@psf.upfronthosting.co.za>


Nitish <nitishch at protonmail.com> added the comment:

RFC 5322[1] says that header field's name can't have space in it and the must be immediately followed by the ':' character.

Is it common for SMTP servers to accept messages with ' ' before ':'?


[1] https://tools.ietf.org/html/rfc5322#section-2.2

----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32606>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:16:31 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Jan 2018 03:16:31 +0000
Subject: [issue32690] Return function locals() in order of creation?
Message-ID: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Found in this thread: https://twitter.com/dabeaz/status/956264950430912512

Note that at the global level locals() indeed returns variables in order of definition. Ditto at class scope. Because those calls just return the actual dict. But in a function, a dict is constructed. I agree with Dave that it would be nice if the order there was reversed.

----------
components: Interpreter Core
messages: 310905
nosy: gvanrossum
priority: low
severity: normal
stage: needs patch
status: open
title: Return function locals() in order of creation?
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:22:14 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 28 Jan 2018 03:22:14 +0000
Subject: [issue14010] deeply nested itertools objects segfault
In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>
Message-ID: <1517109734.85.0.467229070634.issue14010@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: deeply nested filter segfaults -> deeply nested itertools objects segfault

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14010>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:31:24 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Jan 2018 03:31:24 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1517110284.78.0.467229070634.issue32664@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5214
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:32:32 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 28 Jan 2018 03:32:32 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1517110352.69.0.467229070634.issue32664@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

I will backport the change to 3.6.

----------
assignee: docs at python -> Mariatta
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:38:58 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 28 Jan 2018 03:38:58 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517110738.44.0.467229070634.issue32690@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

What should happen for:

def f():
    if random.random() < 0.5:
        a = 1
        b = 2
    else:
        b = 1
        a = 2
    return locals()

? Right now co_varnames preserves the order that names were encountered when compiling, so it'd be easy to make 'a' come before 'b' in locals(), so the above function returns either {'a': 1, 'b': 2} or {'a': 2, 'b': 1}.

If we want to preserve the illusion that local variables are entries in the locals() dict, though, then the dict ought to be either {'a': 1, 'b': 2}, {'b': 1, 'a': 2}. Making this happen would require extra machinery for an extreme edge case so I'm guessing it's not worth it though.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:47:00 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 03:47:00 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1517111220.9.0.467229070634.issue27172@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: ncoghlan -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27172>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:52:54 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 28 Jan 2018 03:52:54 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1517111574.92.0.467229070634.issue32664@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset d331515847f0a053b929e5a4795715cb111f42b3 by Mariatta (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-32664: Add missing "|" connector in Exceptions doc (GH-1173) (GH-5372)
https://github.com/python/cpython/commit/d331515847f0a053b929e5a4795715cb111f42b3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:53:46 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 03:53:46 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1517111626.32.0.467229070634.issue29120@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As part of the startup sequence refactoring, this file has been renamed to Python/bootstrap_hash.c, and _PyRandom_Init/Fini have been renamed to _Py_HashRandomization_Init/Fini.

Relevant commit: https://github.com/python/cpython/commit/6b4be195cd8868b76eb6fbe166acc39beee8ce36#diff-5c57849694577deb1e10475ae796f7dc

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:56:14 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 28 Jan 2018 03:56:14 +0000
Subject: [issue32664] Connector "|" missing between ImportError and LookupError
In-Reply-To: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>
Message-ID: <1517111774.65.0.467229070634.issue32664@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:56:39 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Jan 2018 03:56:39 +0000
Subject: [issue32606] Email Header Injection Protection Bypass
In-Reply-To: <1516513252.62.0.467229070634.issue32606@psf.upfronthosting.co.za>
Message-ID: <1517111799.66.0.467229070634.issue32606@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes.

There's this thing called Postel's Law that says you should be generous in what you accept and careful in what you emit.  So most MTAs and MUAs try very hard to guess what a non-RFC-compliant email is trying to say, which includes allowing spaces between the label and the colon (which I believe was legal at least in RFC 822, though I haven't checked).  If there's a space in the label, the handling for that is less predictable.  The email library's default is to treat that as a non-header line and therefor the start of the body (even if not followed by a blank line).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32606>
_______________________________________

From report at bugs.python.org  Sat Jan 27 23:03:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 04:03:32 +0000
Subject: [issue30306] release arguments of contextmanager
In-Reply-To: <1494252281.4.0.796080303271.issue30306@psf.upfronthosting.co.za>
Message-ID: <1517112212.89.0.467229070634.issue30306@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ouch, this clearly slipped off my review radar last year - I just picked it up again now while going through all my currently assigned issues before 3.7b1.

While I still think the suggested refactoring above would be a good way to go, Martin's single-line fix in the PR passes all the new test cases, and solves the reported problem, so I'm going to add a NEWS entry and then merge it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30306>
_______________________________________

From report at bugs.python.org  Sat Jan 27 23:17:49 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 04:17:49 +0000
Subject: [issue30306] release arguments of contextmanager
In-Reply-To: <1494252281.4.0.796080303271.issue30306@psf.upfronthosting.co.za>
Message-ID: <1517113069.19.0.467229070634.issue30306@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset dd0e087edc8f1e4d2c0913236b1a62a77d9db6d8 by Nick Coghlan (Martin Teichmann) in branch 'master':
bpo-30306: release arguments of contextmanager (GH-1500)
https://github.com/python/cpython/commit/dd0e087edc8f1e4d2c0913236b1a62a77d9db6d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30306>
_______________________________________

From report at bugs.python.org  Sat Jan 27 23:20:55 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 04:20:55 +0000
Subject: [issue30306] release arguments of contextmanager
In-Reply-To: <1494252281.4.0.796080303271.issue30306@psf.upfronthosting.co.za>
Message-ID: <1517113255.24.0.467229070634.issue30306@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +5215
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30306>
_______________________________________

From report at bugs.python.org  Sat Jan 27 23:33:30 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 04:33:30 +0000
Subject: [issue32321] functools.reduce has a redundant guard or needs a pure
 Python fallback
In-Reply-To: <1513257994.59.0.213398074469.issue32321@psf.upfronthosting.co.za>
Message-ID: <1517114010.41.0.467229070634.issue32321@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reviewing the code and the CI test failures on the PR, the trick here is that functools isn't actually *using* functools.reduce, it's just re-exporting it if it's defined.

So if you block importing of "_functools" (which the test suite does in order to test the pure Python fallbacks), then the *only* consequence is that "functools.reduce" will be missing - the module will otherwise be fine.

This isn't at all clear when reading the code though, so I think the simplest resolution here would be to add a comment to the fallback path that says "If _functools.reduce is missing, then functools.reduce will also be missing, but the module will otherwise work".

Alternatively, we could add a fallback implementation based on the recipe in the docs, and adjust the test suite to actually run the reduce tests against the py_functools variant: https://docs.python.org/3/library/functools.html#functools.reduce

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32321>
_______________________________________

From report at bugs.python.org  Sat Jan 27 23:48:11 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 04:48:11 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517114891.2.0.467229070634.issue32690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The current oddity where the names will always appear in the reverse of declaration order comes from a C level loop in the frame object's "map_to_dict" helper function that loops in reverse [1]:

    ...
    for (j = nmap; --j >= 0; ) {
        ...
    }

While I haven't tried reversing that yet, I haven't found anything to indicate that it *needs* to be a reverse iteration - it looks like Guido just wrote it that way back in 1994 [2], and everyone that touched the code since then preserved the original iteration order since they didn't have a compelling reason to change it.


[1] https://github.com/python/cpython/blob/master/Objects/frameobject.c#L794
[2] https://github.com/python/cpython/commit/1d5735e84621a7fe68d361fa0e289fa2c3310836

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sat Jan 27 23:58:50 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 04:58:50 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1517115530.47.0.467229070634.issue32206@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset fcf8b4c1022bc2d2f84dcef5d72eabf40a25ea19 by Nick Coghlan (Mario Corchero) in branch 'master':
bpo-32206: Update pdb usage to include new module option (GH-5111)
https://github.com/python/cpython/commit/fcf8b4c1022bc2d2f84dcef5d72eabf40a25ea19


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:04:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 05:04:51 +0000
Subject: [issue32691] "pdb -m <module>" sets __main__.__package__ incorrectly
Message-ID: <1517115891.43.0.467229070634.issue32691@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

For regular modules, the initial implementation of bpo-32206 sets __package__ to "module_name" instead of "module_name.rpartition('.')[0]".

This is not correct, and will cause problems for relative imports.

(From https://bugs.python.org/issue32206#msg310882)

----------
messages: 310917
nosy: jason.coombs, mariocj89, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: "pdb -m <module>" sets __main__.__package__ incorrectly
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32691>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:07:16 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 05:07:16 +0000
Subject: [issue32206] Run modules with pdb
In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za>
Message-ID: <1517116036.68.0.467229070634.issue32206@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I checked the original PR, and I'm pretty sure the reference implementation is going to have the same bug.

To keep the NEWS entries clear (since the buggy implementation already shipped in the alpha releases), I've created a new issue here: https://bugs.python.org/issue32691

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32206>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:09:31 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 05:09:31 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1517116171.01.0.467229070634.issue17044@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed it should! Thanks for pointing that out :)

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:12:23 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 05:12:23 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517116343.82.0.467229070634.issue32685@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

They're the only characters we won't want to include as part of the suggestion, since they indicate the end of the statement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:14:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 05:14:32 +0000
Subject: [issue30306] release arguments of contextmanager
In-Reply-To: <1494252281.4.0.796080303271.issue30306@psf.upfronthosting.co.za>
Message-ID: <1517116472.72.0.467229070634.issue30306@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset a278ad2faa76ae61569a58f36e06ba8745f4a9b7 by Nick Coghlan in branch 'master':
bpo-30306: Add missing NEWS entry (GH-5374)
https://github.com/python/cpython/commit/a278ad2faa76ae61569a58f36e06ba8745f4a9b7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30306>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:15:17 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 05:15:17 +0000
Subject: [issue30306] release arguments of contextmanager
In-Reply-To: <1494252281.4.0.796080303271.issue30306@psf.upfronthosting.co.za>
Message-ID: <1517116517.44.0.467229070634.issue30306@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the issue report and patch Martin, and sorry for the long delay in getting it merged!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30306>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:29:44 2018
From: report at bugs.python.org (Greg Lindahl)
Date: Sun, 28 Jan 2018 05:29:44 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1517117384.55.0.467229070634.issue17305@psf.upfronthosting.co.za>


Greg Lindahl <lindahl at pbm.com> added the comment:

I am avoiding Python's built-in libraries as much as possible in my aiohttp-based crawler because of this issue, but I cannot open a connection to https://xn--ho-hia.de because there is an 'IDNA does not round-trip' raise in the python 3.6 library ssl.py code.

Happy to provide a code sample. I guess the 500-line async crawler in Guido's book was never used on German websites.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:44:53 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 28 Jan 2018 05:44:53 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1517118293.83.0.467229070634.issue17305@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Greg: That's bpo-28414. There's currently no motion towards builtin IDNA 2008 support (this bug), but I *think* in 3.7 the ssl module will be able to handle pre-encoded A-labels like that. I'm a little confused about the exact status right now but there's been lots of dicussion about that specific issue and I think Christian is planning to get one of the relevant PRs merged ASAP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Sun Jan 28 01:04:10 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Jan 2018 06:04:10 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517119450.94.0.467229070634.issue32690@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Heh, that's old code! IIRC I wrote a lot of loops like that, it was a little C trick I had picked up that reduced the loop overhead (since comparing to 0 is quicker than comparing to a variable). And until 3.6 it didn't really matter. I very much doubt the loop speed matters. So go ahead and try changing it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 01:48:20 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 06:48:20 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517122100.93.0.467229070634.issue32690@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 02:34:43 2018
From: report at bugs.python.org (Nitish)
Date: Sun, 28 Jan 2018 07:34:43 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517124883.08.0.467229070634.issue32685@psf.upfronthosting.co.za>


Change by Nitish <nitishch at protonmail.com>:


----------
keywords: +patch
pull_requests: +5216
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 02:35:18 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Sun, 28 Jan 2018 07:35:18 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517124918.76.0.467229070634.issue32685@psf.upfronthosting.co.za>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +5217

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 02:38:23 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 28 Jan 2018 07:38:23 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
In-Reply-To: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>
Message-ID: <1517125103.38.0.467229070634.issue32687@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 9ed0aee27c249dada410a22fff4325a4a61df36d by Xiang Zhang in branch 'master':
bpo-32687: Fix wrong meaning of args for PyTrace_LINE/CALL in documentation (#5361)
https://github.com/python/cpython/commit/9ed0aee27c249dada410a22fff4325a4a61df36d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sun Jan 28 02:38:29 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Jan 2018 07:38:29 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
In-Reply-To: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>
Message-ID: <1517125109.37.0.467229070634.issue32687@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5218

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sun Jan 28 02:39:30 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Jan 2018 07:39:30 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
In-Reply-To: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>
Message-ID: <1517125170.24.0.467229070634.issue32687@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5219

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sun Jan 28 02:57:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Jan 2018 07:57:12 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1517111626.32.0.467229070634.issue29120@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbMOctDKEZaLm3Qa9Pd6=nbJN6+kJfKNiYHVU0SrrNL1A@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I prefered random.c name since hash initialization is only a small part of
the file, most of file is the implementation of os.urandom() and
os.getrandom() which is used a runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sun Jan 28 03:22:57 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 08:22:57 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517127777.58.0.467229070634.issue32690@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5220
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 03:41:10 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 28 Jan 2018 08:41:10 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
In-Reply-To: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>
Message-ID: <1517128870.28.0.467229070634.issue32687@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 854f0424de389f023b375dfd0b50c34dea29e8f8 by Xiang Zhang (Miss Islington (bot)) in branch '3.6':
bpo-32687: Fix wrong meaning of args for PyTrace_LINE/CALL in documentation (GH-5361) (GH-5377)
https://github.com/python/cpython/commit/854f0424de389f023b375dfd0b50c34dea29e8f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sun Jan 28 03:41:31 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 28 Jan 2018 08:41:31 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
In-Reply-To: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>
Message-ID: <1517128891.62.0.467229070634.issue32687@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 745e9de7dd9d237d54e92d6e4b469e916fb0352b by Xiang Zhang (Miss Islington (bot)) in branch '2.7':
bpo-32687: Fix wrong meaning of args for PyTrace_LINE/CALL in documentation (GH-5361) (GH-5378)
https://github.com/python/cpython/commit/745e9de7dd9d237d54e92d6e4b469e916fb0352b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sun Jan 28 03:43:19 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 28 Jan 2018 08:43:19 +0000
Subject: [issue32687] wrong meaning of arg in Py_tracefunc doc
In-Reply-To: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>
Message-ID: <1517128999.71.0.467229070634.issue32687@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sun Jan 28 03:54:10 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 28 Jan 2018 08:54:10 +0000
Subject: [issue32692] test_threading.test_set_and_clear fails in AppVeyor CI
Message-ID: <1517129650.59.0.467229070634.issue32692@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

test_threading.test_set_and_clear fails in AppVeyor CI. But seems it not stable since rerun succeeds. See https://ci.appveyor.com/project/python/cpython/build/3.6build11314/job/ussor83yaglx5whb.

FAIL: test_set_and_clear (test.test_threading.EventTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\lock_tests.py", line 407, in test_set_and_clear
    self.assertEqual(results, [True] * N)
AssertionError: Lists differ: [False, False, False, True, True] != [True, True, True, True, True]
First differing element 0:
False
True
- [False, False, False, True, True]
+ [True, True, True, True, True]

----------
components: Tests
messages: 310930
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: test_threading.test_set_and_clear fails in AppVeyor CI
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32692>
_______________________________________

From report at bugs.python.org  Sun Jan 28 04:53:46 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 09:53:46 +0000
Subject: [issue32649] complete C API doc debug and profile part with new
 PyTrace_OPCODE
In-Reply-To: <1516798950.57.0.467229070634.issue32649@psf.upfronthosting.co.za>
Message-ID: <1517133226.68.0.467229070634.issue32649@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 255f7a26da47ca6b7bd1d375b8a04920f68c119c by Nick Coghlan (Xiang Zhang) in branch 'master':
bpo-32649: Add C API docs for per-opcode tracing & profiling (GH-5360)
https://github.com/python/cpython/commit/255f7a26da47ca6b7bd1d375b8a04920f68c119c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32649>
_______________________________________

From report at bugs.python.org  Sun Jan 28 04:54:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 09:54:19 +0000
Subject: [issue32649] complete C API doc debug and profile part with new
 PyTrace_OPCODE
In-Reply-To: <1516798950.57.0.467229070634.issue32649@psf.upfronthosting.co.za>
Message-ID: <1517133259.67.0.467229070634.issue32649@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Merged, thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32649>
_______________________________________

From report at bugs.python.org  Sun Jan 28 05:34:44 2018
From: report at bugs.python.org (David Beazley)
Date: Sun, 28 Jan 2018 10:34:44 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517135684.15.0.467229070634.issue32690@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Some context:  I noticed this while discussing (in a course) a programming trick involving instance initialization and locals() that I'd encountered in the past:

    def _init(locs):
        self = locs.pop('self')
        for name, val in locs.items():
            setattr(self, name, val)

    class Spam:
        def __init__(self, a, b, c, d):
            _init(locals())

In looking at locals(), it was coming back in reverse order of method arguments (d, c, b, a, self).   To be honest, it wasn't a critical matter, but more of an odd curiosity in light of recent dictionary ordering.

I could imagine writing a slightly more general version of _init() that didn't depend on a named 'self' argument if order was preserved:

    def _init(locs):
       items = list(locs.items())
       _, self = items[0]
       for name, val in items[1:]:
           setattr(self, name, val)

Personally, I don't think the issue Nathaniel brings up is worth worrying about because it would be such a weird edge case on something that is already an edge case.  Returning variables in "lexical order"--meaning the order in which first encountered in the source seems pretty sensible to me.

----------
nosy: +dabeaz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 05:56:09 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 10:56:09 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517136969.95.0.467229070634.issue32685@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 43c0f1ac5ed8bc9c3bd048d2ce4de4c98a83de99 by Nick Coghlan (Nitish Chandra) in branch 'master':
bpo-32685: Improve suggestion for print statement (GH-5375)
https://github.com/python/cpython/commit/43c0f1ac5ed8bc9c3bd048d2ce4de4c98a83de99


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 05:56:28 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 10:56:28 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517136988.0.0.467229070634.issue32685@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage: patch review -> backport needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 05:57:10 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Jan 2018 10:57:10 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517137030.81.0.467229070634.issue32685@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5221
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 06:01:57 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 11:01:57 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1517137317.18.0.467229070634.issue29120@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aye, but the reason they're here rather than in the os module where you might otherwise expect to find them is because the hash randomization bootstrapping needs them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sun Jan 28 06:16:16 2018
From: report at bugs.python.org (Nikolay Aleksandrovich Pavlov)
Date: Sun, 28 Jan 2018 11:16:16 +0000
Subject: [issue32693] os.path.ismount does not accept bytes objects
Message-ID: <1517138176.06.0.467229070634.issue32693@psf.upfronthosting.co.za>


New submission from Nikolay Aleksandrovich Pavlov <zyx.vim at gmail.com>:

According to the documentation it ought to accept any path-like object, but actually throws for bytes ones. The trace of logic is the following:

1. ismount() from Lib/ntpath.py is using `os.fpath` which may return either bytes or str: https://github.com/python/cpython/blob/255f7a26da47ca6b7bd1d375b8a04920f68c119c/Lib/ntpath.py#L263.
2. The output is passed to _getvolumepathname unchanged.
3. The clinic defines that function?s only argument as [unicode](https://github.com/python/cpython/blob/255f7a26da47ca6b7bd1d375b8a04920f68c119c/Modules/posixmodule.c#L3793).
4. If clinic was not there it would still require to change how path_wchar is defined below, PyUnicode? functions will not accept bytes object: https://github.com/python/cpython/blob/255f7a26da47ca6b7bd1d375b8a04920f68c119c/Modules/posixmodule.c#L3808.

Suggestion: change `Lib/ntpath.py` to use `os.fsdecode` in place of `os.fspath`.

This is a relay of issue https://github.com/powerline/powerline/issues/1876. Initial reporter observed bug on Python 3.6 (patch unknown), I could see an issue in current master (all links above point to that).

----------
components: Windows
messages: 310936
nosy: Nikolay Aleksandrovich Pavlov, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.ismount does not accept bytes objects
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32693>
_______________________________________

From report at bugs.python.org  Sun Jan 28 06:31:50 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 11:31:50 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517139110.46.0.467229070634.issue32685@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset b3b4b81d0147534151941105eba4af984acdc763 by Nick Coghlan (Miss Islington (bot)) in branch '3.6':
bpo-32685: Improve suggestion for print statement (GH-5380)
https://github.com/python/cpython/commit/b3b4b81d0147534151941105eba4af984acdc763


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 06:33:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 11:33:27 +0000
Subject: [issue32685] Erroneous suggestion in print statement
In-Reply-To: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>
Message-ID: <1517139207.86.0.467229070634.issue32685@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the patches, Sanyam & Nitish, and for the original bug report Mayank.

Thanks also to Cheryl for nudging us to get it resolved :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 06:43:18 2018
From: report at bugs.python.org (Ofer)
Date: Sun, 28 Jan 2018 11:43:18 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
 to BaseException.__new__
Message-ID: <1517139798.73.0.467229070634.issue1692335@psf.upfronthosting.co.za>


Ofer <horowitz.ofer at gmail.com> added the comment:

Perhaps this is a problem for a different issue, but pickling custom exceptions fails when the exception gets more than one argument:

import pickle
class MultipleArgumentsError(Exception):
    def __init__(self, a, b):
        self.a = a
        self.b = b
        Exception.__init__(self, a)

pickle.loads(pickle.dumps(MultipleArgumentsError('a', 'b')))


this code produces the following error:

Traceback (most recent call last):
  File "/tmp/multiple_arguments_exception.py", line 8, in <module>
    pickle.loads(pickle.dumps(MultipleArgumentsError('a', 'b')))
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1388, in loads
    return Unpickler(file).load()
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 864, in load
    dispatch[key](self)
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1139, in load_reduce
    value = func(*args)
TypeError: __init__() takes exactly 3 arguments (2 given)

----------
nosy: +slallum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jan 28 06:54:59 2018
From: report at bugs.python.org (Andreas Schwab)
Date: Sun, 28 Jan 2018 11:54:59 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1517140499.25.0.467229070634.issue31900@psf.upfronthosting.co.za>


Andreas Schwab <schwab at linux-m68k.org> added the comment:

> The technical issue here is that the libc has no "stateless" function to process bytes and text with one specific locale.

That's not true.  There is a rich set of *_l functions that take a locale_t object and operate on that locale.

----------
nosy: +schwab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Sun Jan 28 07:05:27 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 28 Jan 2018 12:05:27 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1517141127.29.0.467229070634.issue32545@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

>From the log file, all I can tell is that it failed to open the file containing information about ongoing installs. At a guess, another install was running (maybe failed?) and didn't clean up properly.

Rebooting should generally resolve that. If it doesn't, you're either looking at serious OS corruption (worth testing if any other MSI installers work - Anaconda does not use MSI) or disk corruption.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Sun Jan 28 07:10:12 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 28 Jan 2018 12:10:12 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
In-Reply-To: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>
Message-ID: <1517141412.62.0.467229070634.issue32611@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

To fix this, we need to make Idle its own .exe file with an AppId and properly registered icon. Right now, it's just a .pyw file running in Python, and so things like pinning icons or file associations won't work cleanly.

----------
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Sun Jan 28 07:15:07 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Jan 2018 12:15:07 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1517141707.62.0.467229070634.issue17305@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

A fix will land in 3.7 and maybe get backported to 3.6. Stay tuned!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Sun Jan 28 07:57:38 2018
From: report at bugs.python.org (7stud)
Date: Sun, 28 Jan 2018 12:57:38 +0000
Subject: [issue32686] python3.6.4 build with --enable-optimzations hangs on
 macOS 10.13
In-Reply-To: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>
Message-ID: <1517144258.53.0.467229070634.issue32686@psf.upfronthosting.co.za>


7stud <7stud at excite.com> added the comment:

Hi Ned Deily,

Thanks for the suggestion.  I ran ./configure again, but this time make errored out:


...
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [python.exe] Error 1

So I deleted the Python3.6.4 directory:

$ rm -rf Python-3.6.4

and I started over:

~/Downloads$ tar xfvz Python-3.6.4.tgz 

Then I ran ./configure, then make, and this time make completed successfully.

However....next up was make test, and after letting make test run for two hours, I killed it:

...
...
running: test_asyncio (56 sec)
running: test_asyncio (86 sec)
running: test_asyncio (116 sec)
running: test_asyncio (146 sec)
running: test_asyncio (176 sec)
running: test_asyncio (206 sec)
running: test_asyncio (236 sec)
running: test_asyncio (266 sec)
running: test_asyncio (296 sec)
running: test_asyncio (326 sec)
running: test_asyncio (356 sec)
running: test_asyncio (386 sec)
running: test_asyncio (416 sec)
running: test_asyncio (446 sec)
running: test_asyncio (476 sec)
running: test_asyncio (506 sec)
running: test_asyncio (536 sec)
running: test_asyncio (566 sec)
running: test_asyncio (596 sec)
running: test_asyncio (626 sec)
running: test_asyncio (656 sec)
running: test_asyncio (686 sec)
running: test_asyncio (716 sec)
running: test_asyncio (746 sec)
running: test_asyncio (776 sec)
running: test_asyncio (806 sec)
running: test_asyncio (836 sec)
running: test_asyncio (866 sec)
running: test_asyncio (896 sec)
running: test_asyncio (926 sec)
running: test_asyncio (956 sec)
running: test_asyncio (986 sec)
running: test_asyncio (1016 sec)
running: test_asyncio (1046 sec)
running: test_asyncio (1076 sec)
running: test_asyncio (1106 sec)
running: test_asyncio (1136 sec)
running: test_asyncio (1166 sec)
running: test_asyncio (1196 sec)
running: test_asyncio (1226 sec)
running: test_asyncio (1256 sec)
running: test_asyncio (1286 sec)
running: test_asyncio (1316 sec)
running: test_asyncio (1346 sec)
running: test_asyncio (1376 sec)
running: test_asyncio (1406 sec)
running: test_asyncio (1436 sec)
running: test_asyncio (1466 sec)
running: test_asyncio (1496 sec)
running: test_asyncio (1526 sec)
running: test_asyncio (1556 sec)
running: test_asyncio (1586 sec)
running: test_asyncio (1616 sec)
running: test_asyncio (1646 sec)
running: test_asyncio (1676 sec)
running: test_asyncio (1706 sec)
running: test_asyncio (1736 sec)
running: test_asyncio (1766 sec)
running: test_asyncio (1796 sec)
running: test_asyncio (1826 sec)
running: test_asyncio (1856 sec)
running: test_asyncio (1886 sec)
running: test_asyncio (1916 sec)
running: test_asyncio (1946 sec)
running: test_asyncio (1976 sec)
running: test_asyncio (2006 sec)
running: test_asyncio (2036 sec)
running: test_asyncio (2066 sec)
running: test_asyncio (2096 sec)
running: test_asyncio (2126 sec)
running: test_asyncio (2156 sec)
running: test_asyncio (2186 sec)
running: test_asyncio (2216 sec)
running: test_asyncio (2246 sec)
running: test_asyncio (2276 sec)
running: test_asyncio (2306 sec)
running: test_asyncio (2336 sec)
running: test_asyncio (2366 sec)
running: test_asyncio (2396 sec)
running: test_asyncio (2426 sec)
running: test_asyncio (2456 sec)
running: test_asyncio (2486 sec)
running: test_asyncio (2516 sec)
running: test_asyncio (2546 sec)
running: test_asyncio (2576 sec)
running: test_asyncio (2606 sec)
running: test_asyncio (2636 sec)
running: test_asyncio (2666 sec)
running: test_asyncio (2696 sec)
running: test_asyncio (2726 sec)
running: test_asyncio (2756 sec)
running: test_asyncio (2786 sec)
running: test_asyncio (2816 sec)
running: test_asyncio (2846 sec)
running: test_asyncio (2876 sec)
running: test_asyncio (2906 sec)
running: test_asyncio (2936 sec)
running: test_asyncio (2966 sec)
running: test_asyncio (2996 sec)
running: test_asyncio (3026 sec)
running: test_asyncio (3056 sec)
running: test_asyncio (3086 sec)
running: test_asyncio (3116 sec)
running: test_asyncio (3146 sec)
running: test_asyncio (3176 sec)
running: test_asyncio (3206 sec)
running: test_asyncio (3236 sec)
running: test_asyncio (3266 sec)
running: test_asyncio (3296 sec)
running: test_asyncio (3326 sec)
running: test_asyncio (3356 sec)
running: test_asyncio (3386 sec)
running: test_asyncio (3416 sec)
running: test_asyncio (3446 sec)
running: test_asyncio (3476 sec)
running: test_asyncio (3506 sec)
running: test_asyncio (3536 sec)
running: test_asyncio (3566 sec)
running: test_asyncio (3596 sec)
running: test_asyncio (3626 sec)
running: test_asyncio (3656 sec)
running: test_asyncio (3686 sec)
running: test_asyncio (3716 sec)
running: test_asyncio (3746 sec)
running: test_asyncio (3776 sec)
running: test_asyncio (3806 sec)
running: test_asyncio (3836 sec)
running: test_asyncio (3866 sec)
running: test_asyncio (3896 sec)
running: test_asyncio (3926 sec)
running: test_asyncio (3956 sec)
running: test_asyncio (3986 sec)
running: test_asyncio (4016 sec)
running: test_asyncio (4046 sec)
running: test_asyncio (4076 sec)
running: test_asyncio (4106 sec)
running: test_asyncio (4136 sec)
running: test_asyncio (4166 sec)
running: test_asyncio (4196 sec)
running: test_asyncio (4226 sec)
running: test_asyncio (4256 sec)
running: test_asyncio (4286 sec)
running: test_asyncio (4316 sec)
running: test_asyncio (4346 sec)
running: test_asyncio (4376 sec)
running: test_asyncio (4406 sec)
running: test_asyncio (4436 sec)
running: test_asyncio (4466 sec)
running: test_asyncio (4496 sec)
running: test_asyncio (4526 sec)
running: test_asyncio (4556 sec)
running: test_asyncio (4586 sec)
running: test_asyncio (4616 sec)
running: test_asyncio (4646 sec)
running: test_asyncio (4676 sec)
running: test_asyncio (4706 sec)
running: test_asyncio (4736 sec)
running: test_asyncio (4766 sec)
running: test_asyncio (4796 sec)
running: test_asyncio (4826 sec)
running: test_asyncio (4856 sec)
running: test_asyncio (4886 sec)
running: test_asyncio (4916 sec)
running: test_asyncio (4946 sec)
running: test_asyncio (4976 sec)
running: test_asyncio (5006 sec)
running: test_asyncio (5036 sec)
running: test_asyncio (5066 sec)
running: test_asyncio (5096 sec)
running: test_asyncio (5126 sec)
running: test_asyncio (5156 sec)
running: test_asyncio (5186 sec)
running: test_asyncio (5216 sec)
running: test_asyncio (5246 sec)
running: test_asyncio (5276 sec)
running: test_asyncio (5306 sec)
running: test_asyncio (5336 sec)
running: test_asyncio (5366 sec)
running: test_asyncio (5396 sec)
running: test_asyncio (5426 sec)
running: test_asyncio (5456 sec)
running: test_asyncio (5486 sec)
running: test_asyncio (5516 sec)
running: test_asyncio (5546 sec)
running: test_asyncio (5576 sec)
running: test_asyncio (5606 sec)
running: test_asyncio (5636 sec)
running: test_asyncio (5666 sec)
running: test_asyncio (5696 sec)
running: test_asyncio (5726 sec)
running: test_asyncio (5756 sec)
running: test_asyncio (5786 sec)
running: test_asyncio (5816 sec)
running: test_asyncio (5846 sec)
running: test_asyncio (5876 sec)
running: test_asyncio (5906 sec)
running: test_asyncio (5936 sec)
running: test_asyncio (5966 sec)
running: test_asyncio (5996 sec)
running: test_asyncio (6026 sec)
running: test_asyncio (6056 sec)
running: test_asyncio (6086 sec)
running: test_asyncio (6116 sec)
running: test_asyncio (6146 sec)
running: test_asyncio (6176 sec)
running: test_asyncio (6206 sec)
running: test_asyncio (6236 sec)
running: test_asyncio (6266 sec)
running: test_asyncio (6296 sec)
running: test_asyncio (6326 sec)
running: test_asyncio (6356 sec)
running: test_asyncio (6386 sec)
running: test_asyncio (6416 sec)
running: test_asyncio (6446 sec)
running: test_asyncio (6476 sec)
running: test_asyncio (6506 sec)
running: test_asyncio (6536 sec)
running: test_asyncio (6566 sec)
running: test_asyncio (6596 sec)
running: test_asyncio (6626 sec)
running: test_asyncio (6656 sec)
running: test_asyncio (6686 sec)
running: test_asyncio (6716 sec)
running: test_asyncio (6746 sec)
running: test_asyncio (6776 sec)
running: test_asyncio (6806 sec)
running: test_asyncio (6836 sec)
running: test_asyncio (6866 sec)
running: test_asyncio (6896 sec)
running: test_asyncio (6926 sec)
running: test_asyncio (6956 sec)
running: test_asyncio (6986 sec)
running: test_asyncio (7016 sec)
running: test_asyncio (7046 sec)
running: test_asyncio (7076 sec)
running: test_asyncio (7106 sec)
running: test_asyncio (7136 sec)
running: test_asyncio (7166 sec)
running: test_asyncio (7196 sec)
running: test_asyncio (7226 sec)
running: test_asyncio (7256 sec)
running: test_asyncio (7286 sec)
running: test_asyncio (7316 sec)
running: test_asyncio (7346 sec)
running: test_asyncio (7376 sec)
running: test_asyncio (7406 sec)
running: test_asyncio (7436 sec)
running: test_asyncio (7466 sec)
running: test_asyncio (7496 sec)
running: test_asyncio (7526 sec)
running: test_asyncio (7556 sec)
running: test_asyncio (7586 sec)
running: test_asyncio (7616 sec)
running: test_asyncio (7646 sec)
running: test_asyncio (7676 sec)
running: test_asyncio (7706 sec)
running: test_asyncio (7736 sec)
running: test_asyncio (7766 sec)
running: test_asyncio (7796 sec)
running: test_asyncio (7826 sec)
running: test_asyncio (7856 sec)
running: test_asyncio (7886 sec)
running: test_asyncio (7916 sec)
running: test_asyncio (7946 sec)
running: test_asyncio (7976 sec)
running: test_asyncio (8006 sec)
running: test_asyncio (8036 sec)
running: test_asyncio (8066 sec)
running: test_asyncio (8096 sec)
running: test_asyncio (8126 sec)
running: test_asyncio (8156 sec)
running: test_asyncio (8186 sec)
running: test_asyncio (8216 sec)
running: test_asyncio (8246 sec)
running: test_asyncio (8276 sec)
running: test_asyncio (8306 sec)
running: test_asyncio (8336 sec)
running: test_asyncio (8366 sec)
running: test_asyncio (8396 sec)
running: test_asyncio (8426 sec)
running: test_asyncio (8456 sec)
running: test_asyncio (8486 sec)
running: test_asyncio (8516 sec)
running: test_asyncio (8546 sec)
running: test_asyncio (8576 sec)
running: test_asyncio (8606 sec)
running: test_asyncio (8636 sec)
running: test_asyncio (8666 sec)
running: test_asyncio (8696 sec)
running: test_asyncio (8726 sec)
running: test_asyncio (8756 sec)
running: test_asyncio (8787 sec)
running: test_asyncio (8817 sec)
running: test_asyncio (8847 sec)
running: test_asyncio (8877 sec)
running: test_asyncio (8907 sec)
running: test_asyncio (8937 sec)
running: test_asyncio (8967 sec)
running: test_asyncio (8997 sec)
running: test_asyncio (9027 sec)
running: test_asyncio (9057 sec)
running: test_asyncio (9087 sec)
running: test_asyncio (9117 sec)
running: test_asyncio (9147 sec)
running: test_asyncio (9177 sec)
running: test_asyncio (9207 sec)
running: test_asyncio (9237 sec)
running: test_asyncio (9267 sec)
running: test_asyncio (9297 sec)
running: test_asyncio (9327 sec)
running: test_asyncio (9357 sec)
running: test_asyncio (9387 sec)
running: test_asyncio (9417 sec)
running: test_asyncio (9447 sec)
running: test_asyncio (9477 sec)
running: test_asyncio (9507 sec)
running: test_asyncio (9537 sec)
running: test_asyncio (9567 sec)
running: test_asyncio (9597 sec)
running: test_asyncio (9627 sec)
running: test_asyncio (9657 sec)
running: test_asyncio (9687 sec)
running: test_asyncio (9717 sec)
running: test_asyncio (9747 sec)
running: test_asyncio (9777 sec)
running: test_asyncio (9807 sec)
running: test_asyncio (9837 sec)
running: test_asyncio (9867 sec)
running: test_asyncio (9897 sec)
running: test_asyncio (9927 sec)
running: test_asyncio (9957 sec)
running: test_asyncio (9987 sec)
running: test_asyncio (10017 sec)
running: test_asyncio (10047 sec)
running: test_asyncio (10077 sec)
running: test_asyncio (10107 sec)
^C
Waiting for test_asyncio (1 tests)

Test suite interrupted by signal SIGINT.
1 test omitted:
    test_asyncio
386 tests OK.

1 test failed:
    test_posix

18 tests skipped:
    test_dbm_gnu test_devpoll test_epoll test_gdb test_lzma
    test_msilib test_ossaudiodev test_smtpnet test_spwd test_ssl
    test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio
    test_winreg test_winsound test_zipfile64
Re-running failed tests in verbose mode
Re-running test 'test_posix' in verbose mode
testNoArgFunctions (test.test_posix.PosixTester) ... ok
test_access (test.test_posix.PosixTester) ... ok
test_access_dir_fd (test.test_posix.PosixTester) ... ok
test_chdir (test.test_posix.PosixTester) ... ok
test_chflags (test.test_posix.PosixTester) ... ok
test_chmod_dir_fd (test.test_posix.PosixTester) ... ok
test_chown (test.test_posix.PosixTester) ... ok
test_chown_dir_fd (test.test_posix.PosixTester) ... ok
test_confstr (test.test_posix.PosixTester) ... ok
test_dup (test.test_posix.PosixTester) ... ok
test_dup2 (test.test_posix.PosixTester) ... ok
test_environ (test.test_posix.PosixTester) ... ok
test_fchown (test.test_posix.PosixTester) ... ok
test_fexecve (test.test_posix.PosixTester) ... skipped 'test needs execve() to support the fd parameter'
test_fs_holes (test.test_posix.PosixTester) ... skipped 'OSError raised!'
test_fstat (test.test_posix.PosixTester) ... ok
test_fstatvfs (test.test_posix.PosixTester) ... ok
test_ftruncate (test.test_posix.PosixTester) ... ok
test_get_and_set_scheduler_and_param (test.test_posix.PosixTester) ... skipped "can't change scheduler"
test_getcwd_long_pathnames (test.test_posix.PosixTester) ... ok
test_getgrouplist (test.test_posix.PosixTester) ... ERROR
test_getgroups (test.test_posix.PosixTester) ... ok
test_getresgid (test.test_posix.PosixTester) ... skipped 'test needs posix.getresgid()'
test_getresuid (test.test_posix.PosixTester) ... skipped 'test needs posix.getresuid()'
test_initgroups (test.test_posix.PosixTester) ... ok
test_lchflags_regular_file (test.test_posix.PosixTester) ... ok
test_lchflags_symlink (test.test_posix.PosixTester) ... ok
test_lchown (test.test_posix.PosixTester) ... ok
test_link_dir_fd (test.test_posix.PosixTester) ... ok
test_listdir (test.test_posix.PosixTester) ... ok
test_listdir_bytes (test.test_posix.PosixTester) ... ok
test_listdir_bytes_like (test.test_posix.PosixTester) ... ok
test_listdir_default (test.test_posix.PosixTester) ... ok
test_listdir_fd (test.test_posix.PosixTester) ... ok
test_lockf (test.test_posix.PosixTester) ... ok
test_makedev (test.test_posix.PosixTester) ... ok
test_mkdir_dir_fd (test.test_posix.PosixTester) ... ok
test_mkfifo (test.test_posix.PosixTester) ... ok
test_mkfifo_dir_fd (test.test_posix.PosixTester) ... skipped 'test needs dir_fd support in os.mkfifo()'
test_mknod (test.test_posix.PosixTester) ... ok
test_mknod_dir_fd (test.test_posix.PosixTester) ... skipped 'test requires both stat.S_IFIFO and dir_fd support for os.mknod()'
test_open_dir_fd (test.test_posix.PosixTester) ... ok
test_oscloexec (test.test_posix.PosixTester) ... ok
test_osexlock (test.test_posix.PosixTester) ... ok
test_osshlock (test.test_posix.PosixTester) ... ok
test_path_error2 (test.test_posix.PosixTester) ... ok
test_path_with_null_byte (test.test_posix.PosixTester) ... ok
test_path_with_null_character (test.test_posix.PosixTester) ... ok
test_pipe (test.test_posix.PosixTester) ... ok
test_pipe2 (test.test_posix.PosixTester) ... skipped 'test needs os.pipe2()'
test_pipe2_c_limits (test.test_posix.PosixTester) ... skipped 'test needs os.pipe2()'
test_posix_fadvise (test.test_posix.PosixTester) ... skipped 'test needs posix.posix_fadvise()'
test_posix_fallocate (test.test_posix.PosixTester) ... skipped 'test needs posix.posix_fallocate()'
test_pread (test.test_posix.PosixTester) ... ok
test_putenv (test.test_posix.PosixTester) ... ok
test_pwrite (test.test_posix.PosixTester) ... ok
test_readlink_dir_fd (test.test_posix.PosixTester) ... ok
test_readv (test.test_posix.PosixTester) ... ok
test_rename_dir_fd (test.test_posix.PosixTester) ... ok
test_rtld_constants (test.test_posix.PosixTester) ... ok
test_sched_getaffinity (test.test_posix.PosixTester) ... skipped "don't have sched affinity support"
test_sched_priority (test.test_posix.PosixTester) ... ok
test_sched_rr_get_interval (test.test_posix.PosixTester) ... skipped 'no function'
test_sched_setaffinity (test.test_posix.PosixTester) ... skipped "don't have sched affinity support"
test_sched_yield (test.test_posix.PosixTester) ... ok
test_setresgid (test.test_posix.PosixTester) ... skipped 'test needs posix.setresgid()'
test_setresgid_exception (test.test_posix.PosixTester) ... skipped 'test needs posix.setresgid()'
test_setresuid (test.test_posix.PosixTester) ... skipped 'test needs posix.setresuid()'
test_setresuid_exception (test.test_posix.PosixTester) ... skipped 'test needs posix.setresuid()'
test_stat (test.test_posix.PosixTester) ... ok
test_stat_dir_fd (test.test_posix.PosixTester) ... ok
test_statvfs (test.test_posix.PosixTester) ... ok
test_strerror (test.test_posix.PosixTester) ... ok
test_symlink_dir_fd (test.test_posix.PosixTester) ... ok
test_truncate (test.test_posix.PosixTester) ... ok
test_umask (test.test_posix.PosixTester) ... ok
test_unlink_dir_fd (test.test_posix.PosixTester) ... ok
test_utime (test.test_posix.PosixTester) ... ok
test_utime_dir_fd (test.test_posix.PosixTester) ... ok
test_utime_nofollow_symlinks (test.test_posix.PosixTester) ... ok
test_utime_with_fd (test.test_posix.PosixTester) ... ok
test_waitid (test.test_posix.PosixTester) ... skipped 'test needs posix.waitid()'
test_writev (test.test_posix.PosixTester) ... ok
test_initgroups (test.test_posix.PosixGroupsTester) ... skipped 'not enough privileges'
test_setgroups (test.test_posix.PosixGroupsTester) ... skipped 'not enough privileges'

======================================================================
ERROR: test_getgrouplist (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/7stud/Downloads/Python-3.6.4/Lib/test/test_posix.py", line 823, in test_getgrouplist
    self.assertIn(group, posix.getgrouplist(user, group))
OSError: [Errno 25] Inappropriate ioctl for device

----------------------------------------------------------------------
Ran 85 tests in 0.191s

FAILED (errors=1, skipped=21)
test test_posix failed
1 test failed again:
    test_posix

Total duration: 172 min 28 sec
Tests result: FAILURE
make: *** [test] Error 2

~/Downloads/Python-3.6.4$ 





So, it looks like the same problem. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Sun Jan 28 08:00:11 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 28 Jan 2018 13:00:11 +0000
Subject: [issue32659] Solaris "stat" should support "st_fstype"
In-Reply-To: <1516841214.25.0.467229070634.issue32659@psf.upfronthosting.co.za>
Message-ID: <1517144411.41.0.467229070634.issue32659@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:


New changeset 6c51d518800cdda7ba16ae163be0d211d2c4fa12 by jcea in branch 'master':
bpo-32659: Solaris "stat" should support "st_fstype" (#5307)
https://github.com/python/cpython/commit/6c51d518800cdda7ba16ae163be0d211d2c4fa12


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32659>
_______________________________________

From report at bugs.python.org  Sun Jan 28 08:00:50 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 28 Jan 2018 13:00:50 +0000
Subject: [issue32660] Solaris should support constants like termios' FIONREAD
In-Reply-To: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>
Message-ID: <1517144450.95.0.467229070634.issue32660@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:


New changeset f0a95f27c043e847a23940534fdfc53e1b3e31a1 by jcea in branch 'master':
bpo-32660: Solaris should support constants like termios' FIONREAD (#5328)
https://github.com/python/cpython/commit/f0a95f27c043e847a23940534fdfc53e1b3e31a1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32660>
_______________________________________

From report at bugs.python.org  Sun Jan 28 09:01:10 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 14:01:10 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1517148070.75.0.467229070634.issue29571@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, even though we reverted the original test_re based change, and the initial attempted fix for bpo-20087 was also reverted, I'm still not currently seeing the failure for:

    LANG=en_IN.utf8 ./python -m test -v test_re

I do have the locale installed, so it's not a result of falling back to the C locale and that getting coerced to C.UTF-8:

    $ LANG=en_IN.utf8 locale -k currency_symbol
    currency_symbol="?"

Jaysinh, are you still seeing this test failure on a fresh checkout?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29571>
_______________________________________

From report at bugs.python.org  Sun Jan 28 09:15:37 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 14:15:37 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1517148937.69.0.467229070634.issue29571@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, this actually works for me on Fedora 27 even if I go back to 1b3d88eb33085e90af729c4c2f78b5ba1b942b1e, the commit just before the initially merged (and subsequently reverted) test change above.

Unassigning, since I can't readily reproduce it myself.

----------
assignee: ncoghlan -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29571>
_______________________________________

From report at bugs.python.org  Sun Jan 28 09:28:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 14:28:32 +0000
Subject: [issue31687] test_semaphore_tracker() of test_multiprocessing_spawn
 fails randomly (race condition?)
In-Reply-To: <1507109795.91.0.213398074469.issue31687@psf.upfronthosting.co.za>
Message-ID: <1517149712.93.0.467229070634.issue31687@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A warning I'm sometimes seeing currently on successful test runs is as follows:

------
/home/ncoghlan/devel/cpython/Lib/multiprocessing/semaphore_tracker.py:55: UserWarning: semaphore_tracker: process died unexpectedly, relaunching.  Some semaphores might leak.
  warnings.warn('semaphore_tracker: process died unexpectedly, '
------

So it may be that the system has to be under load for the test suite to notice that failure.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31687>
_______________________________________

From report at bugs.python.org  Sun Jan 28 09:48:49 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 28 Jan 2018 14:48:49 +0000
Subject: [issue21417] Compression level for zipfile
In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za>
Message-ID: <1517150929.53.0.467229070634.issue21417@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
keywords: +patch
pull_requests: +5222
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21417>
_______________________________________

From report at bugs.python.org  Sun Jan 28 09:53:07 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 28 Jan 2018 14:53:07 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <1517151187.61.0.467229070634.issue32688@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Ahh, I figure out that the line is useless and can't affect any logic then. So the analyzer is right! Sorry for the bother Brett.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sun Jan 28 09:55:49 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 28 Jan 2018 14:55:49 +0000
Subject: [issue21417] Compression level for zipfile
In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za>
Message-ID: <1517151349.17.0.467229070634.issue21417@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21417>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:04:51 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 28 Jan 2018 15:04:51 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
 to BaseException.__new__
Message-ID: <1517151891.55.0.467229070634.issue1692335@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

@slallum, That does seem to be a problem, though I do observe that the issue reported by bdb with CalledProcessError is no longer an issue:

>>> import subprocess, pickle
>>> try:
...   subprocess.check_call(['python', '-c', 'raise SystemExit(1)'])
... except Exception as e:
...   pickle.loads(pickle.dumps(e))
... 
CalledProcessError(1, ['python', '-c', 'raise SystemExit(1)'])

Looking into how CalledProcessError is defined (https://github.com/python/cpython/blob/79db11ce99332d62917be9d03b31494b1ff2f96a/Lib/subprocess.py#L60) may shed some light on the recommended way to make a pickleable Exception class that takes more than one argument.

Hmm. It seems it does it by not calling the superclass __init__. Indeed, following that model it seems to work:

import pickle
class MultipleArgumentsError(Exception):
    def __init__(self, a, b):
        self.a = a
        self.b = b

err = pickle.loads(pickle.dumps(MultipleArgumentsError('a', 'b')))
assert err.a == 'a'
assert err.b == 'b'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:11:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 15:11:23 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
Message-ID: <1517152283.77.0.467229070634.issue32694@psf.upfronthosting.co.za>


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


----------
components: Cross-Build
nosy: Alex.Willmer, christian.heimes, ned.deily, yselivanov
priority: normal
severity: normal
status: open
title: macos/configure: Discover OpenSSL when installed with MacPorts
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:11:26 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sun, 28 Jan 2018 15:11:26 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1517152286.73.0.467229070634.issue32654@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Here are some ideas after testing:

* Testing environment:
 - My building scripts at https://github.com/yan12125/python3-android/
 - Android NDK r16b
 - Google's emulator image 'system-images;android-19;default;x86'

* Ideas/findings:
 - Locale emulation for setlocale() no longer works as _locale builds fine.

>>> locale.setlocale(locale.LC_ALL, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/local/tmp/python3/usr/lib/python3.7/locale.py", line 608, in setlocale
    return _setlocale(category, locale)
locale.Error: locale query failed

 - Declarations for mmap/sendfile shouldn't be necessary. In Android NDK r16b, sendfile() is defined if __USE_FILE_OFFSET64 is not defined: (from $ANDROID_NDK/sysroot/usr/include/sys/sendfile.h)

#if defined(__USE_FILE_OFFSET64)

#if __ANDROID_API__ >= 21
ssize_t sendfile(int __out_fd, int __in_fd, off_t* __offset, size_t __count) __RENAME(sendfile64) __INTRODUCED_IN(21);
#endif /* __ANDROID_API__ >= 21 */

#else
ssize_t sendfile(int __out_fd, int __in_fd, off_t* __offset, size_t __count);
#endif

#if __ANDROID_API__ >= 21
ssize_t sendfile64(int __out_fd, int __in_fd, off64_t* __offset, size_t __count) __INTRODUCED_IN(21);
#endif /* __ANDROID_API__ >= 21 */

__USE_FILE_OFFSET64 is defined as _FILE_OFFSET_BITS is defined to 64 in pyconfig.h. An NDK developer suggest "stop defining _FILE_OFFSET_BITS=64 on 32-bit Android." (https://github.com/android-ndk/ndk/issues/536#issuecomment-333197557) Either disabling large file support on Android or simply don't define _FILE_OFFSET_BITS on Android should work.   (Android does not use _LARGEFILE_SOURCE)

 - SIGRTMIN/SIGRTMAX: This is a bug on older NDK. r15 has fixed it (https://github.com/android-ndk/ndk/issues/352). I propose to wait until CPython builds with NDK r15+. I don't like adding patches for a known bug in older toolchains and revert them later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:13:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 15:13:41 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
Message-ID: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Not sure if we should do it or not:

1. MacPorts maintainers will create a port file for Python 3.7 and they will just configure it with `configure --with-openssl=$PREFIX", where PREFIX is /opt/local by default.

2. This, however, would certainly improve the experience of manually building CPython on MacOS with macports (this would directly benefit guys like me).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:17:14 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 15:17:14 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517152634.6.0.467229070634.issue32694@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5223
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:22:06 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 28 Jan 2018 15:22:06 +0000
Subject: [issue32695] tarfile.open() raises TypeError when using compresslevel
 parameter with LZMA
Message-ID: <1517152925.99.0.467229070634.issue32695@psf.upfronthosting.co.za>


New submission from bbayles <bbayles at gmail.com>:

tarfile.open() allows for specifying both a compression type and a compression level. However, the compresslevel parameter doesn't work when using the xz modes.

    import tarfile
    good_archive = tarfile.open('/tmp/dummy.tar.gz', 'w:gz', compresslevel=9)
    bad_archive = tarfile.open('/tmp/dummy.tar.gz', 'w:xz', compresslevel=9)

This gives an error in the tarfile.TarFile constructor:

    TypeError: __init__() got an unexpected keyword argument 'compresslevel'

This appears to be due to tarfile.xzopen() specifying a preset keyword instead of a compresslevel keyword. This matches the LZMAFile compressor, but it means that it doesn't get passed in and is then carried along in the kwargs - see [1].

Changing to lzma.LZMAFile(fileobj or name, mode, preset=compresslevel) seems to fix the issue. Assuming that's the right fix, I'll submit a PR.

[1] https://github.com/python/cpython/blob/374c6e178a7599aae46c857b17c6c8bc19dfe4c2/Lib/tarfile.py#L1684-L1699

----------
components: Library (Lib)
messages: 310954
nosy: bbayles
priority: normal
severity: normal
status: open
title: tarfile.open() raises TypeError when using compresslevel parameter with LZMA
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32695>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:29:45 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Jan 2018 15:29:45 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517153385.2.0.467229070634.issue32694@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:37:56 2018
From: report at bugs.python.org (Ofer)
Date: Sun, 28 Jan 2018 15:37:56 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
 to BaseException.__new__
Message-ID: <1517153876.06.0.467229070634.issue1692335@psf.upfronthosting.co.za>


Ofer <horowitz.ofer at gmail.com> added the comment:

@jason.coombs as far as I can tell, this only works in python3, but not in python2, where it still produces the same error.

----------
versions: +Python 2.7 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:39:51 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 15:39:51 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1517153991.77.0.467229070634.issue26219@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> With the 3.7 beta deadline just around the corner, 3.8 will be the next opportunity to reconsider this idea.

Nick, Ned, Guido,

Would it be OK if we add this to 3.7beta2?

I feel kind of bad about this one... few thoughts:  

1. The speedup is about 5-10% on macro-benchmarks!  This is significant.

2. Inada-san offered me help with this, and I declined, saying that I plan to do more research/experiments and commit it before 3.7.  And I didn't have time to do it because of other work I did for CPython.

3. Even though the optimization is invasive, I feel confident about it.  It just so happens that whatever modification we do to ceval, it will be covered 100% with tests or any code you execute.  Any regression or anomaly should become apparent almost immediately.

4. We'll have quite a bit of time to see if this works or not.  This isn't a new functionality, so we can always pull it from the first RC build if necessary.

----------
nosy: +inada.naoki, ned.deily

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

From report at bugs.python.org  Sun Jan 28 10:46:14 2018
From: report at bugs.python.org (Minion Jim)
Date: Sun, 28 Jan 2018 15:46:14 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
In-Reply-To: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>
Message-ID: <1517154374.33.0.467229070634.issue32611@psf.upfronthosting.co.za>


Minion Jim <epaine13 at ranelagh.bracknell-forest.sch.uk> added the comment:

This isn't just IDLE. On the GIF, I also demonstrate other Tkinter windows which is why have been led to believe it is an underlying Tkinter problem rather than IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:51:04 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Jan 2018 15:51:04 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
 to BaseException.__new__
Message-ID: <1517154664.4.0.467229070634.issue1692335@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Please don't discuss on closed issues. Open a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:54:48 2018
From: report at bugs.python.org (pmpp)
Date: Sun, 28 Jan 2018 15:54:48 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1517154888.39.0.467229070634.issue32654@psf.upfronthosting.co.za>


pmpp <pmpp.pub at gmail.com> added the comment:

@yan12125
Hi, I ran some tests too and here are my findings:
 https://github.com/pmp-p/droid-pydk/tree/master/sources.32/build_logs

* I used some dirty patchset to cover more tests https://github.com/pmp-p/droid-pydk/tree/master/sources.32/cpython-bpo-30386.patchset i would be glad if you could have a look at them, as i am not a C/C++ programmer (i'm "pmpp" on IRC where we met last time).

* Maybe SIG* stuff is fixed only for unified headers API>=21 regardless of NDK that would need checking. 

* python build quite fine will all NDK ( sorry to say but especially the non vendor one can support cpython for prehistoric api and  version 3.5/3.6 *without patches* under certain condition of use )

my thoughts :

* Only third parties libs that have trouble with NDK versions, like openssl but libssl and libcrypto are provided by OS.

* Third parties are not required to embed libpython. Xavier de Gaye's script use shared linking. you should be able to provide whatever version of those you need that's not a cpython's build script job to deal with that, imho it was just for demontrasting that android build can be easy. I personnally would not build my third parties that way.

*  non official cpython build runs very well after android 5.0 there's almost nothing to do left, and micropython is able to run everywhere cpython can't (yet) so nothing is impossible.

* old api are frozen, there won't be suddenly a lot to support, when devices using them will vanish from asian stores it will mark the end of them and their need of support : imho there's no "end of life/support" concept for android os.

* I'd like a possible api19 "best effort", because android kitkat vendor statistics are wrong they don't take into account the *huge* amount of gservice-less devices.

unclear if unrelated to this:

* platform=='android' shoud be set, regardless of any API version : Android platform exists and is already running some pythons, it is a fact.

Thanks Victor for trying to clean my patchset : i did not realize my embed use of libpython could help official cpython too. Anyway I would be glad to help this way or another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:55:03 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Jan 2018 15:55:03 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1517153991.77.0.467229070634.issue26219@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJs4B5H2bWRmUVcoTV-d=i-JNYX-=PJmYMfZE9eq4As0Q@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

It's up to the release manager, but personally it feels like you're pushing
too hard. Since you've done that frequently in the past I think we should
help you by declining your request. 3.8 is right around the corner (on a
Python release timescale) and this will give people a nice incentive to
upgrade. Subsequent betas exist to stabilize the release, not to put in
more new stuff.

Now maybe we'll need to come up with a different way to do releases, but
that's more a python-dev discussion.

----------

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

From report at bugs.python.org  Sun Jan 28 10:57:36 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 15:57:36 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1517155056.75.0.467229070634.issue26219@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> It's up to the release manager, but personally it feels like you're pushing
too hard. Since you've done that frequently in the past I think we should
help you by declining your request.

NP, I totally understand.

> Now maybe we'll need to come up with a different way to do releases, but
that's more a python-dev discussion.

That would be great.

----------

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

From report at bugs.python.org  Sun Jan 28 11:00:11 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Jan 2018 16:00:11 +0000
Subject: [issue32228] truncate() changes current stream position
In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za>
Message-ID: <1517155211.55.0.467229070634.issue32228@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 059f58ce938d9c3f0286412a4efb1b9131339421 by Antoine Pitrou (Nitish Chandra) in branch 'master':
bpo-32228: Reset raw_pos after unwinding the raw stream (#4858)
https://github.com/python/cpython/commit/059f58ce938d9c3f0286412a4efb1b9131339421


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32228>
_______________________________________

From report at bugs.python.org  Sun Jan 28 11:10:21 2018
From: report at bugs.python.org (Greg Lindahl)
Date: Sun, 28 Jan 2018 16:10:21 +0000
Subject: [issue28414] SSL match_hostname fails for internationalized domain
 names
In-Reply-To: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za>
Message-ID: <1517155821.1.0.467229070634.issue28414@psf.upfronthosting.co.za>


Change by Greg Lindahl <lindahl at pbm.com>:


----------
nosy: +wumpus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28414>
_______________________________________

From report at bugs.python.org  Sun Jan 28 11:15:55 2018
From: report at bugs.python.org (Ofer)
Date: Sun, 28 Jan 2018 16:15:55 +0000
Subject: [issue32696] Fix pickling exceptions with multiple arguments
Message-ID: <1517156155.35.0.467229070634.issue32696@psf.upfronthosting.co.za>


New submission from Ofer <horowitz.ofer at gmail.com>:

Pickling exceptions fails when a custom exception class requires multiple arguments.

import pickle
class MultipleArgumentsError(Exception):
    def __init__(self, a, b):
        self.a = a
        self.b = b

pickle.loads(pickle.dumps(MultipleArgumentsError('a', 'b')))

this code produces the following error:

Traceback (most recent call last):
  File "/tmp/multiple_arguments_exception.py", line 8, in <module>
    pickle.loads(pickle.dumps(MultipleArgumentsError('a', 'b')))
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1388, in loads
    return Unpickler(file).load()
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 864, in load
    dispatch[key](self)
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1139, in load_reduce
    value = func(*args)
TypeError: __init__() takes exactly 3 arguments (2 given)


The same error occurs when using a built-in module like subprocess:
>>> import subprocess, pickle
>>> try:
...   subprocess.check_call(['python', '-c', 'raise SystemExit(1)'])
... except Exception as e:
...   pickle.loads(pickle.dumps(e))
... 


Related issue: https://bugs.python.org/issue1692335

----------
components: Interpreter Core
messages: 310963
nosy: alexandre.vassalotti, georg.brandl, jason.coombs, sbt, slallum, zseil
priority: normal
severity: normal
status: open
title: Fix pickling exceptions with multiple arguments
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32696>
_______________________________________

From report at bugs.python.org  Sun Jan 28 11:17:43 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 28 Jan 2018 16:17:43 +0000
Subject: [issue32691] "pdb -m <module>" sets __main__.__package__ incorrectly
In-Reply-To: <1517115891.43.0.467229070634.issue32691@psf.upfronthosting.co.za>
Message-ID: <1517156263.88.0.467229070634.issue32691@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In the backport, I found that `mod_spec.parent` seemed to be the right thing (in at least a few cases). Might that be preferable to `module_name.rpartition('.')[0]`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32691>
_______________________________________

From report at bugs.python.org  Sun Jan 28 11:36:00 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 16:36:00 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1517157360.56.0.467229070634.issue26219@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I concur with Guido and Nick; let's target this for 3.8.

----------

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

From report at bugs.python.org  Sun Jan 28 11:39:02 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 16:39:02 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1517157542.99.0.467229070634.issue32654@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Since we won't officially support Android in 3.7, these changes should wait for 3.8 and until there is a PEP for Android support.

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Sun Jan 28 11:42:58 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Jan 2018 16:42:58 +0000
Subject: [issue32228] truncate() changes current stream position
In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za>
Message-ID: <1517157778.75.0.467229070634.issue32228@psf.upfronthosting.co.za>


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


----------
pull_requests: +5224

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32228>
_______________________________________

From report at bugs.python.org  Sun Jan 28 11:55:27 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 16:55:27 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517158527.8.0.467229070634.issue32694@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

The good news is that, since Christian's recent enhancements in Issue32598 to have autoconf use pkg-config to detect OpenSSL header and lib files, configure will now automatically find the MacPorts OpenSSL as long as the MacPorts bin directory (typically /opt/local/bin) is in the shell PATH when you run configure.  MacPorts supplies pkg-config and .pc files for various packages it installs including OpenSSL. (Apple doesn't ship a copy of pkg-config with macOS).  I found this out by accident; thanks, Christian!  The current status quo is also more robust in that MacPorts is not necessarily installed in /opt/local, a problem with PR 5388 as it stands.  I install MacPorts from source to a non-standard location so it would be good for someone to verify that the current 3.7 configure works with a default (/opt/local) binary install of MacPorts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:04:42 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 17:04:42 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517159082.33.0.467229070634.issue32694@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The good news is that, since Christian's recent enhancements in Issue32598 to have autoconf use pkg-config to detect OpenSSL header and lib files, configure will now automatically find the MacPorts OpenSSL as long as the MacPorts bin directory (typically /opt/local/bin) is in the shell PATH when you run configure.

/opt/local/bin *is* in my shell's PATH and `./configure' still fails to auto-discover OpenSSL:

    ~ ? echo $PATH
    /Users/yury/dev/bin /opt/local/bin /opt/local/sbin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /usr/local/share/dotnet /Users/yury/dev/sys-venvs/fish/bin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:19:03 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 17:19:03 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517159943.02.0.467229070634.issue32694@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

OK, so the trick is to first install pkg-config:

   sudo port install pkgconfig
   ./configure
   make
   python -m ssl  # works

I'll close the PR then, but we need to document this trick with pkg-config somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:30:13 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 17:30:13 +0000
Subject: [issue32686] python3.6.4 build with --enable-optimzations hangs on
 macOS 10.13
In-Reply-To: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>
Message-ID: <1517160613.13.0.467229070634.issue32686@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Sorry, I wasn't clear but, yes, you will run into the same problem if you try to run the test suite with test_asyncio.  There are various ways to exclude specific tests (not particularly well-documented), one way is:

make test EXTRATESTOPTS='-x test_asyncio'

But, that said, building Python on current versions of macOS can be problematic in that Apple doesn't ship or, in the case of OpenSSL no longer ships, all of the third-party libraries and header files needed for a fully-functioning Python installation.  The Python Developer's Guide touches on this here:

https://devguide.python.org/setup/#build-dependencies

Depending on what you want to do with Python, you *might* be better off installing a pre-built one rather than trying to build it yourself.  Versions of Python 3.6.x for macOS 10.13 are available from https://www.python.org/downloads/ and from a number of third-party distributors like Homebrew, MacPorts, and others.  Good luck!

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:32:41 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 17:32:41 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517160761.68.0.467229070634.issue32694@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Good!  Yes, that should go into the devguide.  Unfortunately, it only works with 3.7+, so the CFLAGS/LDFLAGS stuff is still needed for 3.6- and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:40:22 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 28 Jan 2018 17:40:22 +0000
Subject: [issue32694] macos/configure: Discover OpenSSL when installed with
 MacPorts
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517161222.29.0.467229070634.issue32694@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:40:26 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 17:40:26 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517161226.53.0.467229070634.issue32690@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset a4d00012565d716db6e6abe1b8f33eaaa4de416e by Raymond Hettinger in branch 'master':
bpo-32690: Preserve order of locals() (#5379)
https://github.com/python/cpython/commit/a4d00012565d716db6e6abe1b8f33eaaa4de416e


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:41:32 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 28 Jan 2018 17:41:32 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517161292.66.0.467229070634.issue32690@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5225

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:42:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Jan 2018 17:42:33 +0000
Subject: [issue32228] truncate() changes current stream position
In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za>
Message-ID: <1517161353.95.0.467229070634.issue32228@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 1d896ed2cddada4455f40782e4120249defbfa70 by Antoine Pitrou in branch '3.6':
[3.6] bpo-32228: Reset raw_pos after unwinding the raw stream (GH-4858) (#5389)
https://github.com/python/cpython/commit/1d896ed2cddada4455f40782e4120249defbfa70


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32228>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:44:00 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Jan 2018 17:44:00 +0000
Subject: [issue32228] truncate() changes current stream position
In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za>
Message-ID: <1517161440.4.0.467229070634.issue32228@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've now pushed Nitish's fix to 3.7 and 3.6.   I have no interest in backporting to 2.7 at this point. Closing!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32228>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:48:42 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 28 Jan 2018 17:48:42 +0000
Subject: [issue32697] Guarantee that Python preserves the order of kwonly
 parameters
Message-ID: <1517161722.52.0.467229070634.issue32697@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Following on from the "Can Python guarantee the order of keyword-only parameters?", here's a patch to enforce that guarantee.  It adds documentation that makes the guarantee, and adds tests that make at least a passable attempt at testing that it's true.

I nosied everybody who +1'd my original proposal in python-dev, because I'm looking for someone to review the patch.  Beta 1 gets tagged on Sunday, so can someone rubber-stamp this today?

----------
assignee: larry
components: Interpreter Core
messages: 310975
nosy: eric.snow, gregory.p.smith, larry, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Guarantee that Python preserves the order of kwonly parameters
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:56:52 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 28 Jan 2018 17:56:52 +0000
Subject: [issue32697] Guarantee that Python preserves the order of kwonly
 parameters
In-Reply-To: <1517161722.52.0.467229070634.issue32697@psf.upfronthosting.co.za>
Message-ID: <1517162212.1.0.467229070634.issue32697@psf.upfronthosting.co.za>


Change by Larry Hastings <larry at hastings.org>:


----------
keywords: +patch
pull_requests: +5226

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:07:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 28 Jan 2018 18:07:05 +0000
Subject: [issue32697] Guarantee that Python preserves the order of kwonly
 parameters
In-Reply-To: <1517161722.52.0.467229070634.issue32697@psf.upfronthosting.co.za>
Message-ID: <1517162825.48.0.467229070634.issue32697@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:13:20 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 18:13:20 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517163200.1.0.467229070634.issue32690@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 9105879bfd7133ecbac67f3e9c0bacf6e477de5a by Raymond Hettinger (Miss Islington (bot)) in branch '3.6':
bpo-32690: Preserve order of locals() (GH-5379) (#5390)
https://github.com/python/cpython/commit/9105879bfd7133ecbac67f3e9c0bacf6e477de5a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:17:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 18:17:20 +0000
Subject: [issue32327] Make asyncio methods documented as coroutines -
 coroutines.
In-Reply-To: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za>
Message-ID: <1517163440.2.0.467229070634.issue32327@psf.upfronthosting.co.za>


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


----------
pull_requests: +5227

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32327>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:20:59 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 18:20:59 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517163659.35.0.467229070634.issue32690@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:22:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 18:22:17 +0000
Subject: [issue32621] Problem of consistency in collection.abc documentation
In-Reply-To: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za>
Message-ID: <1517163737.03.0.467229070634.issue32621@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32621>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:22:39 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 18:22:39 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517163759.27.0.467229070634.issue32690@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Why did this fix go to 3.6?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:37:33 2018
From: report at bugs.python.org (Adrien)
Date: Sun, 28 Jan 2018 18:37:33 +0000
Subject: [issue32698] Improper gzip compression if output file extension is
 not "gz"
Message-ID: <1517164653.32.0.467229070634.issue32698@psf.upfronthosting.co.za>


New submission from Adrien <delgan.py at gmail.com>:

Hello.

The following code produces a improper compressed "test.txt.gzip" file:

    import gzip
    import shutil
    
    input_path = "test.txt"
    output_path = input_path + ".gzip"
    
    with open(input_path, 'w') as file:
        file.write("abc" * 10)
    
    with gzip.open(output_path, 'wb') as f_out:
        with open(input_path, 'rb') as f_in:
            shutil.copyfileobj(f_in, f_out)

Although the content can be read correctly using `gzip.open(outputh_path, 'rb')`, it cannot be correctly opened using software like 7-Zip or WinRar.
If I open the "test.txt.gzip" file, it contains another "test.txt.gzip" file. If I change the code to use ".gz" extension and then open "test.txt.gz", it contains the expected "test.txt" file.
The contained "test.txt.gzip" is actually the same (at bytes level) that "test.txt", just the filename differs which causes tools like 7-Zip to mess up.

The bug is not present using compressions functions from "bz2" and "lzma" modules. I can use custom extension, it still can be (un)compressed without issue.

As to why I need to use an extension differents from ".gz": I would like to compress arbitrary ".tar" file given in input to ".tgz". I wish the user could open the file in his favorite software archiver and see that it contains a ".tar" file, rather than he does not understand why it contains the same ".tgz" file.

----------
components: Library (Lib)
files: test.py
messages: 310978
nosy: Delgan
priority: normal
severity: normal
status: open
title: Improper gzip compression if output file extension is not "gz"
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47414/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32698>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:42:13 2018
From: report at bugs.python.org (Kirill Balunov)
Date: Sun, 28 Jan 2018 18:42:13 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517164933.02.0.467229070634.issue28685@psf.upfronthosting.co.za>


Kirill Balunov <kirill.balunov at gmail.com> added the comment:

What is the current status of this issue and will it go into Python 3.7?

----------
nosy: +godaygo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:51:50 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 28 Jan 2018 18:51:50 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
Message-ID: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>


New submission from Thomas Kluyver <thomas at kluyver.me.uk>:

Nicholas Tollervey has been getting Pynsist to use the new pythonXY._pth file to assemble sys.path. However, I'm not clear on how this behaves with .pth files. The docs on this (https://docs.python.org/3/using/windows.html#finding-modules ) appear to contradict themselves:

> site is not imported unless one line in the file specifies import site
> ...
> Note that .pth files (without leading underscore) will be processed normally by the site module.

I can see two possibilities:

1. .pth files are processed normally if and only if the ._pth file specifies 'import site'. If it doesn't, they are ignored.
2. If a .pth file is encountered, site is imported to process it, but with sys.flags.nosite set, so that site doesn't do the normal stuff on import.

Some packages unfortunately seem to depend on .pth files getting processed, so if 1. is the case, Pynsist needs to ensure site is loaded.

Thanks :-)

----------
messages: 310980
nosy: steve.dower, takluyver
priority: normal
severity: normal
status: open
title: pythonXY._pth : unclear how .pth files are handled

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 14:09:42 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 19:09:42 +0000
Subject: [issue32327] Make asyncio methods documented as coroutines -
 coroutines.
In-Reply-To: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za>
Message-ID: <1517166582.27.0.467229070634.issue32327@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset bec2372b7e1da5dfdbadaf242aa8e994b164cace by Yury Selivanov in branch 'master':
bpo-32327: Revert loop.run_in_executor behaviour: return a Future. (#5392)
https://github.com/python/cpython/commit/bec2372b7e1da5dfdbadaf242aa8e994b164cace


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32327>
_______________________________________

From report at bugs.python.org  Sun Jan 28 14:13:07 2018
From: report at bugs.python.org (Emily Morehouse)
Date: Sun, 28 Jan 2018 19:13:07 +0000
Subject: [issue32689] shutil.move raises AttributeError if first argument is a
 pathlib.Path object and destination is a directory
In-Reply-To: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>
Message-ID: <1517166787.47.0.467229070634.issue32689@psf.upfronthosting.co.za>


Change by Emily Morehouse <emily at cuttlesoft.com>:


----------
keywords: +patch
pull_requests: +5228
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Sun Jan 28 14:13:12 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 28 Jan 2018 19:13:12 +0000
Subject: [issue32697] Guarantee that Python preserves the order of kwonly
 parameters
In-Reply-To: <1517161722.52.0.467229070634.issue32697@psf.upfronthosting.co.za>
Message-ID: <1517166791.99.0.467229070634.issue32697@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset f36ba12809d5db1b76464d8f1f04dad8d685ec78 by larryhastings in branch 'master':
bpo-32697: Definition order of kwonly params is now guaranteed preserved. (#5391)
https://github.com/python/cpython/commit/f36ba12809d5db1b76464d8f1f04dad8d685ec78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 14:13:57 2018
From: report at bugs.python.org (Emily Morehouse)
Date: Sun, 28 Jan 2018 19:13:57 +0000
Subject: [issue32689] shutil.move raises AttributeError if first argument is a
 pathlib.Path object and destination is a directory
In-Reply-To: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>
Message-ID: <1517166837.39.0.467229070634.issue32689@psf.upfronthosting.co.za>


Emily Morehouse <emily at cuttlesoft.com> added the comment:

Thanks for the bug report!

shutil.move should certainly accept a path object, as shutil.copy does, though it should be noted that in your example, 'path' could become out of date as it does not refresh the path information. For example, with shutil.move fixed:

    >>> import os, pathlib, shutil
    >>> os.mkdir('test1')
    >>>
    >>> os.mkdir('test2')
    >>> path = pathlib.Path('test1')
    >>> path.absolute()
    PosixPath('/Users/e/Development/OSS/cpython/test1')
    >>> shutil.move(path, 'test2')
    'test2/test1'
    >>> path.absolute()
    PosixPath('/Users/e/Development/OSS/cpython/test2')

test1 is now actually at '/Users/e/Development/OSS/cpython/test2/test1'


For the fix:
I did a bit of digging and the error comes from a helper method _basename that uses rstrip to remove a trailing separator, hence the error as rstrip doesn't exist for a path object (and I don't think it makes sense that it should, though that was one solution). Removing the trailing separator is, however, very important in determining the full destination path.

After trying a few different approaches, I think the simplest way is to cast the src to a string before finding its appropriate basename. I also added some comments to make it more clear why _basename is used over os.path.basename to hopefully save someone else time in the future.

A more robust option would be to explicitly handle Path objects or to handle exceptions for any dst that cannot be cast to a string. However, the current patch fixes the issue without introducing new problems.

----------
nosy: +emilyemorehouse

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Sun Jan 28 14:16:35 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 28 Jan 2018 19:16:35 +0000
Subject: [issue32697] Guarantee that Python preserves the order of kwonly
 parameters
In-Reply-To: <1517161722.52.0.467229070634.issue32697@psf.upfronthosting.co.za>
Message-ID: <1517166995.74.0.467229070634.issue32697@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Thanks for the quick turnaround reviews!  Today we've all collectively made Python a better programming language.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 14:22:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 19:22:35 +0000
Subject: [issue32697] Guarantee that Python preserves the order of kwonly
 parameters
In-Reply-To: <1517161722.52.0.467229070634.issue32697@psf.upfronthosting.co.za>
Message-ID: <1517167355.63.0.467229070634.issue32697@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Today we've all collectively made Python a better programming language.

Literally can't stop doing that for some reason... :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 14:43:45 2018
From: report at bugs.python.org (Craig Holmquist)
Date: Sun, 28 Jan 2018 19:43:45 +0000
Subject: [issue32689] shutil.move raises AttributeError if first argument is a
 pathlib.Path object and destination is a directory
In-Reply-To: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>
Message-ID: <1517168625.47.0.467229070634.issue32689@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

In my test, the second call to path.absolute() is just returning the same result as the first call, which is what I would expect (as you say, the path object doesn't update automatically).

However, your output shows it returning '/Users/e/Development/OSS/cpython/test2' instead of the (now broken) path from the first call.  Maybe I'm missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Sun Jan 28 15:18:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 20:18:32 +0000
Subject: [issue32221] Converting ipv6 address to string representation using
 getnameinfo() is wrong.
In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>
Message-ID: <1517170712.04.0.467229070634.issue32221@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Mark,

Two tests fail on MacOS X now (newly added tests).  I'm reverting the change for now.  If you figure this out, please re-submit a PR for a quick approval.


======================================================================
ERROR: test_getaddrinfo_ipv6_scopeid (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/yury/dev/pydev/cpython/Lib/test/test_socket.py", line 1612, in test_getaddrinfo_ipv6_scopeid
    ifindex = socket.if_nametoindex(test_interface)
OSError: no interface with this name

======================================================================
ERROR: test_getnameinfo_ipv6_scopeid (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/yury/dev/pydev/cpython/Lib/test/test_socket.py", line 1636, in test_getnameinfo_ipv6_scopeid
    nameinfo = socket.getnameinfo(sockaddr, socket.NI_NUMERICHOST | socket.NI_NUMERICSERV)
socket.gaierror: [Errno 4] Non-recoverable failure in name resolution

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

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Sun Jan 28 15:20:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 20:20:00 +0000
Subject: [issue32221] Converting ipv6 address to string representation using
 getnameinfo() is wrong.
In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>
Message-ID: <1517170800.42.0.467229070634.issue32221@psf.upfronthosting.co.za>


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


----------
pull_requests: +5229
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Sun Jan 28 15:20:43 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Jan 2018 20:20:43 +0000
Subject: [issue28414] SSL match_hostname fails for internationalized domain
 names
In-Reply-To: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za>
Message-ID: <1517170843.7.0.467229070634.issue28414@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5230

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28414>
_______________________________________

From report at bugs.python.org  Sun Jan 28 15:20:43 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Jan 2018 20:20:43 +0000
Subject: [issue31399] Let OpenSSL verify hostname and IP address
In-Reply-To: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
Message-ID: <1517170843.95.0.574204596225.issue31399@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5231

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31399>
_______________________________________

From report at bugs.python.org  Sun Jan 28 15:22:53 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Jan 2018 20:22:53 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1517170973.68.0.467229070634.issue17305@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

bpo-31399 has fixed hostname matching for IDNA 2003 compatible domain names. IDNA 2008 domain names with German ? are still broken, for example:

UnicodeError: ('IDNA does not round-trip', b'xn--knigsgchen-b4a3dun', b'xn--knigsgsschen-lcb0w')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Sun Jan 28 15:54:54 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 20:54:54 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517172894.87.0.467229070634.issue28685@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It would be really nice to have this into 3.7

----------
nosy: +rhettinger
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:01:54 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 28 Jan 2018 21:01:54 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <1517173314.19.0.467229070634.issue32688@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

We should probably delete the line regardless so no one else gets thrown by this (or at least leave a comment).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:02:35 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 21:02:35 +0000
Subject: [issue18369] X509 cert class for ssl module
In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za>
Message-ID: <1517173355.27.0.467229070634.issue18369@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

At Christian's request and considering the importance of the ssl module, I'm going to allow an extension for landing of this feature until 3.7.0b2, currently scheduled for 2018-02-26.  If anyone else can help Christian get this in before b2, that would be great.

----------
nosy: +ned.deily
priority: high -> deferred blocker
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18369>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:04:41 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 21:04:41 +0000
Subject: [issue28414] SSL match_hostname fails for internationalized domain
 names
In-Reply-To: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za>
Message-ID: <1517173481.3.0.467229070634.issue28414@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

At Christian's request and considering the importance of the ssl module, I'm going to allow an extension for landing of this feature until 3.7.0b2, currently scheduled for 2018-02-26.  If anyone else can help Christian get this in before b2, that would be great.  I'm removing older versions for now. We can discuss potential backports after the feature lands.

----------
nosy: +ned.deily
priority: normal -> deferred blocker
versions: +Python 3.8 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28414>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:08:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 21:08:34 +0000
Subject: [issue32221] Converting ipv6 address to string representation using
 getnameinfo() is wrong.
In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>
Message-ID: <1517173714.85.0.467229070634.issue32221@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 0ceb717689b04c0540d78c1ba93c0572c66c0994 by Yury Selivanov in branch 'master':
Revert "bpo-32221: makeipaddr(): remove interface part + speedup (GH-4724)" (#5394)
https://github.com/python/cpython/commit/0ceb717689b04c0540d78c1ba93c0572c66c0994


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:09:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Jan 2018 21:09:42 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
In-Reply-To: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>
Message-ID: <1517173782.31.0.467229070634.issue32611@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Looking at the animated .gif, Jim's problem has nothing to do with IDLE in particular, and is as least partly specific to his system, as I do not have the same problem on my system.  (That does not mean that improvements are not possible, so that reboots are not needed after updates.)

If one runs a file with python.exe that does not exit immediately, the taskbar icon is the 'Python Console icon, a dark console with blue title bar and text and the Python double snake overlaid.  If on runs a file with pythonw.exe (no console) that does not exit immediately, the taskbar icon should be the 'Python GUI' icon, a spiral-bound notebook page with folded upper right corner and the Python double snake overlaid.  The expected use case is a GUI program, such as a tkinter program, that runs an event loop until closed.  IDLE is just the prime example of such. Another example is the test program for this issue.

import tkinter as tk
r = tk.Tk()
r.mainloop()

When I name this file tem.py or tem.pyw and double-click, I get the respective Python icons.

Jim, the 'blank' icon you see when you double-click *.pyw is a white sheet of paper with the upper right corner folded.  It is the first one shown when the builtin icons are displayed.  It is used when Windows cannot find the proper icon for an application (or perhaps also when there is None).

Some while ago, after an update, my pinned Skype icon visually changed from the blue blob with white S to this default.  Yesterday, I right-clicked the folded page icon, right-clicked 'Skype, selected Properties, and then [Change Icon] on the Shortcut tab.

An error box popped up with a message similar to "%SystemRoot%\Installer\{3B7E914A-93D5-4A29-92BB-AF8C3F66C431}\SkypeIcon.exe cannot be found". My guess is that an update changed the uuid without updating the pinned icon, so the default folded page is the substitute.  When I clicked 'OK', the Change Icon dialog appeared.  When I browsed to the Skype directory, I did not find an icon file, so I clicked on Skype.exe instead, and that worked, and I again have the Skype icon on my taskbar.

Jim, I suggest you try the same, except navigate to 3.6 pythonw.exe.  Running 'import sys; sys.executable' shows the location.  If pythonw.exe has the proper icon, I expect that this should work.

----------
type: enhancement -> behavior
versions: +Python 3.6 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:10:15 2018
From: report at bugs.python.org (Allen)
Date: Sun, 28 Jan 2018 21:10:15 +0000
Subject: [issue32700] The replys additional (Re.) is ok.
Message-ID: <CAG3QrKuF2qDP8Lezwh9XhpiLpT-dTv0m8ZTWKvft2cswGoonmQ@mail.gmail.com>


New submission from Allen <Londonowl1973 at gmail.com>:

..

----------
messages: 310995
nosy: BIGAL
priority: normal
severity: normal
status: open
title: The replys additional (Re.) is ok.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32700>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:11:30 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 21:11:30 +0000
Subject: [issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with
 PROTOCOL_TLS
In-Reply-To: <1505317705.14.0.640405907228.issue31453@psf.upfronthosting.co.za>
Message-ID: <1517173890.73.0.467229070634.issue31453@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I'm not clear if this is still needed, i.e. has Debian backed off on their change across the board?  If it is still needed, I'm going to allow an extension for landing of it until 3.7.0b2, currently scheduled for 2018-02-26.  If anyone else can help Christian get this in before b2, that would be great.  I'm removing older versions for now. We can discuss potential backports after the code lands.

----------
priority: normal -> deferred blocker
versions: +Python 3.8 -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31453>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:12:56 2018
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 28 Jan 2018 21:12:56 +0000
Subject: [issue32693] os.path.ismount does not accept bytes objects
In-Reply-To: <1517138176.06.0.467229070634.issue32693@psf.upfronthosting.co.za>
Message-ID: <1517173976.5.0.467229070634.issue32693@psf.upfronthosting.co.za>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> support bytes paths in nt _getdiskusage, _getvolumepathname, and _getfinalpathname

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32693>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:24:07 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 28 Jan 2018 21:24:07 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517174647.65.0.467229070634.issue28685@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I agree it would be nice (very!) to get this in.  Indeed, I'm surprised to see that this is still open :-(

But who can drive it?  I cannot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:25:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 21:25:50 +0000
Subject: [issue31333] Implement ABCMeta in C
In-Reply-To: <1504472061.83.0.294667499276.issue31333@psf.upfronthosting.co.za>
Message-ID: <1517174750.38.0.467229070634.issue31333@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

There has been a lot of work by a number of people on this feature leading up to the 3.7.0b1.  Thank you!  On PR 5273, Yury says that he believes the feature is ready to merge but would prefer an extension until 3.7.0b2 and that Guido has agreed.  I'll defer to Yury's judgement on this and somewhat reluctantly allow an extension: there's a lot going on here.  Let's try to get it in as soon as we can, please!

----------
nosy: +ned.deily
priority: normal -> deferred blocker
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31333>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:28:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 21:28:00 +0000
Subject: [issue31333] Implement ABCMeta in C
In-Reply-To: <1504472061.83.0.294667499276.issue31333@psf.upfronthosting.co.za>
Message-ID: <1517174880.88.0.467229070634.issue31333@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Let's try to get it in as soon as we can, please!

Thank you, Ned!  We'll get it merged in the next few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31333>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:30:21 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 21:30:21 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517175021.78.0.467229070634.issue32690@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Why did this fix go to 3.6?

The patch is trivially small and fixes an odd an unnecessary implementation quirk.  Backporting will help avoid confusing dissimilarity between 3.6 and 3.7.  It also makes maintenance easier by keeping the versions in-sync (there are a number of precedents for this).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:30:28 2018
From: report at bugs.python.org (Robert Booth)
Date: Sun, 28 Jan 2018 21:30:28 +0000
Subject: [issue17048] calendar should understand full- vs. half-width
 characters
In-Reply-To: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za>
Message-ID: <1517175028.39.0.467229070634.issue17048@psf.upfronthosting.co.za>


Robert Booth <rob at ishigoya.com> added the comment:

There is similar misaligned output in Japanese and Korean:

Korean:
         1?                        2?                        3?
?  ?  ?  ?  ?  ?  ?       ?  ?  ?  ?  ?  ?  ?       ?  ?  ?  ?  ?  ?  ?
 1  2  3  4  5  6  7                1  2  3  4                1  2  3  4
 8  9 10 11 12 13 14       5  6  7  8  9 10 11       5  6  7  8  9 10 11

Japanese:
         1?                        2?                        3?
?  ?  ?  ?  ?  ?  ?       ?  ?  ?  ?  ?  ?  ?       ?  ?  ?  ?  ?  ?  ?
 1  2  3  4  5  6  7                1  2  3  4                1  2  3  4
 8  9 10 11 12 13 14       5  6  7  8  9 10 11       5  6  7  8  9 10 11

I came across this issue while using khal, a command-line calendar. That program also uses the calendar.LocaleTextCalendar class. I've raised an issue at https://github.com/pimutils/khal/issues/751

----------
nosy: +ishigoya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17048>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:30:29 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 21:30:29 +0000
Subject: [issue32251] Add asyncio.BufferedProtocol
In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za>
Message-ID: <1517175029.05.0.467229070634.issue32251@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 631fd38dbf04dbf0127881f3977982e401a849e4 by Yury Selivanov in branch 'master':
bpo-32251: Implement asyncio.BufferedProtocol. (#4755)
https://github.com/python/cpython/commit/631fd38dbf04dbf0127881f3977982e401a849e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32251>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:35:01 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 21:35:01 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517175301.4.0.467229070634.issue32690@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I don't have a strong opinion on this, but I worry a bit that while the change is trivial, it still might break something (doctests? some obscure code?) in the next 3.6 point release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:37:22 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 21:37:22 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517175442.05.0.467229070634.issue32690@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

While I appreciate the desirability of changing the behavior, it does introduce a behavior change in a 3.6.x maintenance release.  I don't have a good feel for the probability that current users or 3-party libraries are depending on the old behavior.  Anyone want to hazard a guess?  If there is a significantly non-zero probability, perhaps this should wait for 3.7.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:39:31 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 28 Jan 2018 21:39:31 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
In-Reply-To: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>
Message-ID: <1517175571.35.0.467229070634.issue32699@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

1 is correct. I don't see the contradiction - maybe you could purpose a rewording? (Perhaps it currently relies on the knowledge that the site module finds and processes .pth files? -S will also suppress it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:42:01 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 28 Jan 2018 21:42:01 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
In-Reply-To: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>
Message-ID: <1517175721.09.0.467229070634.issue32699@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:43:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 21:43:53 +0000
Subject: [issue32251] Add asyncio.BufferedProtocol
In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za>
Message-ID: <1517175833.53.0.467229070634.issue32251@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32251>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:45:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 21:45:10 +0000
Subject: [issue32221] Converting ipv6 address to string representation using
 getnameinfo() is wrong.
In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>
Message-ID: <1517175910.09.0.467229070634.issue32221@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Mark, I think this still land in beta-2.  Please try to figure out what's going on on Mac OS (I have no time to take care of this myself).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:47:22 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Jan 2018 21:47:22 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1517176042.97.0.467229070634.issue17305@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What we need for this issue is someone volunteering to writing the code.  Given how long it has already been, I don't think anyone already on the core team is going to pick it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:49:41 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 28 Jan 2018 21:49:41 +0000
Subject: [issue32695] tarfile.open() raises TypeError when using compresslevel
 parameter with LZMA
In-Reply-To: <1517152925.99.0.467229070634.issue32695@psf.upfronthosting.co.za>
Message-ID: <1517176181.01.0.467229070634.issue32695@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
keywords: +patch
pull_requests: +5232
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32695>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:51:03 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Jan 2018 21:51:03 +0000
Subject: [issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with
 PROTOCOL_TLS
In-Reply-To: <1505317705.14.0.640405907228.issue31453@psf.upfronthosting.co.za>
Message-ID: <1517176263.59.0.467229070634.issue31453@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The feature is still useful -- whether or not Debian disables TLS 1.0 and 1.1. The new API is easier to use and more convenient than the old bitmask approach. "option &=~OP_NO_SSLv3" is just horrible. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31453>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:58:52 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Jan 2018 21:58:52 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1517176732.95.0.467229070634.issue17305@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I lack the expertise and time to implement IDNA 2008 with UTS46 codec. I considered GNU libidn2, but the library requires two more helper libraries and LGPLv3 might be an issue for us.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:00:27 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Jan 2018 22:00:27 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517176827.11.0.467229070634.issue32690@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If you guys think the old code is better in some way, feel free to revert the backport :-)

I'm -0 on undoing the backpport.  ISTM that of all of changes to 3.6, this is one of the safest and it has minor benefits of removing a small irritant and keeping the code in-sync.  IIRC, 3.6 dict order is only assured for CPython but not for the language spec as a whole, so this is arguably a CPython buglet or least a surprising and unexpected behavior.  

While my instincts say forward-is-better-than-scrambled, I don't care much either way.  The only way it affects me is that as an educator, the reversed order is a unnecessary distraction from live demos that show the locals dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:02:28 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:02:28 +0000
Subject: [issue30715] Test_winreg, test_dynamic_key hangs on my Win 10
In-Reply-To: <1497978867.14.0.417332837919.issue30715@psf.upfronthosting.co.za>
Message-ID: <1517176948.92.0.467229070634.issue30715@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

What's the status of this issue?  It was previous marked as a "release blocker" and I subsequently downgraded it to a "deferred blocker" so as not to hold up releases.  Since a few maintenance releases have gone by without any action, I am removing the "deferred Blocker" status now.  Any one have any ideas?

----------
nosy: +eryksun
priority: deferred blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30715>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:08:09 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 28 Jan 2018 22:08:09 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
In-Reply-To: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>
Message-ID: <1517177289.24.0.467229070634.issue32699@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

I'd reword the second sentence like this:

> Note that .pth files (without leading underscore) will be processed only if this file specifies ``import site``.

The current wording sounds (to me) like a guarantee that .pth files will still be handled, despite the other things that this mechanism switches off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:10:27 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 28 Jan 2018 22:10:27 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1517177427.39.0.467229070634.issue17305@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

The "obvious" solution would be to move the "idna" module into the stdlib, but someone would still have to work that out, and it's clearly not happening for 3.7.

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:14:32 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:14:32 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517177672.5.0.467229070634.issue32690@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> If you guys think the old code is better in some way, feel free to revert the backport :-)

Hey, it's Guido's code, it must be good :)

My only concern is that this seems to be more of an issue of unspecified behavior rather than a bug and, as such, our general policy is that the status quo wins as far as changing behavior in a maintenance release.  I don't have a really strong feeling one way or another myself; I'm just trying to play devil's advocate on behalf of the user community.  Let's see if anyone else can make a case one way or another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:19:08 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:19:08 +0000
Subject: [issue31151] socketserver.ForkingMixIn.server_close() leaks zombie
 processes
In-Reply-To: <1502239239.94.0.0719119279673.issue31151@psf.upfronthosting.co.za>
Message-ID: <1517177948.22.0.467229070634.issue31151@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

What's the status of this?  Feature freeze is here!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31151>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:20:30 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:20:30 +0000
Subject: [issue31233] socketserver.ThreadingMixIn leaks running threads after
 server_close()
In-Reply-To: <1503073499.39.0.93886151367.issue31233@psf.upfronthosting.co.za>
Message-ID: <1517178030.77.0.467229070634.issue31233@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

What's the status of this?  Feature freeze is here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31233>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:21:52 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Jan 2018 22:21:52 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517177672.5.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJX2PmyDDskmPfe7kyxALMOA8EG1C3v2AUBENpAVbxVYQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I think consistency between the 3.6.x releases ought to win here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:27:15 2018
From: report at bugs.python.org (Martin Panter)
Date: Sun, 28 Jan 2018 22:27:15 +0000
Subject: [issue32698] Improper gzip compression if output file extension is
 not "gz"
In-Reply-To: <1517164653.32.0.467229070634.issue32698@psf.upfronthosting.co.za>
Message-ID: <1517178435.05.0.467229070634.issue32698@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

According to the documentation, you can use the lower-level GzipFile constructor?s ?filename? argument:

>>> with open(output_path, 'wb') as f_out, \
...     gzip.GzipFile(fileobj=f_out, mode='wb', filename=input_path) as f_out, \
...     open(input_path, 'rb') as f_in:
...         shutil.copyfileobj(f_in, f_out)
... 
>>> import os
>>> os.system("7z l test.txt.gzip")
[. . .]
   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2018-01-28 22:23:16 .....           30           34  test.txt
------------------- ----- ------------ ------------  ------------------------

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32698>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:27:40 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 22:27:40 +0000
Subject: [issue32373] Add socket.getblocking() method
In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za>
Message-ID: <1517178460.51.0.467229070634.issue32373@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset f11b460d8717fc3a5810684713b8b818f68789e8 by Yury Selivanov in branch 'master':
bpo-32373: Add socket.getblocking() method. (#4926)
https://github.com/python/cpython/commit/f11b460d8717fc3a5810684713b8b818f68789e8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32373>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:29:43 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:29:43 +0000
Subject: [issue31368] Add os.preadv() and os.pwritev()
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517178583.05.0.467229070634.issue31368@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

If I understand the discussion on the PR properly, Victor would like to revisit the documentation for this PR but is OK with the code as merged. I'm therefore downgrading this to "deferred blocker".  Please try to get the issue closed one way or another prior to 3.7.0b2, thanks!

----------
priority: release blocker -> deferred blocker
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:32:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Jan 2018 22:32:55 +0000
Subject: [issue31233] socketserver.ThreadingMixIn leaks running threads after
 server_close()
In-Reply-To: <1503073499.39.0.93886151367.issue31233@psf.upfronthosting.co.za>
Message-ID: <1517178775.33.0.467229070634.issue31233@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> What's the status of this?

The status is bad. The commit b8f4163da30e16c7cd58fe04f4b17e38d53cd57e is backward incompatible, it's not documented in the "Porting the Python 3.7" section of What's New in Python 3.7, and it's not possible to opt-in for the previous behaviour.


> Feature freeze is here.

IMHO it's ok to post-pone this issue to beta2.

IMHO it's better to wait until all threads complete on server_close(), and it's possible to workaround the issue using daemon_threads = True which can be seen as the option to opt-in for the previous behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31233>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:34:36 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 28 Jan 2018 22:34:36 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
In-Reply-To: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>
Message-ID: <1517178876.58.0.467229070634.issue32699@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +5233
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:36:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Jan 2018 22:36:32 +0000
Subject: [issue31151] socketserver.ForkingMixIn.server_close() leaks zombie
 processes
In-Reply-To: <1502239239.94.0.0719119279673.issue31151@psf.upfronthosting.co.za>
Message-ID: <1517178992.14.0.467229070634.issue31151@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> What's the status of this?  Feature freeze is here!

This issue is very to https://bugs.python.org/issue31233#msg311021 as it's status:
* The commit aa8ec34ad52bb3b274ce91169e1bc4a598655049 is backward incompatible and it's not documented
* There is no option to opt-in for the previous behaviour (exit without waiting for child processes)

For beta1, IMHO it's ok to keep the current status. But I would like to see this issue fixed before 3.7 final. Either revert my change, or do something else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31151>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:40:11 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:40:11 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1517179211.37.0.467229070634.issue30697@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

We should make a decision on this for both 3.6.5 and for 3.7.0. Victor, Antoine, Brett, Serhiy, any opinions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:46:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Jan 2018 22:46:22 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517179582.92.0.467229070634.issue28685@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I suggest to post-pone this optimization to Python 3.8. Faster list.sort() is nice to have, but I'm not sure that it's a killer feature that will make everybody move to Python 3.7. It can wait for 3.8.

No core dev took the lead on this non-trivial issue, and IMHO it's getting too late for 3.7.

It see that Serhiy started to review the change and asked for more benchmarks. Serhiy would be a good candidate to drive such work, but sadly he seems to be busy these days...

While such optimization is nice to have, we should be careful to not introduce a performance regressions on some cases. I read quickly the issue, and I'm not sure that it was fully carefully reviewed and tested yet. Sorry, I only read it quickly, ignore me if I'm wrong.

Well, if someone wants to take the responsability of pushing this right now, it's up to you :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:49:01 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:49:01 +0000
Subject: [issue31233] socketserver.ThreadingMixIn leaks running threads after
 server_close()
In-Reply-To: <1503073499.39.0.93886151367.issue31233@psf.upfronthosting.co.za>
Message-ID: <1517179741.21.0.467229070634.issue31233@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

If we're going to leave this open until 3.7.0b2, can you at least add a brief warning in the "Porting section" for b1 that the issue is unresolved?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31233>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:50:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Jan 2018 22:50:10 +0000
Subject: [issue32654] Fixes Python for Android API 19
In-Reply-To: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>
Message-ID: <1517179810.43.0.467229070634.issue32654@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

"""
>>> locale.setlocale(locale.LC_ALL, None)
...
locale.Error: locale query failed
"""

IMHO the correct fix here is to not define _locale.setlocale() to get the pure Python locale.setlocale() emulation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:51:15 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Jan 2018 22:51:15 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1517179875.91.0.467229070634.issue32226@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

What's the status of this?  The issue is still open with "release blocker" status.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Sun Jan 28 17:53:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Jan 2018 22:53:44 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1517180024.17.0.467229070634.issue26219@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Would it be OK if we add this to 3.7beta2?

IMHO we need more time than beta1=>beta2 window to review properly the design, test the implementation, fix any potential regression, etc.

Such change is perfect for the *start of a development cycle, but IMHO it's bad when are close to the *end*.

beta1=>final is supposed to only be made of bugfixes, not introducing new bugs... (I bet that adding any feature fatally introduces new bugs)

----------

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

From report at bugs.python.org  Sun Jan 28 17:54:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Jan 2018 22:54:05 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1517180045.55.0.467229070634.issue32226@psf.upfronthosting.co.za>


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


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:00:02 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 28 Jan 2018 23:00:02 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517180402.9.0.467229070634.issue32650@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +5234
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:18:40 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 23:18:40 +0000
Subject: [issue32373] Add socket.getblocking() method
In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za>
Message-ID: <1517181520.7.0.467229070634.issue32373@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32373>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:20:08 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Jan 2018 23:20:08 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1517181608.44.0.467229070634.issue32304@psf.upfronthosting.co.za>


Change by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
resolution:  -> fixed
stage: patch review -> backport needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:26:17 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Jan 2018 23:26:17 +0000
Subject: [issue12944] Better error message for "setup.py upload" missing
 sdist/bdist
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1517181977.48.0.467229070634.issue12944@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I had a patch for this, but now think it would be an attractive nuisance, given that distutils does not always ensure proper HTTPS verification.

Not adding the ability to build sdists/wheels, check them and then upload them will help push people to twine, which doesn?t have all the .pypirc parsing bugs and is a good HTTPS citizen.

I will however commit a patch to clarify the message ?no dist file created in earlier command?.

----------
nosy: +dstufft
title: Accept arbitrary files for distutils' upload command -> Better error message for "setup.py upload" missing sdist/bdist
type: enhancement -> behavior
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12944>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:28:32 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Jan 2018 23:28:32 +0000
Subject: [issue12944] Accept arbitrary files for distutils' upload command
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1517182112.92.0.467229070634.issue12944@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A doc ticket already exists, moving this one back to a feature request and closing it.

----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Better error message for setup.py upload command without sdist
title: Better error message for "setup.py upload" missing sdist/bdist -> Accept arbitrary files for distutils' upload command
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12944>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:31:50 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Jan 2018 23:31:50 +0000
Subject: [issue21060] Better error message for setup.py upload command without
 sdist/bdist
In-Reply-To: <1395737197.75.0.193444855893.issue21060@psf.upfronthosting.co.za>
Message-ID: <1517182310.15.0.467229070634.issue21060@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For improving the message, I am hesitating between adding to the existing message (hoping to help search engines find their way to improved docs):

?No dist file created in earlier command (e.g. setup.py sdist upload)? 

and rewriting it entirely:

?Must create and upload dist files in one command (e.g. setup.py sdist upload)?

----------
assignee:  -> eric.araujo
stage: needs patch -> patch review
title: Better error message for setup.py upload command without sdist -> Better error message for setup.py upload command without sdist/bdist
versions: +Python 3.6, Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21060>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:34:11 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 28 Jan 2018 23:34:11 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
In-Reply-To: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>
Message-ID: <1517182451.03.0.467229070634.issue32699@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 15ea3a6a320623328530e5d8da5b83c75766180b by Steve Dower in branch 'master':
bpo-32699: Improves doc for .pth files in presense of a ._pth file (#5399)
https://github.com/python/cpython/commit/15ea3a6a320623328530e5d8da5b83c75766180b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:34:50 2018
From: report at bugs.python.org (Julien Palard)
Date: Sun, 28 Jan 2018 23:34:50 +0000
Subject: [issue32701] Typo in quopri documentation
Message-ID: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

Spotted a typo in https://docs.python.org/3/library/quopri.html: "must be provideda"

But I also can't extract the meaning of the sentence:

> quotetabs, a flag which controls whether to encode embedded spaces and tabs must be provideda and when true it encodes such embedded whitespace, and when false it leaves them unencoded.

So here's the diff from 99597c4d12e358174275945d97e504c0318a3783:

+ *quotetabs*, a flag which controls whether to encode embedded spaces and tabs must be provideda and when true it encodes such embedded whitespace, and when false it leaves them unencoded.
- *quotetabs* is a flag which controls whether to encode embedded spaces and tabs; when true it encodes such embedded whitespace, and when false it leaves them unencoded.

So the "must be provided" has been added, I propose:

*quotetabs*, a non-optional flag which controls whether to encode embedded spaces and tabs; when true it encodes such embedded whitespace, and when false it leaves them unencoded.

----------
assignee: docs at python
components: Documentation
messages: 311033
nosy: docs at python, mdk, orsenthil
priority: low
severity: normal
status: open
title: Typo in quopri documentation
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:45:07 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Jan 2018 23:45:07 +0000
Subject: [issue32700] spam?
In-Reply-To: <CAG3QrKuF2qDP8Lezwh9XhpiLpT-dTv0m8ZTWKvft2cswGoonmQ@mail.gmail.com>
Message-ID: <1517183107.52.0.467229070634.issue32700@psf.upfronthosting.co.za>


Change by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> resolved
status: open -> closed
title: The replys additional (Re.) is ok. -> spam?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32700>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:47:34 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 28 Jan 2018 23:47:34 +0000
Subject: [issue32701] Typo in quopri documentation
In-Reply-To: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>
Message-ID: <1517183254.49.0.467229070634.issue32701@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks! I like your proposed change.

Please create the PR.

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:52:04 2018
From: report at bugs.python.org (Julien Palard)
Date: Sun, 28 Jan 2018 23:52:04 +0000
Subject: [issue32701] Typo in quopri documentation
In-Reply-To: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>
Message-ID: <1517183524.45.0.467229070634.issue32701@psf.upfronthosting.co.za>


Change by Julien Palard <julien+python at palard.fr>:


----------
keywords: +patch
pull_requests: +5235
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Sun Jan 28 19:15:23 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jan 2018 00:15:23 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1517184923.15.0.467229070634.issue32226@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I think all the critical things have been implemented/fixed. There are unfortunately no docs yet (my fault), also there are two bugs related to PEP 560, but they are not new, they also exist in Python 3.6.

I am however marking this as high priority, since these two bugs prevent progress on other projects (pickling generic classes), so it would be good to fix them before beta-2.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Sun Jan 28 19:21:14 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Jan 2018 00:21:14 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1517184923.15.0.467229070634.issue32226@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJK2_E3ax3qeJjkn636gDT77sSHwYOK9_zNmfUJdQ+QPWQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Are there more specific descriptions of those bugs? Links to a tracker?
(Even if it's the typing tracker.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Sun Jan 28 19:25:07 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 00:25:07 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517185507.62.0.467229070634.issue32650@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 46877024423e98d1b872bf308dacacd583327207 by Andrew Svetlov (Pablo Galindo) in branch 'master':
bpo-32650: Add native coroutine support to bdb when stepping over line (GH-5400)
https://github.com/python/cpython/commit/46877024423e98d1b872bf308dacacd583327207


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 19:31:08 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Jan 2018 00:31:08 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517185868.45.0.467229070634.issue32650@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5236

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 19:34:31 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Jan 2018 00:34:31 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517186071.41.0.467229070634.issue32650@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +5237

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 20:00:11 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jan 2018 01:00:11 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1517187611.18.0.467229070634.issue32226@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

https://github.com/python/typing/issues/512 and https://github.com/python/typing/issues/511 are first issue (they are closely related to each other). This is not directly related to PEP 560, but changes in typing because of it will allow to fix them in a simple manner.

The second one is Union simplification (was discussed in few PRs on typing tracker). This is not really a bug, but something we should decide on before 3.7 final. It will be difficult to change it later. Again, with PEP 560 in place the corresponding refactoring for removal should be straightforward.

In addition, there is https://github.com/python/typing/issues/392, this is already almost fixed by the typing PR implementing PEP 560, but it doesn't work for dunder attributes (I think we should not relay only specific set of reserved names, rather than all dunders).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Sun Jan 28 20:31:04 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 01:31:04 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517189464.02.0.467229070634.issue32650@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset c7ab581db216aeeb1c2aa7af2f2198d2b7516383 by Yury Selivanov (Pablo Galindo) in branch 'master':
bpo-32650 Add support for async generators and more test for coroutines in pdb  (#5403)
https://github.com/python/cpython/commit/c7ab581db216aeeb1c2aa7af2f2198d2b7516383


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 20:37:12 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 01:37:12 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517189832.73.0.467229070634.issue28685@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 20:56:13 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 29 Jan 2018 01:56:13 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517190973.19.0.467229070634.issue20104@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 6c6ddf97c402709713d668d0ed53836a7749ba99 by Gregory P. Smith (Pablo Galindo) in branch 'master':
bpo-20104: Expose `posix_spawn` in the os module (GH-5109)
https://github.com/python/cpython/commit/6c6ddf97c402709713d668d0ed53836a7749ba99


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Sun Jan 28 20:58:42 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 29 Jan 2018 01:58:42 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517191122.52.0.467229070634.issue20104@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

remaining work before closing this:
  Doc/library/os.rst needs to describe os.posix_spawn

----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Sun Jan 28 21:34:25 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 29 Jan 2018 02:34:25 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <1517193265.86.0.467229070634.issue32688@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5238

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:03:26 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 03:03:26 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517195006.06.0.467229070634.issue28685@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 1e34da49ef22004ca25c517b3f07c6d25f083ece by Raymond Hettinger (embg) in branch 'master':
bpo-28685: Optimize sorted() list.sort() with type-specialized comparisons (#582)
https://github.com/python/cpython/commit/1e34da49ef22004ca25c517b3f07c6d25f083ece


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:04:11 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 03:04:11 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517195051.98.0.467229070634.issue28685@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:22:16 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Jan 2018 03:22:16 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
In-Reply-To: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>
Message-ID: <1517196136.66.0.467229070634.issue32699@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Hopefully that's enough of a clarification.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:23:45 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 03:23:45 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517196225.61.0.467229070634.issue32650@psf.upfronthosting.co.za>


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


----------
pull_requests: +5239

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:32:14 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 29 Jan 2018 03:32:14 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <1517196734.8.0.467229070634.issue32688@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 997478eb797b31bd724135ca17781d1cf4b89cfa by Xiang Zhang in branch 'master':
bpo-32688: Make why the line is commented out clear (GH-5405)
https://github.com/python/cpython/commit/997478eb797b31bd724135ca17781d1cf4b89cfa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:32:37 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 29 Jan 2018 03:32:37 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <1517196757.56.0.467229070634.issue32688@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Done.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:39:29 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 29 Jan 2018 03:39:29 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517197169.14.0.467229070634.issue28685@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Thank you for giving this worthy orphan a home, Raymond!

Victor, don't fret too much.  The code is really quite simple, and at worst affects only `sorted()` and `list.sort()`.  The vast bulk of review effort (of which it got enough) went into dreaming up pathological cases (like mutating list elements, and even list element comparison methods, _while_ a sort was in progress).

I confess I didn't press for more benchmarks, because I don't care about more here:  the code is so obviously a major speed win when it applies, it so obviously applies often, and the new worst-case overhead when it doesn't apply is so obviously minor compared to the cost of a sort (`len(list)-1` wasted C-level pointer equality compares).  The only real value of timing benchmarks to me here was as a gross sanity check, and enough of those were run to confirm that all the preceding were qualitatively on target.  It really doesn't matter at all, e.g., whether the best cases are 2 times faster or 10 times faster, or the truly pathologal worst cases 10% slower or 20% slower.  Regardless, it's as close to a pure win as just about anything can be.

Nevertheless ... if this brings a major player's server to its knees, blame Raymond ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:43:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 03:43:48 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517197428.63.0.467229070634.issue32650@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 9ee1bf9ab5af8233ed8ec5c53d12a29dc1bd9c9d by Yury Selivanov in branch 'master':
bpo-32650: Add an asyncgen pdb test (#5406)
https://github.com/python/cpython/commit/9ee1bf9ab5af8233ed8ec5c53d12a29dc1bd9c9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:44:15 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 03:44:15 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517197455.56.0.467229070634.issue32650@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:44:32 2018
From: report at bugs.python.org (KINEBUCHI Tomohiko)
Date: Mon, 29 Jan 2018 03:44:32 +0000
Subject: [issue32702] Minor markup typo
Message-ID: <1517197472.5.0.467229070634.issue32702@psf.upfronthosting.co.za>


New submission from KINEBUCHI Tomohiko <cocoatomo77 at gmail.com>:

In the staticmethod document [1], code snippet should be a literal block, but actually be a block quote.
See the attached image file.

[1] https://docs.python.org/3.6/library/functions.html#staticmethod

----------
assignee: docs at python
components: Documentation
files: Screen Shot 2018-01-29 at 12.37.37.png
messages: 311048
nosy: cocoatomo, docs at python
priority: normal
severity: normal
status: open
title: Minor markup typo
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47415/Screen Shot 2018-01-29 at 12.37.37.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32702>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:47:19 2018
From: report at bugs.python.org (ppperry)
Date: Mon, 29 Jan 2018 03:47:19 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517197639.67.0.467229070634.issue28685@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

... and I'm still trying to come up with even more pathological mutating cases

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:52:21 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Jan 2018 03:52:21 +0000
Subject: [issue32688] weird comment out line of code
In-Reply-To: <1517196757.56.0.467229070634.issue32688@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W44uCasB0ru2SsLNJzBcKxxAZRKz-ksPOg2i_hXpAN4Vw@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

Thanks!

On Sun, Jan 28, 2018, 19:32 Xiang Zhang, <report at bugs.python.org> wrote:

>
> Xiang Zhang <angwerzx at 126.com> added the comment:
>
> Done.
>
> ----------
> versions:  -Python 3.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32688>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:52:40 2018
From: report at bugs.python.org (KINEBUCHI Tomohiko)
Date: Mon, 29 Jan 2018 03:52:40 +0000
Subject: [issue32702] Minor markup typo
In-Reply-To: <1517197472.5.0.467229070634.issue32702@psf.upfronthosting.co.za>
Message-ID: <1517197960.51.0.467229070634.issue32702@psf.upfronthosting.co.za>


Change by KINEBUCHI Tomohiko <cocoatomo77 at gmail.com>:


----------
keywords: +patch
pull_requests: +5240
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32702>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:54:28 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jan 2018 03:54:28 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517198068.93.0.467229070634.issue20104@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Pablo?s code looked unfinished to me. As well as missing documentation, I suspect there may be memory leaks and poor error handling.

The two calls above the ?fail:? label look like dead code. The ?parse_envlist? result appears to be leaked.

I?m curious why you never call ?posix_spawn_file_actions_destroy?. I saw on Open BSD <https://man.openbsd.org/posix_spawn_file_actions_init.3> it reclaims memory, and it seems sensible to call it on other platforms as well.

No error checking on any of the ?posix_spawn_file_actions_? methods.

If ?posix_spawn? fails, the ?pid? variable will be returned uninitialized.

----------
nosy: +martin.panter, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Sun Jan 28 23:06:16 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 04:06:16 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
Message-ID: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

Example (minimal version of https://github.com/python-trio/trio/issues/425):

-----

async def open_file():
    pass

async def main():
    async with open_file():  # Should be 'async with await open_file()'
        pass

coro = main()
coro.send(None)

-----

Here we accidentally left out an 'await' on the call to 'open_file', so the 'async with' tries to look up 'CoroutineType.__aexit__', which obviously doesn't exist, and the program crashes with an AttributeError("__aexit__"). Yet weirdly, this doesn't trigger a warning about 'open_file' being unawaited. It should!

Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to DECREF the object.

----------
components: asyncio
messages: 311052
nosy: asvetlov, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: 'async with' somehow suppresses unawaited coroutine warnings
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Sun Jan 28 23:10:22 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 04:10:22 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517199022.43.0.467229070634.issue32703@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to DECREF the object.

Nope, that doesn't seem to be it. This version prints "refcount: 2" twice, *and* prints a proper "was never awaited" warning:

-----

import sys

async def open_file():
    pass

async def main():
    open_file_coro = open_file()
    print("refcount:", sys.getrefcount(open_file_coro))

    try:
        async with open_file_coro:
            pass
    except:
        pass

    print("refcount:", sys.getrefcount(open_file_coro))

coro = main()
try:
    coro.send(None)
except:
    pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Sun Jan 28 23:23:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 04:23:41 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517199821.36.0.467229070634.issue32703@psf.upfronthosting.co.za>


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


----------
components: +Interpreter Core -asyncio
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Sun Jan 28 23:35:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 04:35:34 +0000
Subject: [issue32251] Add asyncio.BufferedProtocol
In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za>
Message-ID: <1517200534.33.0.467229070634.issue32251@psf.upfronthosting.co.za>


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


----------
pull_requests: +5241

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32251>
_______________________________________

From report at bugs.python.org  Sun Jan 28 23:43:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Jan 2018 04:43:00 +0000
Subject: [issue30715] Test_winreg, test_dynamic_key hangs on my Win 10
In-Reply-To: <1497978867.14.0.417332837919.issue30715@psf.upfronthosting.co.za>
Message-ID: <1517200980.41.0.467229070634.issue30715@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

test_winreg now works, taking about 5 seconds.  It has been working recently but I dont' know when or why the problem disappeared.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30715>
_______________________________________

From report at bugs.python.org  Sun Jan 28 23:51:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 04:51:11 +0000
Subject: [issue32251] Add asyncio.BufferedProtocol
In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za>
Message-ID: <1517201471.05.0.467229070634.issue32251@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 07627e9a6a5f418354ff3dc99a0f36bc5b79dcd8 by Yury Selivanov in branch 'master':
bpo-32251: Fix docs (#5408)
https://github.com/python/cpython/commit/07627e9a6a5f418354ff3dc99a0f36bc5b79dcd8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32251>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:01:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 05:01:23 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1517202083.52.0.467229070634.issue23749@psf.upfronthosting.co.za>


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


----------
pull_requests: +5242
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:06:08 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 05:06:08 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1517202368.31.0.467229070634.issue30491@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> So let's retarget this to 3.8 as it's too close to 3.7 feature freeze to get seriously considered/merged.

I *think* I have a better idea than this for 3.8, but it's definitely PEP-sized. The unawaited coroutine tracking proposal here was more conceived as a small, unobtrusive thing that could be added to 3.7 and marked provisional, to hold us over until 3.8. (Just this week I've spent time helping two people who were having trouble with forgetting 'await's, and this feature would have given them better errors -- though one was also affected by bpo-32703.)  OTOH the issue is complicated enough that it's entirely possibly my "better idea" has missed some showstopper detail, in which case maybe this is the best solution after all. We'll have plenty to talk about at PyCon this year :-).

Also, looking at the issue log here there's a ton of missing context from all the discussions that happened elsewhere this year and eventually led to this particular proposal; I'll try to make a list of links and post it here for future reference and archaeologists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:13:25 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Mon, 29 Jan 2018 05:13:25 +0000
Subject: [issue17048] calendar should understand full- vs. half-width
 characters
In-Reply-To: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za>
Message-ID: <1517202805.57.0.467229070634.issue17048@psf.upfronthosting.co.za>


Change by Chason Chaffin <chason at gmail.com>:


----------
nosy: +chason.chaffin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17048>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:25:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 05:25:08 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1517203508.21.0.467229070634.issue23749@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 1e5b25b8c0c45ccfd58da2cb82fdf231c6823fef by Yury Selivanov in branch 'master':
bpo-23749: Make start-tls tests more stable on win7 buildbot (GH-5409)
https://github.com/python/cpython/commit/1e5b25b8c0c45ccfd58da2cb82fdf231c6823fef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:36:50 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 29 Jan 2018 05:36:50 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517204210.25.0.467229070634.issue32703@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looking at the ceval code, I think Yury's theory is plausible, and we may also be leaving the interpreter's internal stack in a dubious state. Things then get cleaned up if you wrap the async with in a try/except or try/finally:

==============
>>> async def try_main():
...     try:
...         async with open_file():
...             pass
...     finally:
...         pass
... 
>>> try_main().send(None)
sys:1: RuntimeWarning: coroutine 'open_file' was never awaited
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in try_main
AttributeError: __aexit__
==============

Unfortunately for that theory, adding braces and "Py_DECREF(POP());" to the relevant error handling branch *doesn't* fix the problem.

I also found another way to provoke similar misbehaviour without async with:

==========
>>> async def open_file():
...     pass
... 
>>> open_file()
<coroutine object open_file at 0x7f92fe19c548>
>>> _
<coroutine object open_file at 0x7f92fe19c548>
>>> 1
__main__:1: RuntimeWarning: coroutine 'open_file' was never awaited
1
>>> open_file()
<coroutine object open_file at 0x7f92fe19c548>
>>> del _
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '_' is not defined
>>> _
<coroutine object open_file at 0x7f92fe19c548>
>>> 1
1
>>> _
1
>>> 
==========

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:49:48 2018
From: report at bugs.python.org (Allen)
Date: Mon, 29 Jan 2018 05:49:48 +0000
Subject: [issue32704] Tracking
Message-ID: <CAG3QrKsc3mRMLR7rfJr9SDoeKGtZ+OfbFFi_9jDWcogP608vRQ@mail.gmail.com>


New submission from Allen <Londonowl1973 at gmail.com>:

Could someone help me use python to track the tArget phones location and i
would like to intercepts all text and emaIl.

..

----------
messages: 311059
nosy: BIGAL
priority: normal
severity: normal
status: open
title: Tracking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32704>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:51:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 05:51:34 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517205094.51.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Changing

  async def main():
    async with open_file():
      pass

to

  async def main():
    c = open_file()
    async with c:
      pass

also makes it print the warning :)

Also I've made a test out of this snippet and running tests in refleak mode shows that there's indeed no refleak here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:53:27 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 05:53:27 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517205207.05.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The difference between these two functions is two extra opcodes: STORE_FAST/LOAD_FAST before BEFORE_ASYNC_WITH.  With them we have a warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:55:54 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 05:55:54 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517205354.96.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

So refactoring it into "c = open_file(); async with c" just prolongs the life of the coroutine so that it's GCed outside of WITH_CLEANUP_START/WITH_CLEANUP_FINISH block.  Something weird is going on in that block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:57:09 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 05:57:09 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517205429.65.0.467229070634.issue32650@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 543ec005a4c83fcc0d14ac1e4c0f1a36bf84640b by Andrew Svetlov (Miss Islington (bot)) in branch '3.6':
bpo-32650: Add native coroutine support to bdb when stepping over line (GH-5400) (#5402)
https://github.com/python/cpython/commit/543ec005a4c83fcc0d14ac1e4c0f1a36bf84640b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:57:56 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 05:57:56 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517205476.96.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Ah, we should never really get to WITH_CLEANUP_START; the exception should be raised in BEFORE_ASYNC_WITH

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:15:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 06:15:49 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517206549.76.0.467229070634.issue32703@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5243
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:18:54 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 06:18:54 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517206734.33.0.467229070634.issue32650@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +5244

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:20:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 06:20:02 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517206802.68.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

So the problem was that _PyGen_Finalize wasn't issuing any warnings if there's any error set in the current tstate.  And in Nathaniel's case, the current error was an AttributeError('__aexit__').

This check is weird, because right before raising the warning, we call PyErr_Fetch to temporarily reset the current exception if any, specifically to raise the warning :)

The PR just removes the check.  Unless I'm missing something this should fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:21:25 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 06:21:25 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517206885.46.0.467229070634.issue32703@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Well, I feel silly then: bpo-32605

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:22:04 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 06:22:04 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1517206924.11.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Nathaniel,

test_coroutines raises a bunch of Runtime and Deprecation warnings after this PR.  Could you please make a PR to silence them?


/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:1032: RuntimeWarning: coroutine 'CoroutineTest.test_await_12.<locals>.coro' was never awaited
  return await Awaitable()
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:37: RuntimeWarning: coroutine 'CoroutineTest.test_await_9.<locals>.bar' was never awaited
  buffer.append(coro.send(None))
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:681: RuntimeWarning: coroutine 'CoroutineTest.test_func_13.<locals>.g' was never awaited
  g().send('spam')
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:534: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  list(foo())
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:537: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  tuple(foo())
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:540: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  sum(foo())
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:543: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  iter(foo())
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:564: RuntimeWarning: coroutine 'CoroutineTest.test_func_5.<locals>.foo' was never awaited
  for el in foo(): pass
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:1984: DeprecationWarning: get_coroutine_wrapper is deprecated
  self.assertIs(sys.get_coroutine_wrapper(), wrap)
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:1991: DeprecationWarning: set_coroutine_wrapper is deprecated
  sys.set_coroutine_wrapper(None)
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:1993: DeprecationWarning: get_coroutine_wrapper is deprecated
  self.assertIsNone(sys.get_coroutine_wrapper())
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:2001: DeprecationWarning: get_coroutine_wrapper is deprecated
  self.assertIsNone(sys.get_coroutine_wrapper())
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:2003: DeprecationWarning: set_coroutine_wrapper is deprecated
  sys.set_coroutine_wrapper(1)
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:2004: DeprecationWarning: get_coroutine_wrapper is deprecated
  self.assertIsNone(sys.get_coroutine_wrapper())
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:2015: DeprecationWarning: set_coroutine_wrapper is deprecated
  sys.set_coroutine_wrapper(wrapper)
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:2024: DeprecationWarning: set_coroutine_wrapper is deprecated
  sys.set_coroutine_wrapper(None)
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:2037: DeprecationWarning: set_coroutine_wrapper is deprecated
  sys.set_coroutine_wrapper(wrap)
/Users/yury/dev/pydev/cpython/Lib/test/test_coroutines.py:2045: DeprecationWarning: set_coroutine_wrapper is deprecated
  sys.set_coroutine_wrapper(None)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:25:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 06:25:06 +0000
Subject: [issue32605] Should we really hide unawaited coroutine warnings when
 an exception is pending?
In-Reply-To: <1516426250.01.0.467229070634.issue32605@psf.upfronthosting.co.za>
Message-ID: <1517207106.56.0.467229070634.issue32605@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

So in issue 32703 we consider removing the check.  I'll try to figure out what to do with "coroutine ... was never awaited" warnings in test_coroutines -- probably just silence them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32605>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:25:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 06:25:32 +0000
Subject: [issue27968] test_coroutines generates some warnings
In-Reply-To: <1473143351.91.0.450663771383.issue27968@psf.upfronthosting.co.za>
Message-ID: <1517207132.14.0.467229070634.issue27968@psf.upfronthosting.co.za>


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


----------
pull_requests: +5245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27968>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:25:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 06:25:37 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1517207137.65.0.467229070634.issue32591@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Specifically "DeprecationWarning: get_coroutine_wrapper is deprecated" needs to be silenced as part of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:28:14 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 06:28:14 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1517207294.08.0.467229070634.issue32591@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Ah, gotcha. I'll take a look. (For posterity: the RuntimeWarnings Yury mentioned are also real, but they're from the branch Yury is testing for bpo-32605 / bpo-32703, nothing to do with this issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:38:53 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 29 Jan 2018 06:38:53 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517207933.53.0.467229070634.issue32703@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, and in my REPL example, the NameError was pending when the internal result storage was getting set back to None.

I'm not sure I even knew the "Don't complain when an exception is pending" check existed, so it would have taken me a long time to find that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:47:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 06:47:49 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517208469.92.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I knew about that "if", but it never fully registered to me why it's there and what it is protecting us from ;) So I had to debug half of ceval loop before I stumbled upon it again ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:51:09 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 06:51:09 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517208669.31.0.467229070634.issue32650@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 3cfb84c65790f5f9377574f9be0799bdd9d0132c by Andrew Svetlov in branch '3.6':
[3.6] bpo-32650 Add support for async generators and more test for coroutines in pdb  (GH-5403). (#5411)
https://github.com/python/cpython/commit/3cfb84c65790f5f9377574f9be0799bdd9d0132c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Mon Jan 29 01:59:43 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 06:59:43 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1517209183.16.0.467229070634.issue32591@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
pull_requests: +5246
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:00:04 2018
From: report at bugs.python.org (Jaysinh shukla)
Date: Mon, 29 Jan 2018 07:00:04 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1517209204.55.0.467229070634.issue29571@psf.upfronthosting.co.za>


Jaysinh shukla <jaysinhp at gmail.com> added the comment:

Hello Nick,

    At the devsprints of Pycon India 2017, a few participants were facing this bug. They all were from the Ubuntu land. I have switched to Gentoo distro. I am not facing this bug, but let me confirm from any Ubuntu user. Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29571>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:07:30 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 07:07:30 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517209650.23.0.467229070634.issue32550@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

There are a couple of merge conflicts in the patch.  Once deconflicted, I think this PR is ready to apply.

----------
assignee:  -> Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:21:06 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 29 Jan 2018 07:21:06 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1517210466.91.0.467229070634.issue29571@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've also added Matthias and Barry to the cc list, in case this does turn out to be a Debian or Ubuntu specific quirk.

Restating the problem, the issue is that test_locale_flag in test_re may fail for at least the en_IN locale, and we're not sure yet whether that's a test bug, a locale module bug, or a distro bug:

    LANG=en_IN ./python -m test -v test_re

We've only confirmed it on Ubuntu so far though - I haven't been able to reproduce it on Fedora, and Jaysinh hasn't been able to reproduce it since switching to Gentoo.

----------
nosy: +barry, doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29571>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:34:28 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 07:34:28 +0000
Subject: [issue32591] Deprecate sys.set_coroutine_wrapper and replace it with
 more focused API(s)
In-Reply-To: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>
Message-ID: <1517211268.27.0.467229070634.issue32591@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:


New changeset 95e214713a7da4e5cbfb73f35b2119f76074fc3f by Nathaniel J. Smith in branch 'master':
bpo-32591: silence deprecation warnings in test_coroutine (GH-5412)
https://github.com/python/cpython/commit/95e214713a7da4e5cbfb73f35b2119f76074fc3f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:42:18 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 29 Jan 2018 07:42:18 +0000
Subject: [issue32705] Current Android does not have posix_spawn
Message-ID: <1517211738.51.0.467229070634.issue32705@psf.upfronthosting.co.za>


New submission from Chih-Hsuan Yen <yan12125 at gmail.com>:

Currently Android does not have posix_spawn, thus posixmodule.c does not build. Build log attached. I'll create a patch for this.

Testing environment: my building scripts [1] + Android NDK r16b
Building target: ARM64, android-21

/cc Primary reviewer of issue 20104 and Android enthusiasts in CPython

PS. Looks like posix_spawn will be available in Android P (API 28) [2]. For now I propose to disable it in CPython.

[1] https://github.com/yan12125/python3-android/
[2] https://android-review.googlesource.com/c/platform/bionic/+/504842

----------
components: Cross-Build
files: build.log
messages: 311078
nosy: Alex.Willmer, gregory.p.smith, vstinner, yan12125
priority: normal
severity: normal
status: open
title: Current Android does not have posix_spawn
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file47416/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32705>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:49:14 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 29 Jan 2018 07:49:14 +0000
Subject: [issue32705] Current Android does not have posix_spawn
In-Reply-To: <1517211738.51.0.467229070634.issue32705@psf.upfronthosting.co.za>
Message-ID: <1517212154.98.0.467229070634.issue32705@psf.upfronthosting.co.za>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
keywords: +patch
pull_requests: +5247
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32705>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:53:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 07:53:31 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517212411.9.0.467229070634.issue25988@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5248
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:13:33 2018
From: report at bugs.python.org (7stud)
Date: Mon, 29 Jan 2018 08:13:33 +0000
Subject: [issue32686] python3.6.4 build hangs on test_asyncio macOS 10.13
In-Reply-To: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>
Message-ID: <1517213613.53.0.467229070634.issue32686@psf.upfronthosting.co.za>


Change by 7stud <7stud at excite.com>:


----------
title: python3.6.4 build with --enable-optimzations hangs on macOS 10.13 -> python3.6.4 build hangs on test_asyncio macOS 10.13

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:17:38 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 29 Jan 2018 08:17:38 +0000
Subject: [issue32699] pythonXY._pth : unclear how .pth files are handled
In-Reply-To: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>
Message-ID: <1517213858.12.0.467229070634.issue32699@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

Thanks Steve, that looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:19:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 08:19:46 +0000
Subject: [issue31368] Add os.preadv() and os.pwritev()
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517213986.99.0.467229070634.issue31368@psf.upfronthosting.co.za>


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


----------
pull_requests: +5249

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:22:48 2018
From: report at bugs.python.org (7stud)
Date: Mon, 29 Jan 2018 08:22:48 +0000
Subject: [issue32686] python3.6.4 build hangs on test_asyncio macOS 10.13
In-Reply-To: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>
Message-ID: <1517214168.59.0.467229070634.issue32686@psf.upfronthosting.co.za>


7stud <7stud at excite.com> added the comment:

Thanks for getting back to me Ned!  I'll just install a pre-built python, then. In the past, I've always installed python via a .tgz file, so out of habit that is what I tried first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:34:17 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Jan 2018 08:34:17 +0000
Subject: [issue32702] Minor markup typo
In-Reply-To: <1517197472.5.0.467229070634.issue32702@psf.upfronthosting.co.za>
Message-ID: <1517214857.53.0.467229070634.issue32702@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5250

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32702>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:36:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 08:36:21 +0000
Subject: [issue31233] socketserver.ThreadingMixIn leaks running threads after
 server_close()
In-Reply-To: <1503073499.39.0.93886151367.issue31233@psf.upfronthosting.co.za>
Message-ID: <1517214981.31.0.467229070634.issue31233@psf.upfronthosting.co.za>


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


----------
pull_requests: +5251

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31233>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:36:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 08:36:21 +0000
Subject: [issue31151] socketserver.ForkingMixIn.server_close() leaks zombie
 processes
In-Reply-To: <1502239239.94.0.0719119279673.issue31151@psf.upfronthosting.co.za>
Message-ID: <1517214981.4.0.574204596225.issue31151@psf.upfronthosting.co.za>


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


----------
pull_requests: +5252
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31151>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:36:46 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Jan 2018 08:36:46 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517215006.7.0.467229070634.issue20104@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +5253

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:37:26 2018
From: report at bugs.python.org (Robert Booth)
Date: Mon, 29 Jan 2018 08:37:26 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1517215046.75.0.467229070634.issue12568@psf.upfronthosting.co.za>


Change by Robert Booth <rob at ishigoya.com>:


----------
nosy: +ishigoya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:37:46 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Jan 2018 08:37:46 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517215066.21.0.467229070634.issue20104@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have opened a PR to address this issues:

https://github.com/python/cpython/pull/5415

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 03:45:28 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 08:45:28 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1517215528.72.0.467229070634.issue30491@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Okay, more context for future archaelogists / me in 6 months, phrased in the form of a timeline:

This discussion started back in March, when I made an issue on the trio tracker [1] with notes on rough edges in CPython that it might make sense to try to target for 3.7; Brett, Yury, Nick, Dave Beazley, Matthias Bussonier joined in and it quickly turned into a discussion around the question of "is there anything we can do to improve developer experience when they forget an await?". Various impractical ideas were brainstormed / critiqued / prototyped.

>From discussions at PyCon in May, I realized that while catching missing 'await' where they happen is very difficult, an unobtrusive tweak to the interpreter might allow catching them soon after they happen; that's when I filed this issue (bpo-30491) with a vague initial proposal [2]. Matthias also did some work on prototyping this using set_coroutine_wrapper [3]

End of August/beginning of September: more detailed analysis of various tricky edge cases refined this into an design that could actually work [4]; checked with pytest-asyncio devs for their thoughts [5].

Early/Mid December 2017: uh oh, feature freeze is less than 2 months away, better get moving; I posted a full proposal here [6]. After a few rounds of hashing out the basic idea here in the issue tracker, we seemed to have consensus that this was a reasonable approach, but (a) would it be better to add the feature to the interpreter, or to put it in a third-party library using set_coroutine_wrapper? and (b) how do we get this and asyncio debug mode to work together, like you'd want, instead of clashing over the coroutine wrapper and generally making a mess?

Mid January 2018: Yury re-emerges from vacation, and in more discussions we realized that implementing "origin tracking" and "unawaited tracking" as built-in features would not only cover all the use cases, but would also open up origin tracking to other async frameworks, allow the two tools to complement each other instead of colliding, and let us deprecate set_coroutine_wrapper (which is a pretty obviously terrible API, much uglier than the two more specialized features here). So I filed bpo-32591 and wrote a patch for it, which was merged, and then reworked my prototype for this (bpo-30491) into something reviewable (gh-5279).

Tuesday: Yury realized "oh $#@ in all of that we never talked to Guido" [7]. Lesson learned!

[1] https://github.com/python-trio/trio/issues/79
[2] https://bugs.python.org/issue30491#msg294584
    https://github.com/python-trio/trio/issues/79#issuecomment-304428955
[3] https://github.com/python-trio/trio/pull/176
[4] https://github.com/python-trio/trio/issues/79#issuecomment-325188030
[5] https://github.com/pytest-dev/pytest-asyncio/issues/67
[6] https://bugs.python.org/issue30491#msg308090
[7] https://bugs.python.org/issue30491#msg310559

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Mon Jan 29 04:01:26 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 29 Jan 2018 09:01:26 +0000
Subject: [issue32704] Tracking
In-Reply-To: <CAG3QrKsc3mRMLR7rfJr9SDoeKGtZ+OfbFFi_9jDWcogP608vRQ@mail.gmail.com>
Message-ID: <1517216486.42.0.467229070634.issue32704@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This list is for the development of python, not for help with using python.

I suggest you ask your question on the python-list mailing list: https://mail.python.org/mailman/listinfo/python-list

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32704>
_______________________________________

From report at bugs.python.org  Mon Jan 29 04:25:03 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 09:25:03 +0000
Subject: [issue32702] Minor markup typo
In-Reply-To: <1517197472.5.0.467229070634.issue32702@psf.upfronthosting.co.za>
Message-ID: <1517217903.5.0.467229070634.issue32702@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32702>
_______________________________________

From report at bugs.python.org  Mon Jan 29 04:50:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 09:50:43 +0000
Subject: [issue32705] Current Android does not have posix_spawn
In-Reply-To: <1517211738.51.0.467229070634.issue32705@psf.upfronthosting.co.za>
Message-ID: <1517219443.18.0.467229070634.issue32705@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 8997f9cd1a59f04fbb8c7b590295a9f38c548744 by Victor Stinner (Chih-Hsuan Yen) in branch 'master':
bpo-32705: Current Android does not have posix_spawn (#5413)
https://github.com/python/cpython/commit/8997f9cd1a59f04fbb8c7b590295a9f38c548744


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32705>
_______________________________________

From report at bugs.python.org  Mon Jan 29 05:03:27 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jan 2018 10:03:27 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517220207.17.0.467229070634.issue20104@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Does the PySequence_Fast result need releasing if the following ?for? loop fails? There is a Py_DECREF only in the successful case, which seems inconsistent.

Does Python still support non-UTF-8 locales and bytes filenames? I haven?t been keeping up, but I assumed these things were still supported in many cases. It seems strange to only support UTF-8 in the ?addopen? file action.

Pablo?s second PR currently <https://github.com/python/cpython/pull/5418/commits/e50bdb9> calls PyErr_SetString(PyExc_OSError, . . .) with a custom error message depending on which OS call failed. But I wonder if it is more important to set the ?errno? attribute (which I think should choose an OSError subclass if appropriate). Perhaps you can do that by assigning the return values to ?errno? and then calling PyErr_SetFromErrno. A disadvantage might be less context about which stage went wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 05:14:48 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Jan 2018 10:14:48 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517220888.75.0.467229070634.issue32650@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5254

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Mon Jan 29 05:34:43 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jan 2018 10:34:43 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517222083.4.0.467229070634.issue20104@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

TypeError if ?posix_spawn_file_actions_init? fails doesn?t seem right. I suggest OSError, MemoryError, or even plain Exception instead.

?File_actionsp? is set to point to a local variable ?_file_actions?, but the variable goes out of scope before the pointer is used. This is technically undefined behaviour (even if it happens to work). Simplest solution would be to move the variables into the same outer scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 05:41:36 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 10:41:36 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517222496.63.0.467229070634.issue32650@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset d9c743b2d118530ca13a8e29f96f30950866bd56 by Andrew Svetlov (Miss Islington (bot)) in branch '3.6':
bpo-32650: Add an asyncgen pdb test (GH-5406) (#5419)
https://github.com/python/cpython/commit/d9c743b2d118530ca13a8e29f96f30950866bd56


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Mon Jan 29 05:56:21 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Jan 2018 10:56:21 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517223381.65.0.467229070634.issue20104@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Regarding the leak, I was under the assumption that as File_actionsp is pointing to a stack initialized _file_actions and is this last variable the one that is passed to posix_spawn_file_actions_init, it was not needed to explicitly call posix_spawn_file_actions_destroy as the variable will go out of scope and the pointer is pointing to a stack variable. Am I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 05:57:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 10:57:20 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517223440.85.0.467229070634.issue20891@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I ran pyperformance on my PR 4700. Differences of at least 5%: (...)

I tested again these 5 benchmarks were Python was slower with my PR. I ran these benchmarks manually on my laptop using CPU isolation. Result:

vstinner at apu$ python3 -m perf compare_to ref.json patch.json --table
Not significant (5): unpickle_pure_python; sqlite_synth; spectral_norm; pathlib; scimark_monte_carlo

Ok, that was expected: no significant difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 05:57:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 10:57:47 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517223467.23.0.467229070634.issue20891@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 2914bb32e2adf8dff77c0ca58b33201bc94e398c by Victor Stinner in branch 'master':
bpo-20891: Py_Initialize() now creates the GIL (#4700)
https://github.com/python/cpython/commit/2914bb32e2adf8dff77c0ca58b33201bc94e398c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:01:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:01:08 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517223668.73.0.467229070634.issue20891@psf.upfronthosting.co.za>


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


----------
pull_requests: +5255

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:10:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:10:24 +0000
Subject: [issue31233] socketserver.ThreadingMixIn leaks running threads after
 server_close()
In-Reply-To: <1503073499.39.0.93886151367.issue31233@psf.upfronthosting.co.za>
Message-ID: <1517224224.62.0.467229070634.issue31233@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset db8189bb8db609ca3993dec31fb95fdbe134469a by Victor Stinner in branch 'master':
bpo-31233, bpo-31151: Document socketserver changes (#5417)
https://github.com/python/cpython/commit/db8189bb8db609ca3993dec31fb95fdbe134469a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31233>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:10:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:10:24 +0000
Subject: [issue31151] socketserver.ForkingMixIn.server_close() leaks zombie
 processes
In-Reply-To: <1502239239.94.0.0719119279673.issue31151@psf.upfronthosting.co.za>
Message-ID: <1517224224.74.0.714561066657.issue31151@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset db8189bb8db609ca3993dec31fb95fdbe134469a by Victor Stinner in branch 'master':
bpo-31233, bpo-31151: Document socketserver changes (#5417)
https://github.com/python/cpython/commit/db8189bb8db609ca3993dec31fb95fdbe134469a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31151>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:11:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:11:37 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517224297.56.0.467229070634.issue20891@psf.upfronthosting.co.za>


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


----------
pull_requests: +5256

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:23:39 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jan 2018 11:23:39 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517225019.12.0.467229070634.issue20104@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Your assumption about calling ?file_actions_destroy? would be okay if the posix_spawn_file_actions_t object was a simple object or structure. But I imagine most implementations would allocate memory when you call one of the ?add? methods. Especially ?addopen?, which is supposed to copy the filename string somewhere. Looking at ?uclibc? <https://repo.or.cz/uclibc-ng.git/blob/v1.0.28:/include/spawn.h#l263>, I see it calls ?free?, because it allocates an array for all the file actions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:24:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:24:30 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517225070.07.0.467229070634.issue20891@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I proposed PR 5421 to fix Python 3.6: modify Py_Initialize() to call PyEval_InitThreads().

I'm not sure of Python 2.7. Not only the backport is not straighforward, but I'm not sure that I want to touch the super-stable 2.7 branch. Maybe for 2.7, I should just remove the currently skipped test_bpo20891() test from test_capi.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:27:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:27:36 +0000
Subject: [issue32706] test_check_hostname() of test_ftplib started to fail
 randomly
Message-ID: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

It may be a regression caused by this recent change:
---
commit 61d478c71c5341cdc54e6bfb4ace4252852fd972
Author: Christian Heimes <christian at python.org>
Date:   Sat Jan 27 15:51:38 2018 +0100

    bpo-31399: Let OpenSSL verify hostname and IP address (#3462)
    
    bpo-31399: Let OpenSSL verify hostname and IP
    
    The ssl module now uses OpenSSL's X509_VERIFY_PARAM_set1_host() and
    X509_VERIFY_PARAM_set1_ip() API to verify hostname and IP addresses.
    
    * Remove match_hostname calls
    * Check for libssl with set1_host, libssl must provide X509_VERIFY_PARAM_set1_host()
    * Add documentation for OpenSSL 1.0.2 requirement
    * Don't support OpenSSL special mode with a leading dot, e.g. ".example.org" matches "www.example.org". It's not standard conform.
    * Add hostname_checks_common_name
    
    Signed-off-by: Christian Heimes <christian at python.org>
---

Travis CI output, reformatted to make it more readable:

https://travis-ci.org/python/cpython/jobs/334652437

test_check_hostname (test.test_ftplib.TestTLS_FTPClass) ...

Exception in thread Thread-83:
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 251, in initiate_send
    num_sent = self.send(data)
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 381, in send
    return super(SSLConnection, self).send(data)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 360, in send
    result = self.socket.send(data)
  File "/home/travis/build/python/cpython/Lib/ssl.py", line 963, in send
    return self._sslobj.write(data)
  File "/home/travis/build/python/cpython/Lib/ssl.py", line 670, in write
    return self._sslobj.write(data)
ssl.SSLError: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:2206)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 369, in handle_read_event
    super(SSLConnection, self).handle_read_event()
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 422, in handle_read_event
    self.handle_read()
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 171, in handle_read
    self.found_terminator()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 116, in found_terminator
    method(arg)
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 231, in cmd_list
    self.dtp.push(LIST_DATA)
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 73, in push
    super(DummyDTPHandler, self).push(what.encode('ascii'))
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 202, in push
    self.initiate_send()
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 253, in initiate_send
    self.handle_error()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 402, in handle_error
    raise Exception
Exception

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 279, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 207, in loop
    poll_fun(timeout, map)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 150, in poll
    read(obj)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 87, in read
    obj.handle_error()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 402, in handle_error
    raise Exception
Exception

ERROR

======================================================================
ERROR: test_check_hostname (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 958, in test_check_hostname
    self.client.quit()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 665, in quit
    resp = self.voidcmd('QUIT')
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 278, in voidcmd
    return self.voidresp()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 251, in voidresp
    resp = self.getresp()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 236, in getresp
    resp = self.getmultiline()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 222, in getmultiline
    line = self.getline()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 204, in getline
    line = self.file.readline(self.maxline + 1)
  File "/home/travis/build/python/cpython/Lib/socket.py", line 582, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

----------
assignee: christian.heimes
components: SSL, Tests
messages: 311096
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_check_hostname() of test_ftplib started to fail randomly
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:30:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:30:55 +0000
Subject: [issue32706] test_check_hostname() of test_ftplib started to fail
 randomly
In-Reply-To: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>
Message-ID: <1517225455.53.0.467229070634.issue32706@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I'm able to reproduce the failure on my Fedora 27 using two terminals:

(1) Run the test in a loop:
vstinner at apu$ ./python -m test -v test_ftplib -m test_check_hostname -F

(2) Stress the system, example:
vstinner at apu$ ./python -m test -j0 -r

When the system load becomes higher than 2 (I have 8 logical CPUs), test_check_hostname() fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:41:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:41:45 +0000
Subject: [issue32706] test_check_hostname() of test_ftplib started to fail
 randomly
In-Reply-To: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>
Message-ID: <1517226105.43.0.467229070634.issue32706@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5257
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:42:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:42:29 +0000
Subject: [issue31399] Let OpenSSL verify hostname and IP address
In-Reply-To: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
Message-ID: <1517226149.61.0.467229070634.issue31399@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

It seems like the commit 61d478c71c5341cdc54e6bfb4ace4252852fd972 introduced a regression in test_ftplib: bpo-32706. Can you please take a look?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31399>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:42:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:42:54 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517226174.24.0.467229070634.issue20891@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Antoine Pitrou considers that my PR 5421 for Python 3.6 should not be merged:
"@vstinner I don't think so. People can already call PyEval_InitThreads."
https://github.com/python/cpython/pull/5421#issuecomment-361214537

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:48:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:48:17 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517226497.2.0.467229070634.issue20104@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Python master doesn't build on macOS Tiger anymore:

http://buildbot.python.org/all/#/builders/30/builds/581

./Modules/posixmodule.c:251:19: error: spawn.h: No such file or directory
./Modules/posixmodule.c: In function ?os_posix_spawn_impl?:
./Modules/posixmodule.c:5174: error: ?posix_spawn_file_actions_t? undeclared (first use in this function)
./Modules/posixmodule.c:5174: error: (Each undeclared identifier is reported only once
./Modules/posixmodule.c:5174: error: for each function it appears in.)
./Modules/posixmodule.c:5174: error: ?file_actionsp? undeclared (first use in this function)
./Modules/posixmodule.c:5176: error: parse error before ?_file_actions?
./Modules/posixmodule.c:5177: warning: implicit declaration of function ?posix_spawn_file_actions_init?
./Modules/posixmodule.c:5177: error: ?_file_actions? undeclared (first use in this function)
./Modules/posixmodule.c:5232: warning: implicit declaration of function ?posix_spawn_file_actions_addopen?
./Modules/posixmodule.c:5245: warning: implicit declaration of function ?posix_spawn_file_actions_addclose?
./Modules/posixmodule.c:5262: warning: implicit declaration of function ?posix_spawn_file_actions_adddup2?
./Modules/posixmodule.c:5274: warning: implicit declaration of function ?posix_spawn?
make: *** [Modules/posixmodule.o] Error 1

See also bpo-32705: "Current Android does not have posix_spawn" (now fixed). In PR 5413 of this bpo, it was also asked if "#define HAVE_POSIX_SPAWN 1" of posixmodule.c makes sence since there is already a configure check for posix_spawn()?

https://github.com/python/cpython/pull/5413#issuecomment-361183294

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:59:20 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jan 2018 11:59:20 +0000
Subject: [issue32661] ProactorEventLoop locks up on close call
In-Reply-To: <1516850655.32.0.467229070634.issue32661@psf.upfronthosting.co.za>
Message-ID: <1517227160.45.0.467229070634.issue32661@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32661>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:00:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:00:25 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517227225.59.0.467229070634.issue32645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Different failure on x86 Tiger 3.x:

http://buildbot.python.org/all/#/builders/30/builds/562

======================================================================
ERROR: test_sendfile_ssl (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2243, in test_sendfile_ssl
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_close_peer_after_receiving (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2325, in test_sendfile_ssl_close_peer_after_receiving
    close_after=len(self.DATA))
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_partial (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2302, in test_sendfile_ssl_partial
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_pre_and_post_data (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2277, in test_sendfile_ssl_pre_and_post_data
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2243, in test_sendfile_ssl
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_close_peer_after_receiving (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2325, in test_sendfile_ssl_close_peer_after_receiving
    close_after=len(self.DATA))
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_partial (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2302, in test_sendfile_ssl_partial
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_pre_and_post_data (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2277, in test_sendfile_ssl_pre_and_post_data
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2243, in test_sendfile_ssl
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_close_peer_after_receiving (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2325, in test_sendfile_ssl_close_peer_after_receiving
    close_after=len(self.DATA))
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_partial (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2302, in test_sendfile_ssl_partial
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

======================================================================
ERROR: test_sendfile_ssl_pre_and_post_data (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2277, in test_sendfile_ssl_pre_and_post_data
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:03:01 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Jan 2018 12:03:01 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517227381.49.0.467229070634.issue20104@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

@vstinner I have removed the #define HAVE_POSIX_SPAWN 1 in PR 5418.

----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:07:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:07:13 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517227633.07.0.467229070634.issue32645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Similar errors on more recent macOS version, x86-64 El Capitan 3.x:

http://buildbot.python.org/all/#/builders/93/builds/234

One example:

======================================================================
ERROR: test_sendfile_ssl_partial (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-elcapitan/build/Lib/test/test_asyncio/test_events.py", line 2302, in test_sendfile_ssl_partial
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/Users/buildbot/buildarea/3.x.billenstein-elcapitan/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/Users/buildbot/buildarea/3.x.billenstein-elcapitan/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:08:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:08:31 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517227711.03.0.467229070634.issue32645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

And x86 Ubuntu Shared 3.x:

http://buildbot.python.org/all/#/builders/88/builds/603

Example:

======================================================================
ERROR: test_sendfile_ssl_partial (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/test_events.py", line 2302, in test_sendfile_ssl_partial
    srv_proto, cli_proto = self.prepare(is_ssl=True)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/test_events.py", line 2136, in prepare
    srv_ctx = test_utils.simple_server_sslcontext()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/utils.py", line 73, in simple_server_sslcontext
    server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
AttributeError: 'NoneType' object has no attribute 'SSLContext'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:09:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:09:34 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517227774.72.0.467229070634.issue32622@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

New asyncio sendfile tests fail on many buildbots. See:
https://bugs.python.org/issue32645#msg311101

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:10:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:10:12 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517227812.67.0.467229070634.issue32645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh wait, sendfile test errors come from bpo-32622, loop.sendfile().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:16:09 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 12:16:09 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517228169.03.0.467229070634.issue32645@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Should be fixed by https://github.com/python/cpython/commit/0f54e00e963

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:17:37 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 12:17:37 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517228257.59.0.467229070634.issue32622@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I pretty sure it's fixed by https://github.com/python/cpython/commit/0f54e00e963

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:20:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:20:39 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517228439.93.0.467229070634.issue32645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh sorry, I was reading old issues. I checked the latest status of buildbot workers for which I reported failures:

* x86 Ubuntu Shared 3.x: FIXED
* x86-64 El Capitan 3.x: FIXED
* x86 Windows7 3.x: FIXED
* x86 Tiger 3.x: compilation doesn't work anymore, see https://bugs.python.org/issue20104#msg311100

Ok, it seems like all issues now have been fixed.

On bpo-20104 will be fixed, if test_asyncio still fails on x86 Tiger 3.x, I will open a more specific issue.

I close this issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:21:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:21:39 +0000
Subject: [issue32706] test_check_hostname() of test_ftplib started to fail
 randomly
In-Reply-To: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>
Message-ID: <1517228499.48.0.467229070634.issue32706@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 51500f37453bbcbc5f1dbc3c38d079c3c1efe5de by Victor Stinner in branch 'master':
bpo-32706: Skip test_ftplib.test_check_hostname() (#5422)
https://github.com/python/cpython/commit/51500f37453bbcbc5f1dbc3c38d079c3c1efe5de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:23:04 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 12:23:04 +0000
Subject: [issue32645] test_asyncio: TLS tests fail on "x86 Windows7" buildbot
In-Reply-To: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>
Message-ID: <1517228584.51.0.467229070634.issue32645@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks, Victor!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:24:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:24:12 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517228652.14.0.467229070634.issue28685@psf.upfronthosting.co.za>


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


----------
pull_requests: +5258

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:31:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:31:06 +0000
Subject: [issue32707] Python/hamt.c warnings
Message-ID: <1517229066.54.0.467229070634.issue32707@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

https://ci.appveyor.com/project/python/cpython/build/3.7build11469

..\Python\hamt.c(623): warning C4018: '<': signed/unsigned mismatch [C:\projects\cpython\PCbuild\pythoncore.vcxproj]
..\Python\hamt.c(937): warning C4018: '<': signed/unsigned mismatch [C:\projects\cpython\PCbuild\pythoncore.vcxproj]

IMHO it's a real bug, the warning must not be made quiet. HAMT doesn't support sizes larger than UINT32_MAX. HAMT must either fail to create if size is larger than UINT32_MAX, or the code should be fixed to use wider C types (larger than uint32_t, like uint64_t).

----------
components: Interpreter Core, asyncio
messages: 311112
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Python/hamt.c warnings
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32707>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:35:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:35:22 +0000
Subject: [issue32708] test_sendfile() hangs on AMD64 FreeBSD 10.x Shared 3.x
 buildbot
Message-ID: <1517229322.87.0.467229070634.issue32708@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

loop.sendfile() was added to asyncio in bpo-32622.

The test hangs on AMD64 FreeBSD 10.x Shared 3.x buildbot:

http://buildbot.python.org/all/#/builders/87/builds/598

Timeout (0:15:00)!
Thread 0x0000000802006400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/selectors.py", line 415 in select
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/base_events.py", line 1702 in _run_once
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/base_events.py", line 521 in run_forever
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/base_events.py", line 553 in run_until_complete
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_asyncio/test_events.py", line 2131 in run_loop
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_asyncio/test_events.py", line 2194 in test_sendfile
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 615 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 663 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1861 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1951 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 175 in test_runner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 176 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 291 in rerun_failed_tests
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 540 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 510 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 585 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 2 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 193 in _run_module_as_main
test_sendfile (test.test_asyncio.test_events.PollEventLoopTests) ... *** Error code 1

----------
components: Tests, asyncio
messages: 311113
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_sendfile() hangs on AMD64 FreeBSD 10.x Shared 3.x buildbot
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32708>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:35:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:35:51 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517229351.89.0.467229070634.issue32622@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

test_sendfile() hangs on AMD64 FreeBSD 10.x Shared 3.x buildbot: bpo-32708.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:40:46 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 12:40:46 +0000
Subject: [issue32709] the iterable for itertools.groupby must be sorted
Message-ID: <1517229646.32.0.467229070634.issue32709@psf.upfronthosting.co.za>


New submission from St?phane Wirtel <stephane at wirtel.be>:

The documentation of itertools.groupby indicates that generally, the iterable needs to be sorted. In fact, this iterable MUST be sorted.

----------
assignee: docs at python
components: Documentation
messages: 311115
nosy: docs at python, matrixise
priority: normal
severity: normal
status: open
title: the iterable for itertools.groupby must be sorted
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32709>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:42:54 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 12:42:54 +0000
Subject: [issue32709] the iterable for itertools.groupby must be sorted
In-Reply-To: <1517229646.32.0.467229070634.issue32709@psf.upfronthosting.co.za>
Message-ID: <1517229774.3.0.467229070634.issue32709@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +5259
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32709>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:43:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:43:38 +0000
Subject: [issue32710] test_asyncio leaked [4, 4, 3] memory blocks,
 sum=11 on AMD64 Windows8.1 Refleaks 3.x
Message-ID: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

AMD64 Windows8.1 Refleaks 3.x:
http://buildbot.python.org/all/#/builders/80/builds/118

test_asyncio leaked [4, 4, 3] memory blocks, sum=11

I reproduced the issue. I'm running test.bisect to try to isolate this bug.

----------
components: asyncio
messages: 311116
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio leaked [4, 4, 3] memory blocks, sum=11 on AMD64 Windows8.1 Refleaks 3.x
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:46:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:46:02 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1517229962.12.0.467229070634.issue23749@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

test_start_tls_server_1() still fails randomly. Example on AppVeyor on my PR 5423:

https://ci.appveyor.com/project/python/cpython/build/3.7build11472

ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_asyncio\test_sslproto.py", line 293, in test_start_tls_server_1
    asyncio.wait_for(main(), loop=self.loop, timeout=10))
  File "C:\projects\cpython\lib\asyncio\base_events.py", line 564, in run_until_complete
    raise RuntimeError('Event loop stopped before Future completed.')
RuntimeError: Event loop stopped before Future completed.

I also had this failure on my Windows 10 VM when running "python -m test -R 3:3 -v test_asyncio". I skipped the test to be able to debug bpo-32710.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:47:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:47:08 +0000
Subject: [issue28685] Optimizing list.sort() by performing safety checks in
 advance
In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za>
Message-ID: <1517230028.8.0.467229070634.issue28685@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 8017b804a06804793bcc0a7f734d8a846b0fe18a by Victor Stinner in branch 'master':
bpo-28685: Fix compiler warning (GH-5423)
https://github.com/python/cpython/commit/8017b804a06804793bcc0a7f734d8a846b0fe18a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28685>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:49:59 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 29 Jan 2018 12:49:59 +0000
Subject: [issue32709] the iterable for itertools.groupby must be sorted
In-Reply-To: <1517229646.32.0.467229070634.issue32709@psf.upfronthosting.co.za>
Message-ID: <1517230199.4.0.467229070634.issue32709@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

It depends upon your use case.

In general, if you want it to work like SQL group by, then yes, it needs to be sorted, and I believe the documentation already covers that.  However, there are scenarios where you want to condense a string, but keep the ordering, such as:

'aaaaabbbbbbccccaaaaddd' into '5a6b4c4a3d'

and itertools.groupby works very nicely for that.

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32709>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:53:37 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 12:53:37 +0000
Subject: [issue32709] the iterable for itertools.groupby must be sorted
In-Reply-To: <1517229646.32.0.467229070634.issue32709@psf.upfronthosting.co.za>
Message-ID: <1517230417.45.0.467229070634.issue32709@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

good catch, I only use itertools.groupby when I work for a collection.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32709>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:54:45 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 12:54:45 +0000
Subject: [issue32709] the iterable for itertools.groupby must be sorted
In-Reply-To: <1517229646.32.0.467229070634.issue32709@psf.upfronthosting.co.za>
Message-ID: <1517230485.05.0.467229070634.issue32709@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I am going to close my issue because with your use case, this issue makes no sense.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32709>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:56:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:56:37 +0000
Subject: [issue32710] test_asyncio leaked [4, 4, 3] memory blocks,
 sum=11 on AMD64 Windows8.1 Refleaks 3.x
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1517230597.49.0.467229070634.issue32710@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

It seems to be related to sendfile():

C:\vstinner\python\master>python -m test -R 3:3 test_asyncio -m test.test_asyncio.test_events.ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving
Running Debug|x64 interpreter...
Run tests sequentially
0:00:00 [1/1] test_asyncio
beginning 6 repetitions
123456
......
test_asyncio leaked [1, 2, 1] memory blocks, sum=4
test_asyncio failed

1 test failed:
    test_asyncio

Total duration: 1 sec
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:58:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:58:01 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1517230681.91.0.467229070634.issue32622@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving() leaks a reference on Windows: bpo-32710.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:04:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 13:04:46 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517231086.23.0.467229070634.issue20891@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset d951157268b2122109098c792562b71ccc41920b by Victor Stinner in branch 'master':
bpo-20891: Reenable test_embed.test_bpo20891() (GH-5420)
https://github.com/python/cpython/commit/d951157268b2122109098c792562b71ccc41920b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:07:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 13:07:27 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517231247.09.0.467229070634.issue20891@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Antoine Pitrou:
> @vstinner I don't think so. People can already call PyEval_InitThreads.

Since only two users complained about https://bugs.python.org/issue20891 in 3 years, I agree that it's ok to not fix Python 2.7 and 3.6. The workaround is to call PyEval_InitThreads() before starting the first thread.

I wasn't excited to make such stable in stable 2.7 and 3.6 anyway :-)

test_embed.test_bpo20891() is enabled again on master. I now close the issue.

Thanks Steve Dower for the bug report!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:10:21 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 13:10:21 +0000
Subject: [issue31429] TLS cipher suite compile time option for downstream
In-Reply-To: <1505222565.12.0.626881844442.issue31429@psf.upfronthosting.co.za>
Message-ID: <1517231421.13.0.467229070634.issue31429@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 892d66e422d5367673163d62ba40cd70a37d5cf7 by Christian Heimes in branch 'master':
bpo-31429: Define TLS cipher suite on build time (#3532)
https://github.com/python/cpython/commit/892d66e422d5367673163d62ba40cd70a37d5cf7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31429>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:10:35 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 13:10:35 +0000
Subject: [issue31429] TLS cipher suite compile time option for downstream
In-Reply-To: <1505222565.12.0.626881844442.issue31429@psf.upfronthosting.co.za>
Message-ID: <1517231435.73.0.467229070634.issue31429@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31429>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:12:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 13:12:16 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517231536.95.0.467229070634.issue20891@psf.upfronthosting.co.za>


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


----------
pull_requests: +5260

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:20:00 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 13:20:00 +0000
Subject: [issue32706] test_check_hostname() of test_ftplib started to fail
 randomly
In-Reply-To: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>
Message-ID: <1517232000.3.0.467229070634.issue32706@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Some tests still use asyncore to test TLS. Yes, that's old asyncore, not asyncio. I suggest that we replace asyncore with a threaded test server from test_ssl.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:25:15 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 13:25:15 +0000
Subject: [issue28414] SSL match_hostname fails for internationalized domain
 names
In-Reply-To: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za>
Message-ID: <1517232315.32.0.467229070634.issue28414@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 66e5742becce38e69a8f09e5f7051445fc57e92e by Christian Heimes in branch 'master':
bpo-28414: ssl module idna test (#5395)
https://github.com/python/cpython/commit/66e5742becce38e69a8f09e5f7051445fc57e92e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28414>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:25:15 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 13:25:15 +0000
Subject: [issue31399] Let OpenSSL verify hostname and IP address
In-Reply-To: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
Message-ID: <1517232315.6.0.714561066657.issue31399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 66e5742becce38e69a8f09e5f7051445fc57e92e by Christian Heimes in branch 'master':
bpo-28414: ssl module idna test (#5395)
https://github.com/python/cpython/commit/66e5742becce38e69a8f09e5f7051445fc57e92e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31399>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:26:49 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 13:26:49 +0000
Subject: [issue28414] SSL match_hostname fails for internationalized domain
 names
In-Reply-To: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za>
Message-ID: <1517232409.04.0.467229070634.issue28414@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

In PR https://github.com/python/cpython/pull/5395 I added a test to verify that most IDNA domains are now working. IDNA 2008 deviations and the fundamental issue of IDNA server callback and IDNA encoded server_hostname attribute are still open. I'll address them in another PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28414>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:30:07 2018
From: report at bugs.python.org (Socob)
Date: Mon, 29 Jan 2018 13:30:07 +0000
Subject: [issue31399] Let OpenSSL verify hostname and IP address
In-Reply-To: <1504904686.16.0.498803825814.issue31399@psf.upfronthosting.co.za>
Message-ID: <1517232607.15.0.467229070634.issue31399@psf.upfronthosting.co.za>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31399>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:35:09 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 13:35:09 +0000
Subject: [issue32711] Fix warnings for Python/ast_unparse.c
Message-ID: <1517232909.04.0.467229070634.issue32711@psf.upfronthosting.co.za>


New submission from St?phane Wirtel <stephane at wirtel.be>:

Python/ast_unparse.c: At top level:
Python/ast_unparse.c:1122:1: warning: function declaration isn?t a prototype [-Wstrict-prototypes]
 maybe_init_static_strings()
 ^~~~~~~~~~~~~~~~~~~~~~~~~
Python/ast_unparse.c: In function ?append_ast_binop?:
Python/ast_unparse.c:105:15: warning: ?op? may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (-1 == append_charp(writer, op)) {
               ^~~~~~~~~~~~~~~~~~~~~~~~
Python/ast_unparse.c: In function ?append_ast_unaryop?:
Python/ast_unparse.c:132:15: warning: ?op? may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (-1 == append_charp(writer, op)) {
               ^~~~~~~~~~~~~~~~~~~~~~~~

----------
components: Interpreter Core
messages: 311131
nosy: matrixise
priority: normal
severity: normal
status: open
title: Fix warnings for Python/ast_unparse.c
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32711>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:38:05 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 13:38:05 +0000
Subject: [issue32711] Fix warnings for Python/ast_unparse.c
In-Reply-To: <1517232909.04.0.467229070634.issue32711@psf.upfronthosting.co.za>
Message-ID: <1517233085.15.0.467229070634.issue32711@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'm getting slightly different warnings with GCC 7.2.1:

Python/ast_unparse.c: In function ?append_formattedvalue?:
Python/ast_unparse.c:859:41: warning: ordered comparison of pointer with integer zero [-Wextra]
     if (e->v.FormattedValue.format_spec > 0) {
                                         ^
Python/ast_unparse.c: At top level:
Python/ast_unparse.c:1122:1: warning: function declaration isn?t a prototype [-Wstrict-prototypes]
 maybe_init_static_strings()
 ^~~~~~~~~~~~~~~~~~~~~~~~~
Python/ast_unparse.c: In function ?append_ast_expr?:
Python/ast_unparse.c:23:16: warning: ?op? may be used uninitialized in this function [-Wmaybe-uninitialized]
         return _PyUnicodeWriter_WriteASCIIString(writer, charp, -1);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Python/ast_unparse.c:119:17: note: ?op? was declared here
     const char *op;
                 ^~
Python/ast_unparse.c:23:16: warning: ?op? may be used uninitialized in this function [-Wmaybe-uninitialized]
         return _PyUnicodeWriter_WriteASCIIString(writer, charp, -1);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Python/ast_unparse.c:79:17: note: ?op? was declared here
     const char *op;

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32711>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:38:07 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 13:38:07 +0000
Subject: [issue32711] Fix warnings for Python/ast_unparse.c
In-Reply-To: <1517232909.04.0.467229070634.issue32711@psf.upfronthosting.co.za>
Message-ID: <1517233087.32.0.467229070634.issue32711@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +5261
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32711>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:40:04 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 13:40:04 +0000
Subject: [issue32711] Fix warnings for Python/ast_unparse.c
In-Reply-To: <1517232909.04.0.467229070634.issue32711@psf.upfronthosting.co.za>
Message-ID: <1517233204.15.0.467229070634.issue32711@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Christian, I proposed a patch ofr the maybe_init_static_strings and for the const char *op, but I don't know how to fix for the e->v.FormattedValue.format_spec > 0, I don't know how to interpret it :/

But for _PyUnicodeWriter_WriteASCIIString, I don't get that warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32711>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:40:17 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 13:40:17 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517233217.63.0.467229070634.issue32650@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +5262

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:47:45 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 13:47:45 +0000
Subject: [issue17651] Errno checking replaced by concrete classes inherited
 from OSError
In-Reply-To: <1365354742.46.0.363482089834.issue17651@psf.upfronthosting.co.za>
Message-ID: <1517233665.0.0.467229070634.issue17651@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The issue is outdated and mostly fixed.

Feel free to open a new one if needed.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17651>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:48:10 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 13:48:10 +0000
Subject: [issue17651] Errno checking replaced by concrete classes inherited
 from OSError
In-Reply-To: <1365354742.46.0.363482089834.issue17651@psf.upfronthosting.co.za>
Message-ID: <1517233690.24.0.467229070634.issue17651@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17651>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:48:32 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 13:48:32 +0000
Subject: [issue16705] Use concrete classes inherited from OSError instead of
 errno check
In-Reply-To: <1355776299.81.0.3555135726.issue16705@psf.upfronthosting.co.za>
Message-ID: <1517233712.46.0.467229070634.issue16705@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16705>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:48:51 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 13:48:51 +0000
Subject: [issue16648] stdib should use new exception types from PEP 3151
In-Reply-To: <1354995347.5.0.732021100427.issue16648@psf.upfronthosting.co.za>
Message-ID: <1517233731.98.0.467229070634.issue16648@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16648>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:57:45 2018
From: report at bugs.python.org (64andy)
Date: Mon, 29 Jan 2018 13:57:45 +0000
Subject: [issue32712] Modifying a list/dict effects all variables sharing that
 address
Message-ID: <1517234265.82.0.467229070634.issue32712@psf.upfronthosting.co.za>


New submission from 64andy <64andy2000 at gmail.com>:

If multiple lists/dictionaries are in the same memory address (usually caused by var1 = var2), then altering one will effect every variable in that address.
The ways I've found to achieve this are:
>>> my_list[2] = "Spam"
>>> my_list += "9"
>>> my_list.insert(4, "Hello")
>>> dictvar.update({"Three": "Four"})

This was achieved using Python 3.6.4 32-bit and 3.6.3 64-bit (CPython), and happened in both IDLE and python.exe

List Example code:
x = ['a','b','c']
y = x #Now y and x share a memory address, because CPython does that
print(f"Sanity test - x and y share the same address = {x is y}")

y[1] = '123'
y += ["Foo"]
y.insert(-1, "Eleven")

#x's Expected Value: ['a','b','c']
print(x) #Actual Value

----------
messages: 311135
nosy: 64andy
priority: normal
severity: normal
status: open
title: Modifying a list/dict effects all variables sharing that address
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32712>
_______________________________________

From report at bugs.python.org  Mon Jan 29 09:01:15 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 14:01:15 +0000
Subject: [issue32711] Fix warnings for Python/ast_unparse.c
In-Reply-To: <1517232909.04.0.467229070634.issue32711@psf.upfronthosting.co.za>
Message-ID: <1517234475.29.0.467229070634.issue32711@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi @Chris, with your help I just fixed the last warning, but I don't have the warning with _PyUnicodeWriter_WriteASCIIString :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32711>
_______________________________________

From report at bugs.python.org  Mon Jan 29 09:05:50 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 14:05:50 +0000
Subject: [issue32711] Fix warnings for Python/ast_unparse.c
In-Reply-To: <1517232909.04.0.467229070634.issue32711@psf.upfronthosting.co.za>
Message-ID: <1517234750.78.0.467229070634.issue32711@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

the switch blocks in both functions need to handle invalid input:

default: PyExc_SetString...; return -1;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32711>
_______________________________________

From report at bugs.python.org  Mon Jan 29 09:13:58 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 14:13:58 +0000
Subject: [issue14799] Tkinter ttk tests hang on linux
In-Reply-To: <1336935343.12.0.855604727116.issue14799@psf.upfronthosting.co.za>
Message-ID: <1517235238.26.0.467229070634.issue14799@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Yes, everything works on Ubuntu 17.10

Closing the issue

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14799>
_______________________________________

From report at bugs.python.org  Mon Jan 29 09:15:43 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Jan 2018 14:15:43 +0000
Subject: [issue32624] Implement WriteTransport.is_protocol_paused()
In-Reply-To: <1516642795.12.0.467229070634.issue32624@psf.upfronthosting.co.za>
Message-ID: <1517235343.0.0.467229070634.issue32624@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Let's not do it: the new method is not required for starttls/sendfile, the name and behavior is questionable.

New issue should be created with use case example.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32624>
_______________________________________

From report at bugs.python.org  Mon Jan 29 09:15:53 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Jan 2018 14:15:53 +0000
Subject: [issue32712] Modifying a list/dict effects all variables sharing that
 address
In-Reply-To: <1517234265.82.0.467229070634.issue32712@psf.upfronthosting.co.za>
Message-ID: <1517235353.4.0.467229070634.issue32712@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yep, that's the way Python works.  You are modifying the same object through different names.  Remember that in Python it is the objects that matter (which are identified in CPython via their memory address, but that's an implementation detail) and names are just handy references to those objects.  There can be any number of names that reference a single object.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32712>
_______________________________________

From report at bugs.python.org  Mon Jan 29 09:22:03 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Jan 2018 14:22:03 +0000
Subject: [issue32650] Debug support for native coroutines is broken
In-Reply-To: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>
Message-ID: <1517235723.64.0.467229070634.issue32650@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5263

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Mon Jan 29 09:31:34 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Jan 2018 14:31:34 +0000
Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz
 ending with x0d binary code
In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za>
Message-ID: <1517236294.42.0.467229070634.issue32304@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset f5a793522d539afc84ac7888c9ad189097c43a75 by ?ric Araujo (Bo Bayles) in branch '2.7':
bpo-32304: Fix distutils upload for tar files ending with b'\r' (GH-5264) (GH-5331)
https://github.com/python/cpython/commit/f5a793522d539afc84ac7888c9ad189097c43a75


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32304>
_______________________________________

From report at bugs.python.org  Mon Jan 29 10:17:27 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Jan 2018 15:17:27 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517239047.48.0.467229070634.issue32550@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Is this going to make it into beta 1 before tonight? If not should we abandon it or put it off till 3.8 or can it go into 3.7beta2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 10:34:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 15:34:31 +0000
Subject: [issue30595] test_queue_feeder_donot_stop_onexc() of
 test_multiprocessing_spawn fails randomly on x86 Windows7 3.x
In-Reply-To: <1496907626.7.0.367274651848.issue30595@psf.upfronthosting.co.za>
Message-ID: <1517240071.58.0.467229070634.issue30595@psf.upfronthosting.co.za>


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


----------
pull_requests: +5264

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30595>
_______________________________________

From report at bugs.python.org  Mon Jan 29 10:35:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 15:35:52 +0000
Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error
In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>
Message-ID: <1517240152.79.0.467229070634.issue20891@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 0cecc22842dcc4090eb9cb99e7dababea7034a87 by Victor Stinner in branch '3.6':
bpo-20891: Remove test_capi.test_bpo20891() (#5425)
https://github.com/python/cpython/commit/0cecc22842dcc4090eb9cb99e7dababea7034a87


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20891>
_______________________________________

From report at bugs.python.org  Mon Jan 29 10:39:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 15:39:36 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517240376.24.0.467229070634.issue20104@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

FYI bolen-dmg-3.x was also broken by this change:

http://buildbot.python.org/all/#/builders/69/builds/114

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 10:54:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 15:54:31 +0000
Subject: [issue30595] test_queue_feeder_donot_stop_onexc() of
 test_multiprocessing_spawn fails randomly on x86 Windows7 3.x
In-Reply-To: <1496907626.7.0.367274651848.issue30595@psf.upfronthosting.co.za>
Message-ID: <1517241271.83.0.467229070634.issue30595@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset b60f43a0e6052b29517931eea591b0b29903f382 by Victor Stinner in branch '2.7':
bpo-30595: Increase test_queue_feeder_donot_stop_onexc() timeout (GH-2148) (GH-5429)
https://github.com/python/cpython/commit/b60f43a0e6052b29517931eea591b0b29903f382


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30595>
_______________________________________

From report at bugs.python.org  Mon Jan 29 11:16:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 16:16:17 +0000
Subject: [issue30595] test_queue_feeder_donot_stop_onexc() of
 test_multiprocessing_spawn fails randomly on x86 Windows7 3.x
In-Reply-To: <1496907626.7.0.367274651848.issue30595@psf.upfronthosting.co.za>
Message-ID: <1517242577.47.0.467229070634.issue30595@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The Python 2.7 is to fix this failure:
http://buildbot.python.org/all/#/builders/59/builds/61

test_lock (test.test_multiprocessing.TestForkAwareThreadLock) ... ok
test_ignore (test.test_multiprocessing.TestIgnoreEINTR) ... ok
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_multiprocessing.py", line 674, in test_queue_feeder_donot_stop_onexc
    self.assertTrue(q.get(timeout=0.1))
  File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/multiprocessing/queues.py", line 132, in get
    raise Empty
Empty
test_ignore_listener (test.test_multiprocessing.TestIgnoreEINTR) ... ok
======================================================================
ERROR: test_queue_feeder_donot_stop_onexc (test.test_multiprocessing.WithProcessesTestQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_multiprocessing.py", line 674, in test_queue_feeder_donot_stop_onexc
    self.assertTrue(q.get(timeout=0.1))
  File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/multiprocessing/queues.py", line 132, in get
    raise Empty
Empty

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30595>
_______________________________________

From report at bugs.python.org  Mon Jan 29 11:27:53 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 16:27:53 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517243273.24.0.467229070634.issue25988@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset e6d342156d2ab20fb88c0a5ec615fa8f602c0769 by Raymond Hettinger in branch 'master':
bpo-25988: Deprecate exposing collections.abc in collections GH-5414
https://github.com/python/cpython/commit/e6d342156d2ab20fb88c0a5ec615fa8f602c0769


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Mon Jan 29 11:27:55 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Jan 2018 16:27:55 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1517187611.18.0.467229070634.issue32226@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+LG45SZhdw2mEK6kry9bgjV375Yqq=71AVRkgzjomB3Q@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

ISTM that those ought to be separate issues since PEP 560 has been
implemented fully here.

Also I am getting cold feet about Union simplification (esp. this late in
the release cycle). We should probably retreat on the typing tracker and
discuss why we're considering it -- is there evidence (even anecdotal) that
it's harmful?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Mon Jan 29 11:43:56 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 16:43:56 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517244236.43.0.467229070634.issue20104@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 11:49:14 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Jan 2018 16:49:14 +0000
Subject: [issue32513] dataclasses: make it easier to use user-supplied special
 methods
In-Reply-To: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>
Message-ID: <1517244554.04.0.467229070634.issue32513@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Nit: I think the presentation of the 12-row table in msg310830 can be improved, e.g. by putting the legend for add* closer and/or giving add* a clearer name, and by splitting it into three 4-row tables. Currently the legend comes before all the other tables, and those aren't very useful (they're all the same, except for 'order', and the exception there is better explained in text).

But that's a matter for whoever writes the docs. As a spec it is unambiguous. On python-dev I've just posted that I support this version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Mon Jan 29 12:03:17 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 17:03:17 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1517245397.25.0.467229070634.issue23749@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I have a feeling that using threads+IO+asyncio makes the test too unstable on some Windows buildbots.  I'll rewrite start-tls tests without using threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Jan 29 12:04:09 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 17:04:09 +0000
Subject: [issue32710] test_asyncio leaked [4, 4, 3] memory blocks,
 sum=11 on AMD64 Windows8.1 Refleaks 3.x
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1517245449.85.0.467229070634.issue32710@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Andrew, please take a look.  I'll have very limited (to no at all) time to work on Python in the next 2 weeks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Mon Jan 29 12:45:20 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 17:45:20 +0000
Subject: [issue32694] Can no longer specify OpenSLL locations with CPPFLAGS /
 LDFLAGS ?
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517247920.43.0.467229070634.issue32694@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Hmm, I spoke a bit too soon. I now see one side effect of Christian's change is to break the suggested code in the devguide for using a local or private version of OpenSSL on macOS at least, e.g. supplying the paths via CPPFLAGS and LDFLAGS.  If there is a pkg-config available on the path that supplies the same values, the net effect is the same but having pkg-config available wasn't a requirement previously and should not now be.  We'll probably need to fix this in a more general way than PR 5388 proposed.  I'll try to take a look at it before beta 1 freeze but, if not, it should be fixed for beta 2.

----------
priority: normal -> deferred blocker
title: macos/configure: Discover OpenSSL when installed with MacPorts -> Can no longer specify OpenSLL locations with CPPFLAGS / LDFLAGS ?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Mon Jan 29 12:57:09 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 17:57:09 +0000
Subject: [issue32707] Python/hamt.c warnings
In-Reply-To: <1517229066.54.0.467229070634.issue32707@psf.upfronthosting.co.za>
Message-ID: <1517248629.75.0.467229070634.issue32707@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5265
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32707>
_______________________________________

From report at bugs.python.org  Mon Jan 29 13:00:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 18:00:25 +0000
Subject: [issue32707] Python/hamt.c warnings
In-Reply-To: <1517229066.54.0.467229070634.issue32707@psf.upfronthosting.co.za>
Message-ID: <1517248825.02.0.467229070634.issue32707@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> IMHO it's a real bug,

No. HAMT bitmap and array nodes can only store up to 32 pointers, so we use Py_ssize_t & Py_SIZE only because those nodes are PyObject_VAR_HEAD objects.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32707>
_______________________________________

From report at bugs.python.org  Mon Jan 29 13:07:47 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Jan 2018 18:07:47 +0000
Subject: [issue27931] Email parse IndexError <""@wiarcom.com>
In-Reply-To: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>
Message-ID: <1517249267.67.0.467229070634.issue27931@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:


New changeset aa218d1649690d1c1ba86a9972f7fae646bf1a8f by R. David Murray (jayyyin) in branch 'master':
bpo-27931: Fix email address header parsing error (#5329)
https://github.com/python/cpython/commit/aa218d1649690d1c1ba86a9972f7fae646bf1a8f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27931>
_______________________________________

From report at bugs.python.org  Mon Jan 29 13:08:04 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 29 Jan 2018 18:08:04 +0000
Subject: [issue27931] Email parse IndexError <""@wiarcom.com>
In-Reply-To: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>
Message-ID: <1517249284.38.0.467229070634.issue27931@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5266

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27931>
_______________________________________

From report at bugs.python.org  Mon Jan 29 13:31:45 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 18:31:45 +0000
Subject: [issue32707] Python/hamt.c warnings
In-Reply-To: <1517229066.54.0.467229070634.issue32707@psf.upfronthosting.co.za>
Message-ID: <1517250705.27.0.467229070634.issue32707@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b647d7039d396b1da71ab33b101a78b53d4e6834 by Yury Selivanov in branch 'master':
bpo-32707: Fix warnings in hamt.c (#5430)
https://github.com/python/cpython/commit/b647d7039d396b1da71ab33b101a78b53d4e6834


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32707>
_______________________________________

From report at bugs.python.org  Mon Jan 29 13:32:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 18:32:06 +0000
Subject: [issue32707] Python/hamt.c warnings
In-Reply-To: <1517229066.54.0.467229070634.issue32707@psf.upfronthosting.co.za>
Message-ID: <1517250726.76.0.467229070634.issue32707@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Hopefully the warnings will be fixed.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32707>
_______________________________________

From report at bugs.python.org  Mon Jan 29 13:32:16 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 18:32:16 +0000
Subject: [issue32707] Python/hamt.c warnings
In-Reply-To: <1517229066.54.0.467229070634.issue32707@psf.upfronthosting.co.za>
Message-ID: <1517250736.53.0.467229070634.issue32707@psf.upfronthosting.co.za>


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


----------
components:  -asyncio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32707>
_______________________________________

From report at bugs.python.org  Mon Jan 29 14:31:55 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 19:31:55 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517254315.57.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 2a2270db9be9bdac5ffd2d50929bf905e7391a06 by Yury Selivanov in branch 'master':
bpo-32703: Fix coroutine resource warning in case where there's an error (GH-5410)
https://github.com/python/cpython/commit/2a2270db9be9bdac5ffd2d50929bf905e7391a06


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 14:32:15 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 19:32:15 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517254335.54.0.467229070634.issue32703@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Merged; closing this issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 14:32:43 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 19:32:43 +0000
Subject: [issue32605] Should we really hide unawaited coroutine warnings when
 an exception is pending?
In-Reply-To: <1516426250.01.0.467229070634.issue32605@psf.upfronthosting.co.za>
Message-ID: <1517254363.52.0.467229070634.issue32605@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

With PR https://github.com/python/cpython/pull/5410 being merged I believe this issue can be now closed.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32605>
_______________________________________

From report at bugs.python.org  Mon Jan 29 14:32:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 19:32:53 +0000
Subject: [issue32605] Should we really hide unawaited coroutine warnings when
 an exception is pending?
In-Reply-To: <1516426250.01.0.467229070634.issue32605@psf.upfronthosting.co.za>
Message-ID: <1517254373.48.0.467229070634.issue32605@psf.upfronthosting.co.za>


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


----------
components: +Interpreter Core -asyncio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32605>
_______________________________________

From report at bugs.python.org  Mon Jan 29 14:33:55 2018
From: report at bugs.python.org (Adrien)
Date: Mon, 29 Jan 2018 19:33:55 +0000
Subject: [issue32698] Improper gzip compression if output file extension is
 not "gz"
In-Reply-To: <1517164653.32.0.467229070634.issue32698@psf.upfronthosting.co.za>
Message-ID: <1517254435.02.0.467229070634.issue32698@psf.upfronthosting.co.za>


Adrien <delgan.py at gmail.com> added the comment:

Thanks @martin.panter for your response.

I will close this issue as "not a bug" as there is a workaround and as the current behavior could be deduced by reading carefully the entire documentation.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32698>
_______________________________________

From report at bugs.python.org  Mon Jan 29 14:43:30 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 19:43:30 +0000
Subject: [issue32232] building extensions as builtins is broken in 3.7
In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za>
Message-ID: <1517255010.27.0.467229070634.issue32232@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks Pablo for taking up the challenge!  I just took a quick look at the current state of PR 5256 and I noted numerous issues that need to be addressed with the test.  I don't have time at the moment to review the non-test changes.  It would be good if another core developer could review it.  Since it's not likely this will get resolved prior to the imminent 3.7.0b1 code freeze, I'm going to reluctantly defer this to b2 (unless someone else gets to it first).

----------
priority: release blocker -> deferred blocker
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32232>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:10:43 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 20:10:43 +0000
Subject: [issue24325] Speedup types.coroutine()
In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za>
Message-ID: <1517256643.11.0.467229070634.issue24325@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Closing this one now--there's no point in speeding up types.coroutine anymore.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24325>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:25:04 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:25:04 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517257504.78.0.467229070634.issue32550@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If Mark can get it in tonight, that would be great.  The patch has been ready for a long time.  It just needs to have the merge conflicts resolved.

Otherwise, I think 3.7beta2 would be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:25:33 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 20:25:33 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517257533.39.0.467229070634.issue20104@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

FYI

New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s)
** CID 1428733: Memory - illegal accesses (RETURN_LOCAL) /Modules/posixmodule.c: 5281 in os_posix_spawn_impl()
________________________________________________________________________________________________________ *** CID 1428733: Memory - illegal accesses (RETURN_LOCAL)
/Modules/posixmodule.c: 5281 in os_posix_spawn_impl()
5275 }
5276 }
5277 Py_DECREF(seq);
5278 }
5279
5280 _Py_BEGIN_SUPPRESS_IPH
5281 posix_spawn(&pid, path->narrow, file_actionsp, NULL, argvlist, envlist);
5282 return PyLong_FromPid(pid);
5283 _Py_END_SUPPRESS_IPH
5284
5285 path_error(path); 5286
** CID 1428732: Control flow issues (UNREACHABLE) /Modules/posixmodule.c: 5285 in os_posix_spawn_impl()
________________________________________________________________________________________________________ *** CID 1428732: Control flow issues (UNREACHABLE)
/Modules/posixmodule.c: 5285 in os_posix_spawn_impl()
5279
5280 _Py_BEGIN_SUPPRESS_IPH
5281 posix_spawn(&pid, path->narrow, file_actionsp, NULL, argvlist, envlist);
5282 return PyLong_FromPid(pid);
5283 _Py_END_SUPPRESS_IPH
5284
5285 path_error(path); 5286
 
5287 free_string_array(envlist, envc); 5288
5289 fail:
5290

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:25:50 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 20:25:50 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517257550.84.0.467229070634.issue20104@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:27:57 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 29 Jan 2018 20:27:57 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517257677.02.0.467229070634.issue20104@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thank Yury for the information!

This should be fixed now in PR418.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:34:47 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 29 Jan 2018 20:34:47 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517258087.86.0.467229070634.issue20104@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 0cd6bca65519109a8a7862d38ba1b8924e432a16 by Gregory P. Smith (Pablo Galindo) in branch 'master':
bpo-20104: Fix leaks and errors in new os.posix_spawn (GH-5418)
https://github.com/python/cpython/commit/0cd6bca65519109a8a7862d38ba1b8924e432a16


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:37:12 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:37:12 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517258232.33.0.467229070634.issue31356@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 72a0d218dcc94a3cc409a9ef32dfcd5a7bbcb43c by Raymond Hettinger (Pablo Galindo) in branch 'master':
bpo-31356: Add context manager to temporarily disable GC (GH-4224)
https://github.com/python/cpython/commit/72a0d218dcc94a3cc409a9ef32dfcd5a7bbcb43c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:38:01 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:38:01 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517258281.18.0.467229070634.issue31356@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:39:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:39:31 +0000
Subject: [issue32336] Save OrderedDict import in argparse
In-Reply-To: <1513361484.23.0.213398074469.issue32336@psf.upfronthosting.co.za>
Message-ID: <1517258371.14.0.467229070634.issue32336@psf.upfronthosting.co.za>


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


----------
dependencies:  -Dict order is now guaranteed, so add tests and doc for it
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32336>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:42:29 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:42:29 +0000
Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair
In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>
Message-ID: <1517258549.36.0.467229070634.issue32492@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Ned, I don't have time to finish this before 3.7b1.  Will you approve for inclusion in 3.7b2?  This isn't a user visible feature.  It's goal is to bring named tuple attribute lookup performance up to parity with regular classes using __slots__.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:46:58 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:46:58 +0000
Subject: [issue25478] Consider adding a normalize() method to
 collections.Counter()
In-Reply-To: <1445826280.05.0.307309053044.issue25478@psf.upfronthosting.co.za>
Message-ID: <1517258818.99.0.467229070634.issue25478@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25478>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:48:15 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:48:15 +0000
Subject: [issue30097] Command-line option to suppress "from None" for debugging
In-Reply-To: <1492553512.25.0.992335940269.issue30097@psf.upfronthosting.co.za>
Message-ID: <1517258895.09.0.467229070634.issue30097@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30097>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:49:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:49:17 +0000
Subject: [issue29216] Space saving step for the LRU cache
In-Reply-To: <1483979902.02.0.507353430639.issue29216@psf.upfronthosting.co.za>
Message-ID: <1517258957.51.0.467229070634.issue29216@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've lost interest in this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29216>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:51:20 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:51:20 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1517259080.72.0.467229070634.issue28864@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Closed due to lack of interest (I still think Python would be better-off with this feature).

----------
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28864>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:52:04 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:52:04 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1517259124.45.0.467229070634.issue10716@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:52:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:52:31 +0000
Subject: [issue11698] Improve repr for structseq objects to show named,
 but unindexed fields
In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za>
Message-ID: <1517259151.76.0.467229070634.issue11698@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11698>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:54:39 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:54:39 +0000
Subject: [issue25246] Alternative algorithm for deque_remove()
In-Reply-To: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>
Message-ID: <1517259279.06.0.467229070634.issue25246@psf.upfronthosting.co.za>


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


----------
priority: normal -> low
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25246>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:55:19 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:55:19 +0000
Subject: [issue21475] Support the Sitemap extension in robotparser
In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za>
Message-ID: <1517259319.83.0.467229070634.issue21475@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21475>
_______________________________________

From report at bugs.python.org  Mon Jan 29 15:57:29 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jan 2018 20:57:29 +0000
Subject: [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
Message-ID: <1517259449.9.0.467229070634.issue1818@psf.upfronthosting.co.za>


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


----------
priority: low -> normal
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1818>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:02:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 21:02:17 +0000
Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair
In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>
Message-ID: <1517259737.08.0.467229070634.issue32492@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

OK, it would be nice to get this in and the risk seems relatively low.  Good luck!

----------
priority: normal -> deferred blocker
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:15:16 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 21:15:16 +0000
Subject: [issue32394] socket lib beahavior change in 3.6.4
In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za>
Message-ID: <1517260516.65.0.467229070634.issue32394@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Steve, is there something to be done here for 3.7.0?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32394>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:15:56 2018
From: report at bugs.python.org (Joffrey F)
Date: Mon, 29 Jan 2018 21:15:56 +0000
Subject: [issue32713] tarfile.itn breaks if n is a negative float
Message-ID: <1517260556.9.0.467229070634.issue32713@psf.upfronthosting.co.za>


New submission from Joffrey F <f.joffrey at gmail.com>:

Originally reported @ github.com/docker/compose/issues/5618

It seems that tarfile.itn() attempts to execute bitwise operations on a float if the n argument is a negative float, raising a TypeError.

As pointed out in the original report, this is an issue when converting some mtime values in TarInfo._create_header

This also happens for positive floats > 8**11 - 1, but that one is less of an issue for the next two hundred years or so.

----------
components: Library (Lib)
messages: 311173
nosy: j0ffrey
priority: normal
severity: normal
status: open
title: tarfile.itn breaks if n is a negative float
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32713>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:16:45 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 21:16:45 +0000
Subject: [issue32713] tarfile.itn breaks if n is a negative float
In-Reply-To: <1517260556.9.0.467229070634.issue32713@psf.upfronthosting.co.za>
Message-ID: <1517260605.86.0.467229070634.issue32713@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32713>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:18:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 21:18:19 +0000
Subject: [issue31851] test_subprocess hangs randomly on Windows with Python 3.x
In-Reply-To: <1508781289.15.0.213398074469.issue31851@psf.upfronthosting.co.za>
Message-ID: <1517260699.57.0.467229070634.issue31851@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The test still hangs sometimes. Today on AMD64 Windows10 3.x:

http://buildbot.python.org/all/#/builders/3/builds/563

1:24:46 [409/414] test_tokenize passed (489 sec) -- running: test_subprocess (4242 sec)
1:24:50 [410/414] test_codecencodings_cn passed -- running: test_subprocess (4246 sec)
1:25:14 [411/414] test_codecmaps_kr passed -- running: test_subprocess (4270 sec)
1:25:28 [412/414] test_runpy passed -- running: test_subprocess (4284 sec)
1:25:36 [413/414] test_tempfile passed -- running: test_subprocess (4292 sec)
minkernel\crts\ucrt\src\appcrt\lowio\write.cpp(49) : Assertion failed: (_osfile(fh) & FOPEN)
command timed out: 1200 seconds without output running ['Tools\\buildbot\\test.bat', '-x64', '-j2', '--timeout', '900'], attempting to kill
program finished with exit code 1
elapsedTime=6338.784000

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31851>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:38:02 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 21:38:02 +0000
Subject: [issue28134] socket.socket(fileno=fd) does not work as documented
In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za>
Message-ID: <1517261882.22.0.467229070634.issue28134@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset b6e43af669f61a37a29d8ff0785455108e6bc29d by Christian Heimes in branch 'master':
bpo-28134: Auto-detect socket values from file descriptor (#1349)
https://github.com/python/cpython/commit/b6e43af669f61a37a29d8ff0785455108e6bc29d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28134>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:39:17 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 21:39:17 +0000
Subject: [issue28134] socket.socket(fileno=fd) does not work as documented
In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za>
Message-ID: <1517261957.65.0.467229070634.issue28134@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'm leaving the ticket open to remind me that I have to add a whatsnew entry and maybe consider a backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28134>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:00:08 2018
From: report at bugs.python.org (Joffrey F)
Date: Mon, 29 Jan 2018 22:00:08 +0000
Subject: [issue32713] tarfile.itn breaks if n is a negative float
In-Reply-To: <1517260556.9.0.467229070634.issue32713@psf.upfronthosting.co.za>
Message-ID: <1517263208.1.0.467229070634.issue32713@psf.upfronthosting.co.za>


Change by Joffrey F <f.joffrey at gmail.com>:


----------
keywords: +patch
pull_requests: +5267
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32713>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:00:44 2018
From: report at bugs.python.org (Jay Yin)
Date: Mon, 29 Jan 2018 22:00:44 +0000
Subject: [issue32714] remove resourceLoader related code since it's deprecated
Message-ID: <1517263244.89.0.467229070634.issue32714@psf.upfronthosting.co.za>


New submission from Jay Yin <jayyin11043 at gmail.com>:

I recently discovered in the documentation within the code and recent discussions with Barry, that ResourceLoader is deprecated and was wondering if we wanted to remove the code exclusively pertaining to ResourceLoader for clarity and to remove unused code. (PS if this is will be done I'll gladly contribute to doing so)

----------
messages: 311177
nosy: jayyin11043
priority: normal
severity: normal
status: open
title: remove resourceLoader related code since it's deprecated
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32714>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:01:01 2018
From: report at bugs.python.org (Jay Yin)
Date: Mon, 29 Jan 2018 22:01:01 +0000
Subject: [issue32714] remove resourceLoader related code since it's deprecated
In-Reply-To: <1517263244.89.0.467229070634.issue32714@psf.upfronthosting.co.za>
Message-ID: <1517263261.29.0.467229070634.issue32714@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32714>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:06:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 22:06:02 +0000
Subject: [issue28134] socket.socket(fileno=fd) does not work as documented
In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za>
Message-ID: <1517263562.75.0.467229070634.issue28134@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

x86-64 Sierra 3.x is grumpy:

http://buildbot.python.org/all/#/builders/14/builds/659

======================================================================
FAIL: test_uknown_socket_family_repr (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/test_socket.py", line 1645, in test_uknown_socket_family_repr
    self.assertEqual(s.proto, 23)
AssertionError: 0 != 23

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28134>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:09:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 22:09:10 +0000
Subject: [issue28099] Drop Mac OS X Tiger support in Python 3.6
In-Reply-To: <1473677501.77.0.96699360086.issue28099@psf.upfronthosting.co.za>
Message-ID: <1517263750.0.0.467229070634.issue28099@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

TBH I don't think we need to care about OS X Tiger.  I mean Apple itself doesn't care about it anymore, the last release was 10 years ago.  How about we drop its buildbot?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28099>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:10:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 22:10:59 +0000
Subject: [issue29915] Drop Mac OS X Tiger support in Python 3.7?
In-Reply-To: <1490606944.79.0.982783891513.issue29915@psf.upfronthosting.co.za>
Message-ID: <1517263859.21.0.467229070634.issue29915@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Duplicating my message to issue 28099 here:

TBH I don't think we need to care about OS X Tiger.  I mean Apple itself doesn't care about it anymore, the last release was 10 years ago.  How about we drop its buildbot?

I don't see any point in fixing asyncio for Tiger.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29915>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:11:01 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 22:11:01 +0000
Subject: [issue28134] socket.socket(fileno=fd) does not work as documented
In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za>
Message-ID: <1517263861.88.0.467229070634.issue28134@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The test for proto isn't super critical. It's mostly ignored any way. I'll submit a band-aid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28134>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:16:44 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Jan 2018 22:16:44 +0000
Subject: [issue28134] socket.socket(fileno=fd) does not work as documented
In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za>
Message-ID: <1517264204.28.0.467229070634.issue28134@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5268

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28134>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:17:50 2018
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 29 Jan 2018 22:17:50 +0000
Subject: [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1517259449.94.0.714561066657.issue1818@psf.upfronthosting.co.za>
Message-ID: <CANc-5Uxf04dESzQ4dHNZLEy4DFw1nZokE3weVeAKnrGmdfA__w@mail.gmail.com>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

FWIW, I relinquished my check-in privileges quite awhile ago. This should
almost certainly no longer be assigned to me.

S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1818>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:18:11 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Jan 2018 22:18:11 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517264291.42.0.467229070634.issue32550@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I expect that Mark only checks his mail occasionally. Sometimes GitHub lets you edit a PR and then you can also resolve the conflict yourself. If that's not the case feel free to fork the PR and submit it yourself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:18:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 22:18:39 +0000
Subject: [issue29915] Drop Mac OS X Tiger support in Python 3.7?
In-Reply-To: <1490606944.79.0.982783891513.issue29915@psf.upfronthosting.co.za>
Message-ID: <1517264319.85.0.467229070634.issue29915@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

This issue is now closed, it should be reopened if you want to reopen the discussion. The question for Tiger is how to debug bugs, since Apple forces macOS upgrades, so most users only run the latest macOS version...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29915>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:22:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 22:22:58 +0000
Subject: [issue29915] Drop Mac OS X Tiger support in Python 3.7?
In-Reply-To: <1490606944.79.0.982783891513.issue29915@psf.upfronthosting.co.za>
Message-ID: <1517264578.95.0.467229070634.issue29915@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Yury, is there a current problem with running on 10.4?  Yes, it's very old but it's been very stable and very good at finding compatibility issues with non-mainstream operating systems.  Unless there's a burning issue, let's revisit this after beta 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29915>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:25:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 22:25:44 +0000
Subject: [issue29915] Drop Mac OS X Tiger support in Python 3.7?
In-Reply-To: <1490606944.79.0.982783891513.issue29915@psf.upfronthosting.co.za>
Message-ID: <1517264744.53.0.467229070634.issue29915@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Unless there's a burning issue, let's revisit this after beta 1.

There're no burning issues currently, last fixes to asyncio made the buildbot happy.  I'm totally fine to revisit this later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29915>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:28:04 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 29 Jan 2018 22:28:04 +0000
Subject: [issue27931] Email parse IndexError <""@wiarcom.com>
In-Reply-To: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>
Message-ID: <1517264884.51.0.467229070634.issue27931@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 6ea75b174da0cf824e2acc5db6b53798f5f4e4f9 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-27931: Fix email address header parsing error (GH-5329) (GH-5431)
https://github.com/python/cpython/commit/6ea75b174da0cf824e2acc5db6b53798f5f4e4f9


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27931>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:29:50 2018
From: report at bugs.python.org (holger)
Date: Mon, 29 Jan 2018 22:29:50 +0000
Subject: [issue32715] Make create_unix_server for SOCK_DGRAM work
Message-ID: <1517264990.0.0.467229070634.issue32715@psf.upfronthosting.co.za>


New submission from holger <holger+lp at freyther.de>:

The current implementation verifies that the sock passed is a stream socket. This limitation appears to be arbitrary and is limiting.

* An AF_UNIX SOCK_DGRAM server socket becomes readable when one can accept(2) it. Just like SOCK_STREAM.
* One could provide a different factory to create a reader/writer to use a SOCK_DGRAM socket (but most likely nothing special is needed)
* A connected AF_UNIX SOCK_DGRAM socket will work with normal read/write messages just like SOCK_STREAM.

AF_UNIX, SOCK_DGRAM is interesting because it provides a reliable transport for messages. This avoids having to write message segmentation or packing messages in any kind of envelope.

----------
components: asyncio
messages: 311188
nosy: asvetlov, holger+lp, yselivanov
priority: normal
severity: normal
status: open
title: Make create_unix_server for SOCK_DGRAM work
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32715>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:33:38 2018
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 29 Jan 2018 22:33:38 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517265218.09.0.467229070634.issue32550@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

If it can wait another hour, I will be at home and can do the rebase then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:35:13 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jan 2018 22:35:13 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517265313.55.0.467229070634.issue32550@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Mark, at the moment, you have at least another 14 hours until the announced code freeze deadline :)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:35:56 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Jan 2018 22:35:56 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1517265218.09.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJsSdY2MYEKizmG0RBpPNvaeDwDvqjA=97SnMqDQzB0pw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Awesome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:37:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 22:37:06 +0000
Subject: [issue32715] Make create_unix_server for SOCK_DGRAM work
In-Reply-To: <1517264990.0.0.467229070634.issue32715@psf.upfronthosting.co.za>
Message-ID: <1517265426.1.0.467229070634.issue32715@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

SOCK_DGRAM is never reliable, even for AF_UNIX.  It might appear reliable to your test code, but there's no guarantee for that under any OS in Posix standard AFAIK.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32715>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:39:51 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Jan 2018 22:39:51 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1517265591.74.0.467229070634.issue30697@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

No opinion from me on how critical this is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:40:13 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 29 Jan 2018 22:40:13 +0000
Subject: [issue32714] remove resourceLoader related code since it's deprecated
In-Reply-To: <1517263244.89.0.467229070634.issue32714@psf.upfronthosting.co.za>
Message-ID: <1517265613.89.0.467229070634.issue32714@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

We can't remove the code because it might still be used by third parties.  Deprecation generally means we inform users that they shouldn't use the code any more (possibly with a DeprecationWarning, although we decided not to do that in this case).  We definitely won't remove the code in 3.7.  We can think about it for 3.8

----------
nosy: +barry, brett.cannon
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32714>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:58:48 2018
From: report at bugs.python.org (Takayuki SHIMIZUKAWA)
Date: Mon, 29 Jan 2018 22:58:48 +0000
Subject: [issue32716] setup.py register --repository is broken
Message-ID: <1517266728.23.0.467229070634.issue32716@psf.upfronthosting.co.za>


New submission from Takayuki SHIMIZUKAWA <shimizukawa at gmail.com>:

Although document https://docs.python.org/3.6/distutils/packageindex.html#package-cmdoptions says "The --repository or -r option lets you specify a PyPI server different from the default", if there is no URL specified in ``.pypirc`` it will display "ValueError: <URL> not found in .pypirc".


::

  $ python3 setup.py register -r https://test.pypi.org/legacy/
  running register
  running egg_info
  writing dependency_links to test.egg-info/dependency_links.txt
  writing top-level names to test.egg-info/top_level.txt
  writing test.egg-info/PKG-INFO
  reading manifest file 'test.egg-info/SOURCES.txt'
  writing manifest file 'test.egg-info/SOURCES.txt'
  Traceback (most recent call last):
    File "setup.py", line 4, in <module>
      setup(name='test')
    File "/usr/lib/python3.5/distutils/core.py", line 148, in setup
      dist.run_commands()
    File "/usr/lib/python3.5/distutils/dist.py", line 955, in run_commands
      self.run_command(cmd)
    File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
      cmd_obj.run()
    File "/usr/lib/python3/dist-packages/setuptools/command/register.py", line 10, in run
      orig.register.run(self)
    File "/usr/lib/python3.5/distutils/command/register.py", line 45, in run
      self._set_config()
    File "/usr/lib/python3.5/distutils/command/register.py", line 80, in _set_config
      raise ValueError('%s not found in .pypirc' % self.repository)
  ValueError: https://test.pypi.org/legacy/ not found in .pypirc

  $ python3 -V
  Python 3.5.2

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:    Ubuntu 16.04.3 LTS
  Release:        16.04
  Codename:       xenial

This behavior could be confirmed on Windows.

I think there are two correction methods.
One is to fix it so that we can specify any URL regardless of the setting of .pypirc.
The other is to write in the document that "-r option can specify server name or URL in .pypirc".

----------
components: Distutils
messages: 311195
nosy: dstufft, eric.araujo, shimizukawa
priority: normal
severity: normal
status: open
title: setup.py register --repository is broken
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32716>
_______________________________________

From report at bugs.python.org  Mon Jan 29 18:06:20 2018
From: report at bugs.python.org (holger)
Date: Mon, 29 Jan 2018 23:06:20 +0000
Subject: [issue32715] Make create_unix_server for SOCK_DGRAM work
In-Reply-To: <1517264990.0.0.467229070634.issue32715@psf.upfronthosting.co.za>
Message-ID: <1517267180.87.0.467229070634.issue32715@psf.upfronthosting.co.za>


holger <holger+lp at freyther.de> added the comment:

Could you please tell me which exact posix document and paragraph says that?

In Linux sending can fail but once sendmsg worked the message is enqueued on the other socket (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/unix/af_unix.c?id=110af3acb8cfd79dcb5676a01e07cb2b6afa4c04#n1626).

In FreeBSD (http://fxr.watson.org/fxr/source/kern/uipc_usrreq.c?v=FREEBSD10#L911) it looks similar. If the mbuf can't be put into the recvq of the remote socket.. an error will be returned.

What about SEQPACKET support?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32715>
_______________________________________

From report at bugs.python.org  Mon Jan 29 18:10:20 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Jan 2018 23:10:20 +0000
Subject: [issue32394] socket lib beahavior change in 3.6.4
In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za>
Message-ID: <1517267420.07.0.467229070634.issue32394@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I like Kamil's suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32394>
_______________________________________

From report at bugs.python.org  Mon Jan 29 18:16:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 29 Jan 2018 23:16:47 +0000
Subject: [issue32715] Make create_unix_server for SOCK_DGRAM work
In-Reply-To: <1517264990.0.0.467229070634.issue32715@psf.upfronthosting.co.za>
Message-ID: <1517267807.61.0.467229070634.issue32715@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Hm, maybe I'm mistaken here, but I have no time right now to confirm.

I'll reopen the issue so that we can consider this (and especially SEQPACKET) for 3.8.  Sorry for insta-reject :)

----------
resolution: rejected -> 
stage: resolved -> 
status: closed -> open
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32715>
_______________________________________

From report at bugs.python.org  Mon Jan 29 18:35:04 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jan 2018 23:35:04 +0000
Subject: [issue32226] Implement PEP 560: Core support for typing module and
 generic types
In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za>
Message-ID: <1517268904.76.0.467229070634.issue32226@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

OK, I will close this issue, and open separate issues for documentation, Union, etc.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32226>
_______________________________________

From report at bugs.python.org  Mon Jan 29 18:39:36 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jan 2018 23:39:36 +0000
Subject: [issue32717] Document PEP 560
Message-ID: <1517269176.0.0.467229070634.issue32717@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi <levkivskyi at gmail.com>:

This should include:
* Short documentation PR for `__mro_entry__` and `__base_subclass__` methods.
* The `__class_getitem__` C API calling convention (with motivation, many classes are implemented in C but are generic in nature, like numpy.ndarray) in PEP 560.

----------
assignee: levkivskyi
components: Documentation
messages: 311200
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Document PEP 560
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32717>
_______________________________________

From report at bugs.python.org  Mon Jan 29 18:50:15 2018
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 29 Jan 2018 23:50:15 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517269815.42.0.467229070634.issue32550@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Rebased, pushed and CI is green.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:09:27 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 30 Jan 2018 00:09:27 +0000
Subject: [issue31851] test_subprocess hangs randomly on Windows with Python 3.x
In-Reply-To: <1508781289.15.0.213398074469.issue31851@psf.upfronthosting.co.za>
Message-ID: <1517270967.2.0.467229070634.issue31851@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

It's an assert, so it only affects debug builds - releases are not impacted.

I'm guessing there's a test that spawns a subprocess and doesn't initialize it properly for tests (specifically the part where we disable assertions on Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31851>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:28:19 2018
From: report at bugs.python.org (cowlinator)
Date: Tue, 30 Jan 2018 00:28:19 +0000
Subject: [issue22374] Replace contextmanager example and improve explanation
In-Reply-To: <1410296292.35.0.34327651623.issue22374@psf.upfronthosting.co.za>
Message-ID: <1517272099.56.0.467229070634.issue22374@psf.upfronthosting.co.za>


cowlinator <cowlinator at gmail.com> added the comment:

I would like to second the improved explanation of contextlib.contextmanager, and additionally point out another problem:  
A very important piece of information is missing from the documentation:  how to return data from the contextmanager-wrapped function.  

I had to go look up the source code, which had a wonderful explanation in the comments: https://gist.github.com/enuomi/1385336#file-contextlib-py-L56 

In particular, note that 

@contextmanager
def some_generator(<arguments>):
  yield <return_data>

can be used to return <return_data> to the caller, via

with some_generator(<arguments>) as <return_data>:
  print(return_data)

This information is wholly and completely missing from the contextlib.contextmanager documentation.

----------
nosy: +cowlinator
versions: +Python 2.7, Python 3.4, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22374>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:29:57 2018
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 30 Jan 2018 00:29:57 +0000
Subject: [issue32218] add __iter__ to enum.Flag members
In-Reply-To: <1512445452.31.0.213398074469.issue32218@psf.upfronthosting.co.za>
Message-ID: <1517272197.56.0.467229070634.issue32218@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

This functionality is now in the third-party aenum* library.

Are there any strong use-cases for this behavior such that it should be in the stdlib?


* as of version 2.0.10, available on PyPI, and I am its author

----------
nosy: +barry, eli.bendersky, rhettinger
stage: needs patch -> 
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32218>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:41:12 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Jan 2018 00:41:12 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517272872.64.0.467229070634.issue32550@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 332cd5ee4ff42c9904c56e68a1028f383f7fc9a8 by Raymond Hettinger (Mark Shannon) in branch 'master':
bpo-32550. Remove the STORE_ANNOTATION bytecode. (GH-5181)
https://github.com/python/cpython/commit/332cd5ee4ff42c9904c56e68a1028f383f7fc9a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:41:39 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Jan 2018 00:41:39 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>
Message-ID: <1517272899.49.0.467229070634.issue32550@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:54:56 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Jan 2018 00:54:56 +0000
Subject: [issue32718] Install PowerShell activation scripts for venv for all
 platforms
Message-ID: <1517273696.22.0.467229070634.issue32718@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Thanks to https://github.com/PowerShell/PowerShell, PowerShell Core is cross-platform. That suggests that the Activate.ps1 file for venv should be moved to the common/ directory instead of existing only in the nt/ directory.

----------
components: Library (Lib)
messages: 311206
nosy: brett.cannon, vinay.sajip
priority: low
severity: normal
status: open
title: Install PowerShell activation scripts for venv for all platforms
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32718>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:55:44 2018
From: report at bugs.python.org (Jay Yin)
Date: Tue, 30 Jan 2018 00:55:44 +0000
Subject: [issue32714] remove resourceLoader related code since it's deprecated
In-Reply-To: <1517263244.89.0.467229070634.issue32714@psf.upfronthosting.co.za>
Message-ID: <1517273744.47.0.467229070634.issue32714@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

Alright I see, so I guess I'll set this as "postponed" and close it?

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32714>
_______________________________________

From report at bugs.python.org  Mon Jan 29 20:10:30 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 01:10:30 +0000
Subject: [issue27931] Email parse IndexError <""@wiarcom.com>
In-Reply-To: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>
Message-ID: <1517274630.4.0.467229070634.issue27931@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27931>
_______________________________________

From report at bugs.python.org  Mon Jan 29 20:13:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Jan 2018 01:13:38 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517274818.43.0.467229070634.issue32690@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Can someone please revert the 3.6 change, as asked by Guido?

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Mon Jan 29 20:15:20 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 30 Jan 2018 01:15:20 +0000
Subject: [issue32550] STORE_ANNOTATION bytecode is unnecessary and can be
 removed.
In-Reply-To: <1517272899.52.0.714561066657.issue32550@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJDXx1gYqtKWO04CpsN4WawZ0aavZd0scJuq+BTkoroiA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

W00t!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Mon Jan 29 20:23:46 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 01:23:46 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517275426.8.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 7f8bfc9b9a8381ddb768421b5dd5cbd970266190 by Eric Snow in branch 'master':
bpo-32604: Expose the subinterpreters C-API in a "private" stdlib module. (gh-1748)
https://github.com/python/cpython/commit/7f8bfc9b9a8381ddb768421b5dd5cbd970266190


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 20:30:54 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 01:30:54 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517275854.67.0.467229070634.issue32604@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +5269

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 20:33:02 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 01:33:02 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517275982.49.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I've merged the patch without Windows support, which shouldn't be a problem given the purpose of the extension module.  I've also added a PR for get the module building under Windows.  I'd like to get that resolved ASAP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 20:47:45 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 01:47:45 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517276865.9.0.467229070634.issue32604@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Eric, looks like some buildbots are unhappy, for instance:

http://buildbot.python.org/all/#builders/13/builds/648

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 21:06:59 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 30 Jan 2018 02:06:59 +0000
Subject: [issue32694] Can no longer specify OpenSLL locations with CPPFLAGS /
 LDFLAGS ?
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517278019.03.0.467229070634.issue32694@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Can we also cover Brew?

Here's the dumb little configure wrapper I use:

```
#!/bin/sh

export CPPFLAGS="-I$(brew --prefix sqlite3)/include -I$(brew --prefix zlib)/include"
export LDFLAGS="-L$(brew --prefix sqlite3)/lib -L$(brew --prefix zlib)/lib"
export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig"

./configure
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Mon Jan 29 21:25:55 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Jan 2018 02:25:55 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517279155.55.0.467229070634.issue32690@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Can someone please revert the 3.6 change, as asked by Guido?

You have commit rights, so if you're impatient, go ahead.  Otherwise, I still need to figure-out out the github-foo needed to revert on something other than the master branch.  This isn't even my issue. I was trying to help out and didn't expect the Spanish Inquisition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Mon Jan 29 21:28:06 2018
From: report at bugs.python.org (Jay Yin)
Date: Tue, 30 Jan 2018 02:28:06 +0000
Subject: [issue32714] remove resourceLoader related code since it's deprecated
In-Reply-To: <1517263244.89.0.467229070634.issue32714@psf.upfronthosting.co.za>
Message-ID: <1517279286.81.0.467229070634.issue32714@psf.upfronthosting.co.za>


Change by Jay Yin <jayyin11043 at gmail.com>:


----------
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32714>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:00:56 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 03:00:56 +0000
Subject: [issue32719] fatal error raised when Ctrl-C print loop
Message-ID: <1517281256.8.0.467229070634.issue32719@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

A simple snippet:

import threading

def func():
	while True:
		print(1,2,3,4,5,6,7,8,9,10) 

t1 = threading.Thread(target=func)
t2 = threading.Thread(target=func)
t1.start()
t2.start()

Running this snippet and Ctrl-C raises FatalError:

^CException ignored in: <module 'threading' from '/root/Python-2.8.1/Lib/threading.py'>
Traceback (most recent call last):
1 2 3 4 5 6 7 8 9 10
  File "/root/Python-2.8.1/Lib/threading.py", line 1294, in _shutdown
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
    t.join()
  File "/root/Python-2.8.1/Lib/threading.py", line 1056, in join
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
    self._wait_for_tstate_lock()
  File "/root/Python-2.8.1/Lib/threading.py", line 1072, in _wait_for_tstate_lock
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
    elif lock.acquire(block, timeout):
KeyboardInterrupt
Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to daemon threads

Thread 0x00007f7f6b22e700 (most recent call first):
  File "/tmp/test.py", line 5 in func
  File "/root/Python-2.8.1/Lib/threading.py", line 864 in run
  File "/root/Python-2.8.1/Lib/threading.py", line 916 in _bootstrap_inner
  File "/root/Python-2.8.1/Lib/threading.py", line 884 in _bootstrap

Thread 0x00007f7f6ba2f700 (most recent call first):
  File "/tmp/test.py", line 5 in func
  File "/root/Python-2.8.1/Lib/threading.py", line 864 in run
  File "/root/Python-2.8.1/Lib/threading.py", line 916 in _bootstrap_inner
  File "/root/Python-2.8.1/Lib/threading.py", line 884 in _bootstrap

Current thread 0x00007f7f73761740 (most recent call first):
???(??) /* segfault(core dump) */

----------
components: IO
messages: 311215
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: fatal error raised when Ctrl-C print loop
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32719>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:01:54 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 03:01:54 +0000
Subject: [issue32719] fatal error raised when Ctrl-C print loop
In-Reply-To: <1517281256.8.0.467229070634.issue32719@psf.upfronthosting.co.za>
Message-ID: <1517281314.36.0.467229070634.issue32719@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

It's 3.6 and 3.7. The dir name in traceback doesn't matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32719>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:19:39 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 03:19:39 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517282379.54.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Yeah, I'm looking into it.  Also, I noticed some refleaks that I'll be sorting out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:23:05 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 03:23:05 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517282585.02.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On 4 of the buildbots:


======================================================================
ERROR: test_drop_multiple_times (test.test__xxsubinterpreters.ChannelTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 890, in test_drop_multiple_times
    interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3)
======================================================================
ERROR: test_drop_single_user (test.test__xxsubinterpreters.ChannelTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 848, in test_drop_single_user
    interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3)
======================================================================
ERROR: test_drop_used_multiple_times_by_single_user (test.test__xxsubinterpreters.ChannelTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 957, in test_drop_used_multiple_times_by_single_user
    interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3)
======================================================================
ERROR: test_drop_with_unused_items (test.test__xxsubinterpreters.ChannelTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 899, in test_drop_with_unused_items
    interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:23:39 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 03:23:39 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517282619.65.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On the PPC64 AIX 3.x buildbot:

======================================================================
FAIL: test_repr (test.test__xxsubinterpreters.ChannelIDTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test__xxsubinterpreters.py", line 784, in test_repr
    self.assertEqual(repr(cid), 'ChannelID(10)')
AssertionError: 'ChannelID(0)' != 'ChannelID(10)'
- ChannelID(0)
+ ChannelID(10)
?           +

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:29:29 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 03:29:29 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517282969.06.0.467229070634.issue32604@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +5270

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:30:08 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 03:30:08 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517283008.46.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I just put up a PR that should fix the 4 buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:36:09 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 30 Jan 2018 03:36:09 +0000
Subject: [issue32701] Typo in quopri documentation
In-Reply-To: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>
Message-ID: <1517283369.63.0.467229070634.issue32701@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 9424dcbb3e20a26dfdd81659303b989f7d3da044 by Mariatta (Julien Palard) in branch 'master':
bpo-32701: Clarify the quotetabs flag in quopri documentation (GH-5401)
https://github.com/python/cpython/commit/9424dcbb3e20a26dfdd81659303b989f7d3da044


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:36:19 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Jan 2018 03:36:19 +0000
Subject: [issue32701] Typo in quopri documentation
In-Reply-To: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>
Message-ID: <1517283379.55.0.467229070634.issue32701@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5271

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:02:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Jan 2018 04:02:17 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517284937.07.0.467229070634.issue32690@psf.upfronthosting.co.za>


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


----------
Removed message: https://bugs.python.org/msg311214

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:04:17 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 04:04:17 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517285057.97.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 83e64c8a544028ae677af2a0bc268dbe1c11cc3a by Eric Snow in branch 'master':
bpo-32604: NULL-terminate kwlist in channel_drop_interpreter(). (gh-5437)
https://github.com/python/cpython/commit/83e64c8a544028ae677af2a0bc268dbe1c11cc3a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:04:42 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Jan 2018 04:04:42 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517285082.19.0.467229070634.issue32690@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Ned, can you do the reversion?  I'm a little git/github challenged on how to revert this one.

----------
assignee: ncoghlan -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:04:48 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Jan 2018 04:04:48 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517285088.19.0.467229070634.issue32604@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

The buildbots should be happier now.  I'll keep an eye on them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:10:39 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 04:10:39 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517285439.97.0.467229070634.issue32690@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I'll make sure it's taken care of prior to 3.6.5rc1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:16:23 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 30 Jan 2018 04:16:23 +0000
Subject: [issue32701] Typo in quopri documentation
In-Reply-To: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>
Message-ID: <1517285783.45.0.467229070634.issue32701@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 04f99ba9d7186278eaf072e9a62c03aa63a8a6bb by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-32701: Clarify the quotetabs flag in quopri documentation (GH-5401) (GH-5438)
https://github.com/python/cpython/commit/04f99ba9d7186278eaf072e9a62c03aa63a8a6bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:16:45 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Jan 2018 04:16:45 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517285804.99.0.467229070634.issue32690@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +5272
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:22:33 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Jan 2018 04:22:33 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517286153.0.0.467229070634.issue32690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Noting the git-fu required for non-master reverts:

- check out the branch of interest and ensure it's up to date
- `git checkout -b bpo-32690-revert-3.6-backport`
- `git revert 9105879bfd7133ecbac67f3e9c0bacf6e477de5a`
- edit commit message as appropriate
- create a PR targeting the branch of interest: https://github.com/python/cpython/pull/5439

Devguide issue here: https://github.com/python/devguide/issues/319

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:23:14 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 30 Jan 2018 04:23:14 +0000
Subject: [issue32701] Typo in quopri documentation
In-Reply-To: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>
Message-ID: <1517286194.52.0.467229070634.issue32701@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:45:29 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Jan 2018 04:45:29 +0000
Subject: [issue32720] Format mini-language integer definition is incorrect
Message-ID: <1517287529.39.0.467229070634.issue32720@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I just noticed that https://docs.python.org/3/library/string.html#formatspec links to the "integer" definition in the main Python grammar for the permitted format of numeric fields.

This isn't accurate:

```
>>> format(10e4, ",.2f")
'100,000.00'
>>> format(10e4, ",.0x2f")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier
>>> format(10e4, ",.2_2f")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier
```

Instead, the `width` and `precision` subfields should be defined as "digit+"

----------
assignee: docs at python
components: Documentation
messages: 311229
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Format mini-language integer definition is incorrect
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32720>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:27:41 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 05:27:41 +0000
Subject: [issue25942] Add a new optional cleanup_timeout parameter to
 subprocess.call()
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1517290061.65.0.467229070634.issue25942@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset f4d644f36ffb6cb11b34bfcf533c14cfaebf709a by Gregory P. Smith in branch 'master':
bpo-25942: make subprocess more graceful on ^C (GH-5026)
https://github.com/python/cpython/commit/f4d644f36ffb6cb11b34bfcf533c14cfaebf709a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:27:44 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Jan 2018 05:27:44 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517290064.16.0.467229070634.issue32690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 05f91a42cd9575ef338a67bd04855b44f6ac20c2 by Nick Coghlan in branch '3.6':
[3.6] Revert "bpo-32690: Preserve order of locals() (GH-5379) (#5390)"
https://github.com/python/cpython/commit/05f91a42cd9575ef338a67bd04855b44f6ac20c2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:28:39 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Jan 2018 05:28:39 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517290119.96.0.467229070634.issue32690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, this is back the way it was on the 3.6 branch now, while keeping the change on the 3.7 branch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:29:15 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 05:29:15 +0000
Subject: [issue32721] test_hashlib fails if _md5 is not built
Message-ID: <1517290155.28.0.467229070634.issue32721@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

$ make
$ rm build/lib.linux-x86_64-3.7/_md5.cpython-37m-x86_64-linux-gnu.so 
$ ./python -m test test_hashlib
Run tests sequentially
0:00:00 load avg: 1.11 [1/1] test_hashlib
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/hashlib.py", line 243, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/home/benjamin/dev/python/cpython/Lib/hashlib.py", line 113, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
/home/benjamin/dev/python/cpython/Lib/test/test_hashlib.py:90: UserWarning: Did a C extension fail to compile? No module named '_md5'
  warnings.warn('Did a C extension fail to compile? %s' % error)
Warning -- logging._handlerList was modified by test_hashlib
  Before: (139817255081928, [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>, <weakref at 0x7f29ba4f71d8; to 'StreamHandler' at 0x7f29ba4ee8d0>], [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>])
  After:  (139817255081928, [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>, <weakref at 0x7f29ba4f71d8; to 'StreamHandler' at 0x7f29ba4ee8d0>], [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>, <weakref at 0x7f29ba4f71d8; to 'StreamHandler' at 0x7f29ba4ee8d0>]) 
test test_hashlib failed -- Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_hashlib.py", line 209, in test_get_builtin_constructor
    constructor = get_builtin_constructor('md5')
  File "/home/benjamin/dev/python/cpython/Lib/hashlib.py", line 113, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5

test_hashlib failed

1 test failed:
    test_hashlib

Total duration: 397 ms
Tests result: FAILURE

----------
components: Build
messages: 311233
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_hashlib fails if _md5 is not built
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32721>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:31:53 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 05:31:53 +0000
Subject: [issue32721] test_hashlib fails if _md5 is not built
In-Reply-To: <1517290155.28.0.467229070634.issue32721@psf.upfronthosting.co.za>
Message-ID: <1517290313.56.0.467229070634.issue32721@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +5273
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32721>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:31:57 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 05:31:57 +0000
Subject: [issue25942] Do not immediately SIGKILL subprocess child processes
 upon ^C
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1517290317.88.0.467229070634.issue25942@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I went with my change to give the child process a small amount of time to cleanup by default.  Not perfect, but this should be more similar to the Python <=3.2 behavior.  Lets see if any issues crop up during the 3.7 betas.

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
title: Add a new optional cleanup_timeout parameter to subprocess.call() -> Do not immediately SIGKILL subprocess child processes upon ^C

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:41:01 2018
From: report at bugs.python.org (Soothsayer)
Date: Tue, 30 Jan 2018 05:41:01 +0000
Subject: [issue32722] Classes
Message-ID: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>


New submission from Soothsayer <qd57h9m4q2 at snkmail.com>:

In the Python tutorial, in "9. Classes", in "9.10 Generator expression", a list of sample generator expressions used as arguments to functions is given. However, one of the examples isn't a generator expression, it's a set comprehension.

sine_table = {x: sin(x*pi/180) for x in range(0, 91)}

Perhaps this used to be a call to set() and was mistakenly converted?

----------
assignee: docs at python
components: Documentation
messages: 311235
nosy: Soothsayer, docs at python
priority: normal
severity: normal
status: open
title: Classes
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:41:46 2018
From: report at bugs.python.org (Soothsayer)
Date: Tue, 30 Jan 2018 05:41:46 +0000
Subject: [issue32722] Classes
In-Reply-To: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>
Message-ID: <1517290906.43.0.467229070634.issue32722@psf.upfronthosting.co.za>


Change by Soothsayer <qd57h9m4q2 at snkmail.com>:


----------
versions: +Python 3.5, Python 3.6 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:44:19 2018
From: report at bugs.python.org (Soothsayer)
Date: Tue, 30 Jan 2018 05:44:19 +0000
Subject: [issue32722] Classes
In-Reply-To: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>
Message-ID: <1517291059.28.0.467229070634.issue32722@psf.upfronthosting.co.za>


Soothsayer <qd57h9m4q2 at snkmail.com> added the comment:

Correction: it's a dictionary comprehension, and it did indeed used to be a call to dict() in the 2.7 documentation.

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:54:10 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 05:54:10 +0000
Subject: [issue21417] Compression level for zipfile
In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za>
Message-ID: <1517291650.07.0.467229070634.issue21417@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset ce237c7d58ba207575cdfb0195a58a6407fbf717 by Gregory P. Smith (Bo Bayles) in branch 'master':
bpo-21417: Add compresslevel= to the zipfile module (GH-5385)
https://github.com/python/cpython/commit/ce237c7d58ba207575cdfb0195a58a6407fbf717


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21417>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:04:38 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 06:04:38 +0000
Subject: [issue32681] Fix uninitialized variable in os_dup2_impl
In-Reply-To: <20180126153414.GA604@xps>
Message-ID: <1517292278.72.0.467229070634.issue32681@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 3d86e484de6334fe16cbab512744597bd0de4e80 by Gregory P. Smith (St?phane Wirtel) in branch 'master':
bpo-32681: Fix an uninitialized variable in the C implementation of os.dup2 (GH-5346)
https://github.com/python/cpython/commit/3d86e484de6334fe16cbab512744597bd0de4e80


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:05:06 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 06:05:06 +0000
Subject: [issue32681] Fix uninitialized variable in os_dup2_impl
In-Reply-To: <20180126153414.GA604@xps>
Message-ID: <1517292306.62.0.467229070634.issue32681@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:05:27 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 06:05:27 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1517292327.66.0.467229070634.issue32441@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

https://github.com/python/cpython/pull/5346 (merged) should fix that warning.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:13:32 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 06:13:32 +0000
Subject: [issue32723] codecs.open
Message-ID: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

>>> import codecs
>>> f = codecs.open('/tmp/a', 'w', errors='replace')
>>> f.errors
'strict'

Passing errors to codecs.open without encoding doesn't work. Can't get this from doc and I don't think it should silently ignore the passing argument.

----------
components: Library (Lib)
messages: 311240
nosy: lemburg, vstinner, xiang.zhang
priority: normal
severity: normal
status: open
title: codecs.open
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:13:54 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 06:13:54 +0000
Subject: [issue32723] codecs.open silently ignores argument errors
In-Reply-To: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>
Message-ID: <1517292834.68.0.467229070634.issue32723@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
title: codecs.open -> codecs.open silently ignores argument errors
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:14:20 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 06:14:20 +0000
Subject: [issue32721] test_hashlib fails if _md5 is not built
In-Reply-To: <1517290155.28.0.467229070634.issue32721@psf.upfronthosting.co.za>
Message-ID: <1517292860.35.0.467229070634.issue32721@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 95441809ef77a8df5e14601ade6c054ef7114c02 by Benjamin Peterson in branch 'master':
closes bpo-32721: do not fail test_hashlib if _md5 isn't available (GH-5441)
https://github.com/python/cpython/commit/95441809ef77a8df5e14601ade6c054ef7114c02


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32721>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:14:36 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 30 Jan 2018 06:14:36 +0000
Subject: [issue32721] test_hashlib fails if _md5 is not built
In-Reply-To: <1517290155.28.0.467229070634.issue32721@psf.upfronthosting.co.za>
Message-ID: <1517292876.59.0.467229070634.issue32721@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5274

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32721>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:19:40 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 06:19:40 +0000
Subject: [issue32102] Add "capture_output=True" option to subprocess.run
In-Reply-To: <1511244827.04.0.213398074469.issue32102@psf.upfronthosting.co.za>
Message-ID: <1517293180.74.0.467229070634.issue32102@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32102>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:36:24 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 30 Jan 2018 06:36:24 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1517294184.16.0.467229070634.issue28914@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

As a side note, EPOLL_CLOEXEC is also missing on Android if *both* of the following conditions hold:

1. The build target is Android API < 21 (issue 32654)
2. Android NDK r15 or newer is used

The second condition is related to a workaround in NDK [1]. For now it's proposed to use NDK r14 to build CPython [2], so this issue can be left to the future. I've also asked if the relevant workaround in NDK can be reverted [3].

[1] https://android-review.googlesource.com/c/platform/bionic/+/401372
[2] https://github.com/python/cpython/pull/1629
[3] https://github.com/android-ndk/ndk/issues/302#issuecomment-361488327

----------
components: +Build, Cross-Build
nosy: +Alex.Willmer, yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:40:41 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 06:40:41 +0000
Subject: [issue32102] Add "capture_output=True" option to subprocess.run
In-Reply-To: <1511244827.04.0.213398074469.issue32102@psf.upfronthosting.co.za>
Message-ID: <1517294441.08.0.467229070634.issue32102@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset ce0f33d04528fcafc673a8707871f8430d8f7ce8 by Gregory P. Smith (Bo Bayles) in branch 'master':
bpo-32102 Add "capture_output=True" to subprocess.run (GH-5149)
https://github.com/python/cpython/commit/ce0f33d04528fcafc673a8707871f8430d8f7ce8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32102>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:43:14 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 06:43:14 +0000
Subject: [issue32102] Add "capture_output=True" option to subprocess.run
In-Reply-To: <1511244827.04.0.213398074469.issue32102@psf.upfronthosting.co.za>
Message-ID: <1517294594.75.0.467229070634.issue32102@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks Bo.  I agree with Nick, this is a readability win for a common annoying to type otherwise case.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32102>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:52:14 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 06:52:14 +0000
Subject: [issue21417] Compression level for zipfile
In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za>
Message-ID: <1517295134.05.0.467229070634.issue21417@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21417>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:01:34 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 07:01:34 +0000
Subject: [issue32721] test_hashlib fails if _md5 is not built
In-Reply-To: <1517290155.28.0.467229070634.issue32721@psf.upfronthosting.co.za>
Message-ID: <1517295694.61.0.467229070634.issue32721@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 6b2bbcc4cca414f35f67caa4674f59f41ff638ea by Benjamin Peterson (Miss Islington (bot)) in branch '3.6':
closes bpo-32721: do not fail test_hashlib if _md5 isn't available (GH-5441) (GH-5442)
https://github.com/python/cpython/commit/6b2bbcc4cca414f35f67caa4674f59f41ff638ea


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32721>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:13:06 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 07:13:06 +0000
Subject: [issue30117] test_lib2to3.test_parser.test_all_project_files() fails
In-Reply-To: <1492692321.21.0.476906243501.issue30117@psf.upfronthosting.co.za>
Message-ID: <1517296386.19.0.467229070634.issue30117@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 14e976e00e65bf343ba0fca016c3c9132a843daf by Benjamin Peterson (Eric Appelt) in branch 'master':
closes bpo-30117: fix lib2to3 ParserIdempotency test (GH-1242)
https://github.com/python/cpython/commit/14e976e00e65bf343ba0fca016c3c9132a843daf


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30117>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:14:37 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 07:14:37 +0000
Subject: [issue30117] test_lib2to3.test_parser.test_all_project_files() fails
In-Reply-To: <1492692321.21.0.476906243501.issue30117@psf.upfronthosting.co.za>
Message-ID: <1517296477.93.0.467229070634.issue30117@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +5275

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30117>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:16:36 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 07:16:36 +0000
Subject: [issue32441] os.dup2 should return the new fd
In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za>
Message-ID: <1517296596.82.0.467229070634.issue32441@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32441>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:27:31 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 07:27:31 +0000
Subject: [issue31961] subprocess._execute_child doesn't accept a single
 PathLike argument for args
In-Reply-To: <1509989245.86.0.213398074469.issue31961@psf.upfronthosting.co.za>
Message-ID: <1517297251.27.0.467229070634.issue31961@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset dd42cb71f2cb02f3a32f016137b12a146bc0d0e2 by Gregory P. Smith (Anders Lorentsen) in branch 'master':
bpo-31961: subprocess now accepts path-like args (GH-4329)
https://github.com/python/cpython/commit/dd42cb71f2cb02f3a32f016137b12a146bc0d0e2


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31961>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:27:51 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 30 Jan 2018 07:27:51 +0000
Subject: [issue32723] codecs.open silently ignores argument errors
In-Reply-To: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>
Message-ID: <1517297271.87.0.467229070634.issue32723@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

On both Py2 and Py3, calling codecs.open without passing an encoding argument is equivalent to adding 'b' to the mode string and calling the built-in open function directly; it returns a plain binary mode file object. The errors parameter is meaningless because no decoding is being performed (there will never be any errors to handle).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:32:27 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 07:32:27 +0000
Subject: [issue31961] subprocess._execute_child doesn't accept a single
 PathLike argument for args
In-Reply-To: <1509989245.86.0.213398074469.issue31961@psf.upfronthosting.co.za>
Message-ID: <1517297547.39.0.467229070634.issue31961@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
versions:  -Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31961>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:33:04 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 30 Jan 2018 07:33:04 +0000
Subject: [issue32705] Current Android does not have posix_spawn
In-Reply-To: <1517211738.51.0.467229070634.issue32705@psf.upfronthosting.co.za>
Message-ID: <1517297584.0.0.467229070634.issue32705@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

With https://github.com/python/cpython/pull/5418 merged, I guess this issue can be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32705>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:36:58 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 07:36:58 +0000
Subject: [issue31961] subprocess._execute_child doesn't accept a single
 PathLike argument for args
In-Reply-To: <1509989245.86.0.213398074469.issue31961@psf.upfronthosting.co.za>
Message-ID: <1517297818.86.0.467229070634.issue31961@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for the PR!  I accepted it as this makes sense as a feature.

<meme> pathlib all the things! </meme>

I think the code be polished up a bit to not rely on catching TypeError but this gets the feature in before the 3.7 feature freeze (just).  If further changes are needed or bugs are found, they can be addressed during the 3.7 betas. :)

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31961>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:38:25 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 07:38:25 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517297905.26.0.467229070634.issue20104@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:38:33 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 07:38:33 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1517297913.12.0.467229070634.issue20104@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:40:36 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 07:40:36 +0000
Subject: [issue32705] Current Android does not have posix_spawn
In-Reply-To: <1517211738.51.0.467229070634.issue32705@psf.upfronthosting.co.za>
Message-ID: <1517298036.07.0.467229070634.issue32705@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

likely.  i don't have an android build, please reopen if there are still android posix_spawn related build issues.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32705>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:55:49 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Jan 2018 07:55:49 +0000
Subject: [issue28134] socket.socket(fileno=fd) does not work as documented
In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za>
Message-ID: <1517298949.04.0.467229070634.issue28134@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 2e0ecde8d74f5fc0e3e3e39216975cc70efc4796 by Christian Heimes in branch 'master':
bpo-28134: Ignore proto in unknown socket test (GH-5435)
https://github.com/python/cpython/commit/2e0ecde8d74f5fc0e3e3e39216975cc70efc4796


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28134>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:59:33 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 07:59:33 +0000
Subject: [issue32724] Fix references to commands in Doc/pdb.rst
Message-ID: <1517299173.52.0.467229070634.issue32724@psf.upfronthosting.co.za>


New submission from St?phane Wirtel <stephane at wirtel.be>:

In the documentation of pdb.rst, we explain that we have to use some commands, but there is no link to these commands.

----------
assignee: docs at python
components: Documentation
messages: 311253
nosy: Mariatta, docs at python, matrixise
priority: normal
severity: normal
status: open
title: Fix references to commands in Doc/pdb.rst
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32724>
_______________________________________

From report at bugs.python.org  Tue Jan 30 03:02:37 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 08:02:37 +0000
Subject: [issue32724] Fix references to commands in Doc/pdb.rst
In-Reply-To: <1517299173.52.0.467229070634.issue32724@psf.upfronthosting.co.za>
Message-ID: <1517299357.05.0.467229070634.issue32724@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +5276
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32724>
_______________________________________

From report at bugs.python.org  Tue Jan 30 03:45:02 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 08:45:02 +0000
Subject: [issue22908] ZipExtFile in zipfile can be seekable
In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za>
Message-ID: <1517301902.47.0.467229070634.issue22908@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee: serhiy.storchaka -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22908>
_______________________________________

From report at bugs.python.org  Tue Jan 30 03:51:42 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 08:51:42 +0000
Subject: [issue22908] ZipExtFile in zipfile can be seekable
In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za>
Message-ID: <1517302302.63.0.467229070634.issue22908@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 066df4fd454d6ff9be66e80b2a65995b10af174f by Gregory P. Smith (John Jolly) in branch 'master':
bpo-22908: Add seek and tell functionality to ZipExtFile (GH-4966)
https://github.com/python/cpython/commit/066df4fd454d6ff9be66e80b2a65995b10af174f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22908>
_______________________________________

From report at bugs.python.org  Tue Jan 30 03:53:26 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 08:53:26 +0000
Subject: [issue22908] ZipExtFile in zipfile can be seekable
In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za>
Message-ID: <1517302406.95.0.467229070634.issue22908@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22908>
_______________________________________

From report at bugs.python.org  Tue Jan 30 03:55:22 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Jan 2018 08:55:22 +0000
Subject: [issue32387] Disallow untagged C extension import on major platforms
In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za>
Message-ID: <1517302522.04.0.467229070634.issue32387@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

did this get discussed on distutils-sig?  It's a trivial change (for the POSIX only PR) and would be neat to go through one of the 3.7 beta cycles to see if anything serious an unexpected is likely to come up for anyone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32387>
_______________________________________

From report at bugs.python.org  Tue Jan 30 03:56:40 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 30 Jan 2018 08:56:40 +0000
Subject: [issue32387] Disallow untagged C extension import on major platforms
In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za>
Message-ID: <1517302600.18.0.467229070634.issue32387@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

+1

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32387>
_______________________________________

From report at bugs.python.org  Tue Jan 30 04:34:39 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 30 Jan 2018 09:34:39 +0000
Subject: [issue32724] Fix references to commands in Doc/pdb.rst
In-Reply-To: <1517299173.52.0.467229070634.issue32724@psf.upfronthosting.co.za>
Message-ID: <1517304879.73.0.467229070634.issue32724@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 67adb31a416864f853772c3e74a06caeadc9b6f1 by Andrew Svetlov (St?phane Wirtel) in branch 'master':
bpo-32724: Fix references to commands in Doc/pdb.rst (GH-5444)
https://github.com/python/cpython/commit/67adb31a416864f853772c3e74a06caeadc9b6f1


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32724>
_______________________________________

From report at bugs.python.org  Tue Jan 30 04:34:58 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 30 Jan 2018 09:34:58 +0000
Subject: [issue32724] Fix references to commands in Doc/pdb.rst
In-Reply-To: <1517299173.52.0.467229070634.issue32724@psf.upfronthosting.co.za>
Message-ID: <1517304898.93.0.467229070634.issue32724@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32724>
_______________________________________

From report at bugs.python.org  Tue Jan 30 04:35:53 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 09:35:53 +0000
Subject: [issue32724] Fix references to commands in Doc/pdb.rst
In-Reply-To: <1517299173.52.0.467229070634.issue32724@psf.upfronthosting.co.za>
Message-ID: <1517304953.8.0.467229070634.issue32724@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32724>
_______________________________________

From report at bugs.python.org  Tue Jan 30 04:39:50 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 09:39:50 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1517305190.54.0.467229070634.issue32476@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

as explained on the PR, maybe you could add in the documentation.

..versionadded:: 3.7
    Support of the XPath concat function

but maybe your PR is too late because 3.7 starts to be in the frozen period for the features.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Tue Jan 30 04:52:41 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 09:52:41 +0000
Subject: [issue28440] ensurepip and pip install failures on macOS Sierra with
 non-system Python 2.7.x
In-Reply-To: <1476450540.6.0.486887198503.issue28440@psf.upfronthosting.co.za>
Message-ID: <1517305961.08.0.467229070634.issue28440@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +5277

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28440>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:13:55 2018
From: report at bugs.python.org (Clement Rouault)
Date: Tue, 30 Jan 2018 10:13:55 +0000
Subject: [issue32725] Instance of _multiprocessing.PipeConnection-subtype
 crash on deletion
Message-ID: <1517307235.22.0.467229070634.issue32725@psf.upfronthosting.co.za>


New submission from Clement Rouault <python at hakril.net>:

While playing with '_multiprocessing.PipeConnection' I found out that instancing an object with a subtype of '_multiprocessing.PipeConnection' will crash the interpreter when the object is deleted.

My guess is that some connection methods does not check/handle the fact that the object is a subtype and not a 'pure' PipeConnection.

I don't know if the exploitability aspect of this crash is important but it allows to rewrite an arbitrary address easily with some heap-pointer (leading to CPython trying to execute the heap).

I attached a simple program that crash CPython using this bug.

----------
components: Library (Lib)
files: poc.py
messages: 311260
nosy: hakril
priority: normal
severity: normal
status: open
title: Instance of _multiprocessing.PipeConnection-subtype crash on deletion
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47417/poc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32725>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:14:14 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 10:14:14 +0000
Subject: [issue28440] ensurepip and pip install failures on macOS Sierra with
 non-system Python 2.7.x
In-Reply-To: <1476450540.6.0.486887198503.issue28440@psf.upfronthosting.co.za>
Message-ID: <1517307254.64.0.467229070634.issue28440@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 763f094b1f0ce2a07768828e78afe9687e9ad3bb by Ned Deily in branch 'master':
bpo-28440: Don't add /Library/Python/3.x/site-packages to sys.path (#5445)
https://github.com/python/cpython/commit/763f094b1f0ce2a07768828e78afe9687e9ad3bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28440>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:29:51 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 10:29:51 +0000
Subject: [issue32722] Classes
In-Reply-To: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>
Message-ID: <1517308191.53.0.467229070634.issue32722@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +5278
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:29:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Jan 2018 10:29:55 +0000
Subject: [issue30117] test_lib2to3.test_parser.test_all_project_files() fails
In-Reply-To: <1492692321.21.0.476906243501.issue30117@psf.upfronthosting.co.za>
Message-ID: <1517308195.8.0.467229070634.issue30117@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Failure on AMD64 Windows8.1 Non-Debug 3.x:

http://buildbot.python.org/all/#/builders/12/builds/585

======================================================================
ERROR: test_all_project_files (lib2to3.tests.test_parser.TestParserIdempotency)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release\build\lib\lib2to3\tests\test_parser.py", line 432, in test_all_project_files
    x = diff(filepath, new, encoding=encoding)
  File "D:\buildarea\3.x.ware-win81-release\build\lib\lib2to3\tests\test_parser.py", line 488, in diff
    return subprocess.call(['diff', '-u', fn, '@'], stdout=(subprocess.DEVNULL if verbose < 1 else None))
  File "D:\buildarea\3.x.ware-win81-release\build\lib\subprocess.py", line 304, in call
    with Popen(*popenargs, **kwargs) as p:
  File "D:\buildarea\3.x.ware-win81-release\build\lib\subprocess.py", line 756, in __init__
    restore_signals, start_new_session)
  File "D:\buildarea\3.x.ware-win81-release\build\lib\subprocess.py", line 1160, in _execute_child
    startupinfo)
FileNotFoundError: [WinError 2] The system cannot find the file specified

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30117>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:32:34 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 10:32:34 +0000
Subject: [issue32723] codecs.open silently ignores argument errors
In-Reply-To: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>
Message-ID: <1517308354.3.0.467229070634.issue32723@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I don't understand Josh. Looking from the code only when *passing* encoding binary mode is forced, although in the comment it's saying always.

>>> f = codecs.open('/tmp/a', 'w')
>>> f
<open file '/tmp/a', mode 'w' at 0x7f516efbb6f0>

For example I want to use 'replace' instead of 'strict' for default encoding, I can't simply do:

>>> import codecs
>>> f = codecs.open('/tmp/a', 'w', errors='replace')
>>> f.write(u'\udc80')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\udc80' in position 0: ordinal not in range(128)

I have to specify the default encoding explicitly to make errors function:

>>> f = codecs.open('/tmp/a', 'w', encoding='ascii', errors='replace')
>>> f.write(u'\udc80')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:33:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Jan 2018 10:33:25 +0000
Subject: [issue30117] test_lib2to3.test_parser.test_all_project_files() fails
In-Reply-To: <1492692321.21.0.476906243501.issue30117@psf.upfronthosting.co.za>
Message-ID: <1517308405.32.0.467229070634.issue30117@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Different failure on AMD64 Windows10 3.x:

======================================================================
FAIL: test_all_project_files (lib2to3.tests.test_parser.TestParserIdempotency)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\lib2to3\tests\test_parser.py", line 434, in test_all_project_files
    self.fail("Idempotency failed: %s" % filepath)
AssertionError: Idempotency failed: D:\buildarea\3.x.bolen-windows10\build\lib\lib2to3\btm_matcher.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30117>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:37:22 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 10:37:22 +0000
Subject: [issue32722] Classes
In-Reply-To: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>
Message-ID: <1517308642.15.0.467229070634.issue32722@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

This example is also in 2.7 
https://docs.python.org/2.7/tutorial/classes.html#generator-expressions

-> I add 2.7

----------
nosy: +matrixise
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:43:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Jan 2018 10:43:10 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1517308990.15.0.467229070634.issue28914@psf.upfronthosting.co.za>


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


----------
pull_requests: +5279
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:59:05 2018
From: report at bugs.python.org (Torsten Bronger)
Date: Tue, 30 Jan 2018 10:59:05 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1517309945.43.0.467229070634.issue24132@psf.upfronthosting.co.za>


Change by Torsten Bronger <bronger at physik.rwth-aachen.de>:


----------
nosy: +bronger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Tue Jan 30 06:04:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Jan 2018 11:04:23 +0000
Subject: [issue30117] test_lib2to3.test_parser.test_all_project_files() fails
In-Reply-To: <1492692321.21.0.476906243501.issue30117@psf.upfronthosting.co.za>
Message-ID: <1517310263.73.0.467229070634.issue30117@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

x86 Windows7 3.x:

http://buildbot.python.org/all/#/builders/58/builds/563

======================================================================
FAIL: test_nonexisting_with_pipes (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_subprocess.py", line 1194, in test_nonexisting_with_pipes
    self.assertEqual(stderr, "")
AssertionError: 'Traceback (most recent call last):\n  Fil[1129 chars]le\n' != ''
Diff is 1153 characters long. Set self.maxDiff to None to see it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30117>
_______________________________________

From report at bugs.python.org  Tue Jan 30 06:18:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Jan 2018 11:18:56 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1517311136.22.0.467229070634.issue28914@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset b8d90328ad2abc9d6d2c9b8ce769fb82b18bbc10 by Victor Stinner in branch 'master':
bpo-28914: Fix compilation of select on Android (#5447)
https://github.com/python/cpython/commit/b8d90328ad2abc9d6d2c9b8ce769fb82b18bbc10


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Tue Jan 30 06:58:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 11:58:51 +0000
Subject: [issue32726] 3.7.0 macOS installer and framework enhancements and
 changes
Message-ID: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at python.org>:

This issue covers various changes for the macOS installers provided via python.org for 3.7.0.

----------
components: Build, macOS
messages: 311268
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: 3.7.0 macOS installer and framework enhancements and changes
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Tue Jan 30 07:19:31 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 12:19:31 +0000
Subject: [issue32726] 3.7.0 macOS installer and framework enhancements and
 changes
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1517314771.94.0.467229070634.issue32726@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch
pull_requests: +5280
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Tue Jan 30 07:22:01 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 12:22:01 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1517314921.15.0.467229070634.issue32726@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
title: 3.7.0 macOS installer and framework enhancements and changes -> macOS installer and framework enhancements and changes for 3.7.0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Tue Jan 30 07:22:46 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 12:22:46 +0000
Subject: [issue32725] Instance of _multiprocessing.PipeConnection-subtype
 crash on deletion
In-Reply-To: <1517307235.22.0.467229070634.issue32725@psf.upfronthosting.co.za>
Message-ID: <1517314966.12.0.467229070634.issue32725@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

The test is executed under Windows.

----------
components: +Windows
nosy: +matrixise, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32725>
_______________________________________

From report at bugs.python.org  Tue Jan 30 07:42:19 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 12:42:19 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1517316139.1.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 8c9bb72e8b6474ae722f7d6521cfb3cb2e26e3c5 by Ned Deily in branch 'master':
bpo-32726: macOS installer and framework enhancements and changes for 3.7.0 (GH-5448)
https://github.com/python/cpython/commit/8c9bb72e8b6474ae722f7d6521cfb3cb2e26e3c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Tue Jan 30 08:06:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Jan 2018 13:06:04 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1517317564.81.0.467229070634.issue28914@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I merged a PR based on selectmodule.patch. Thanks Wataru Matsumoto for your contribution!

Python 3.6 doesn't seem to be affected by the issue. I close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Tue Jan 30 08:13:31 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 13:13:31 +0000
Subject: [issue32515] Add an option to trace to run module as a script
In-Reply-To: <1515358727.93.0.467229070634.issue32515@psf.upfronthosting.co.za>
Message-ID: <1517318011.3.0.467229070634.issue32515@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32515>
_______________________________________

From report at bugs.python.org  Tue Jan 30 08:52:58 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jan 2018 13:52:58 +0000
Subject: [issue27321] Email parser creates a message object that can't be
 flattened
In-Reply-To: <1465930372.53.0.0254623453508.issue27321@psf.upfronthosting.co.za>
Message-ID: <1517320378.57.0.467229070634.issue27321@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Requested a small additional change to the new tests, and then this will be ready to go in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27321>
_______________________________________

From report at bugs.python.org  Tue Jan 30 09:29:48 2018
From: report at bugs.python.org (John Jolly)
Date: Tue, 30 Jan 2018 14:29:48 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1517322588.47.0.467229070634.issue32476@psf.upfronthosting.co.za>


John Jolly <jjolly at suse.com> added the comment:

I understand that the feature is likely too late, but I do not want it to get lost. Is there any way to make certain this feature is accepted for the next release? Do I just select the 3.8 version for this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Tue Jan 30 09:34:47 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 30 Jan 2018 14:34:47 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1517322887.41.0.467229070634.issue32146@psf.upfronthosting.co.za>


bbayles <bbayles at gmail.com> added the comment:

I presume it's too late to get my pull request in for 3.7, but perhaps we could get a note in the documentation for this before release?

That could be as simple as: 

    .. warning::
    
    The ``'spawn'`` and ``'forkserver'`` start methods cannot currently be used with "frozen" executables (i.e., binaries produced by packages like **PyInstaller** and **cx_Freeze**) on Unix. The ``'fork'`` start method does work.

I will make that into a PR if it seems like a good option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:04:42 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 30 Jan 2018 15:04:42 +0000
Subject: [issue32221] Converting ipv6 address to string representation using
 getnameinfo() is wrong.
In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za>
Message-ID: <1517324682.59.0.467229070634.issue32221@psf.upfronthosting.co.za>


Change by ???? ????????? <socketpair at gmail.com>:


----------
pull_requests: +5281

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32221>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:10:33 2018
From: report at bugs.python.org (=?utf-8?q?Micha=C3=ABl_Lemaire?=)
Date: Tue, 30 Jan 2018 15:10:33 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
Message-ID: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>


New submission from Micha?l Lemaire <m.lemaire at rodacom.fr>:

Hi,

I noticed that SMTP.send_message, when getting the sender and recipients from the Message object, strips the name from recipients (to keep only the address), but not from the sender.

        if from_addr is None:
            # Prefer the sender field per RFC 2822:3.6.2.
            from_addr = (msg[header_prefix + 'Sender']
                           if (header_prefix + 'Sender') in msg
                           else msg[header_prefix + 'From'])
        if to_addrs is None:
            addr_fields = [f for f in (msg[header_prefix + 'To'],
                                       msg[header_prefix + 'Bcc'],
                                       msg[header_prefix + 'Cc'])
                           if f is not None]
            to_addrs = [a[1] for a in email.utils.getaddresses(addr_fields)]

There is an ugly side-effect to that (starting with Python 3.5) : if the sender name contains a non-ascii character, send_message will then require the SMTPUTF8 option from the SMTP server, and raise a SMTPNotSupportedError if unavailable. This is not wanted because the sender name is not actually sent to the SMTP server in the "MAIL FROM:" command (it is only sent in the MIME payload), so the SMTPUTF8 option should not be required based on it (it should only depend on the addresses).

----------
components: Library (Lib)
messages: 311275
nosy: Micha?l Lemaire
priority: normal
severity: normal
status: open
title: smtplib's SMTP.send_message behaves differently with from_addr and to_addrs
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:16:26 2018
From: report at bugs.python.org (Stuart Berg)
Date: Tue, 30 Jan 2018 15:16:26 +0000
Subject: [issue25942] Do not immediately SIGKILL subprocess child processes
 upon ^C
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1517325386.85.0.467229070634.issue25942@psf.upfronthosting.co.za>


Change by Stuart Berg <bergs at janelia.hhmi.org>:


----------
nosy: +stuarteberg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:31:25 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 15:31:25 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517326285.05.0.467229070634.issue32727@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Do you have an example with a test?

Thank you

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:44:17 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 15:44:17 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1517327057.89.0.467229070634.issue32476@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I think (but not sure) that your feature will be included in 3.8 because 3.7 has been frozen today :/

@ned do you think you could integrate this functionality in 3.7 or 3.8 ?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:44:22 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 15:44:22 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1517327062.0.0.467229070634.issue32476@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:44:28 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 15:44:28 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1517327068.92.0.467229070634.issue32476@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:46:45 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jan 2018 15:46:45 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517327205.25.0.467229070634.issue32727@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, that looks like a bug.  Should be a one line bug fix, plus tests and news item if someone wants to make a PR...

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:47:51 2018
From: report at bugs.python.org (=?utf-8?q?Micha=C3=ABl_Lemaire?=)
Date: Tue, 30 Jan 2018 15:47:51 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517327271.71.0.467229070634.issue32727@psf.upfronthosting.co.za>


Micha?l Lemaire <m.lemaire at rodacom.fr> added the comment:

Sure :

#coding: utf-8
import email.utils
from email.message import EmailMessage
from smtplib import SMTP
m = EmailMessage()
m['From'] = email.utils.formataddr(("Micha?l", "michael at example.com"))
m['To'] = email.utils.formataddr(("Ren?", "bounce at rodacom.fr"))
with SMTP('localhost') as smtp:
    smtp.set_debuglevel(2)
    smtp.send_message(m)
#END

On a server without SMTPUTF8, this outputs:

---
16:39:26.351302 send: 'ehlo localhost\r\n'
16:39:26.351391 reply: b'250-localhost\r\n'
16:39:26.351414 reply: b'250-PIPELINING\r\n'
16:39:26.351427 reply: b'250-SIZE 10240000\r\n'
16:39:26.351437 reply: b'250-VRFY\r\n'
16:39:26.351448 reply: b'250-ETRN\r\n'
16:39:26.351458 reply: b'250-ENHANCEDSTATUSCODES\r\n'
16:39:26.351468 reply: b'250-8BITMIME\r\n'
16:39:26.351477 reply: b'250 DSN\r\n'
16:39:26.351490 reply: retcode (250); Msg: b'localhost\nPIPELINING\nSIZE 10240000\nVRFY\nETRN\nENHANCEDSTATUSCODES\n8BITMIME\nDSN'
16:39:26.351832 send: 'QUIT\r\n'
16:39:26.351901 reply: b'221 2.0.0 Bye\r\n'
16:39:26.351923 reply: retcode (221); Msg: b'2.0.0 Bye'
Traceback (most recent call last):
  File "/usr/lib/python3.5/smtplib.py", line 943, in send_message
    ''.join([from_addr, *to_addrs]).encode('ascii')
UnicodeEncodeError: 'ascii' codec can't encode character '\xeb' in position 5: ordinal not in range(128)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "testsmtp.py", line 12, in <module>
    smtp.send_message(m)
  File "/usr/lib/python3.5/smtplib.py", line 947, in send_message
    "One or more source or delivery addresses require"
smtplib.SMTPNotSupportedError: One or more source or delivery addresses require internationalized email support, but the server does not advertise the required SMTPUTF8 capability
---


With removing the accented character in the sender name :
m['From'] = email.utils.formataddr(("Michael", "michael at example.com"))

It works :

---
16:42:49.882358 send: 'ehlo localhost\r\n'
16:42:49.882437 reply: b'250-localhost\r\n'
16:42:49.882460 reply: b'250-PIPELINING\r\n'
16:42:49.882474 reply: b'250-SIZE 10240000\r\n'
16:42:49.882486 reply: b'250-VRFY\r\n'
16:42:49.882498 reply: b'250-ETRN\r\n'
16:42:49.882509 reply: b'250-ENHANCEDSTATUSCODES\r\n'
16:42:49.882520 reply: b'250-8BITMIME\r\n'
16:42:49.882530 reply: b'250 DSN\r\n'
16:42:49.882543 reply: retcode (250); Msg: b'localhost\nPIPELINING\nSIZE 10240000\nVRFY\nETRN\nENHANCEDSTATUSCODES\n8BITMIME\nDSN'
16:42:49.883439 send: 'mail FROM:<michael at example.com> size=86\r\n'
16:42:49.886567 reply: b'250 2.1.0 Ok\r\n'
16:42:49.886603 reply: retcode (250); Msg: b'2.1.0 Ok'
16:42:49.886666 send: 'rcpt TO:<bounce at rodacom.fr>\r\n'
16:42:49.889642 reply: b'250 2.1.5 Ok\r\n'
16:42:49.889676 reply: retcode (250); Msg: b'2.1.5 Ok'
16:42:49.889694 send: 'data\r\n'
16:42:49.889769 reply: b'354 End data with <CR><LF>.<CR><LF>\r\n'
16:42:49.889827 reply: retcode (354); Msg: b'End data with <CR><LF>.<CR><LF>'
16:42:49.889843 data: (354, b'End data with <CR><LF>.<CR><LF>')
16:42:49.889939 send: b'From: Michael <michael at example.com>\r\nTo: =?utf-8?q?Ren=C3=A9?= <bounce at rodacom.fr>\r\n\r\n.\r\n'
16:42:49.892726 reply: b'250 2.0.0 Ok: queued as D92C540105\r\n'
16:42:49.892752 reply: retcode (250); Msg: b'2.0.0 Ok: queued as D92C540105'
16:42:49.892764 data: (250, b'2.0.0 Ok: queued as D92C540105')
16:42:49.892786 send: 'QUIT\r\n'
16:42:49.892862 reply: b'221 2.0.0 Bye\r\n'
16:42:49.892896 reply: retcode (221); Msg: b'2.0.0 Bye'
---

As you can see, the sender and recipients names are not sent in SMTP command, except in the MIME body, so they should not be used to determine whether SMTPUTF8 is required or not.

----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:24:11 2018
From: report at bugs.python.org (=?utf-8?q?Micha=C3=ABl_Lemaire?=)
Date: Tue, 30 Jan 2018 16:24:11 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517329451.25.0.467229070634.issue32727@psf.upfronthosting.co.za>


Micha?l Lemaire <m.lemaire at rodacom.fr> added the comment:

Oups @r.david.murray, just saw I posted over your message, and removed you from the nozy list, sorry.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:33:55 2018
From: report at bugs.python.org (John Jolly)
Date: Tue, 30 Jan 2018 16:33:55 +0000
Subject: [issue28494] is_zipfile false positives
In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za>
Message-ID: <1517330035.42.0.467229070634.issue28494@psf.upfronthosting.co.za>


John Jolly <jjolly at suse.com> added the comment:

Is there any chance that this will make it into 3.7 or is my reminder too late?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28494>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:35:26 2018
From: report at bugs.python.org (John Jolly)
Date: Tue, 30 Jan 2018 16:35:26 +0000
Subject: [issue28494] is_zipfile false positives
In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za>
Message-ID: <1517330126.42.0.467229070634.issue28494@psf.upfronthosting.co.za>


Change by John Jolly <jjolly at suse.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28494>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:40:53 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 16:40:53 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517330453.79.0.467229070634.issue32727@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@r.david.murray I started to work on a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:47:20 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 30 Jan 2018 16:47:20 +0000
Subject: [issue32728] Extend zipfile's compression level support  to LZMA
Message-ID: <1517330840.6.0.467229070634.issue32728@psf.upfronthosting.co.za>


New submission from bbayles <bbayles at gmail.com>:

In [1] (issue 21417), support for setting an archive (or its files) compression level was added to the zipfile module.

That currently works for the ZIP_DEFLATED and ZIP_BZIP2 compression methods, but not for ZIP_LZMA. This is because zipfile includes its own implementation of LZMACompressor that hard-codes the default preset's parameters (see also [2]).

It should be possible to extend compression level settings to ZIP_LZMA by making zipfile.LZMACompressor more flexible, i.e. able to accept an LZMA preset. I think this would involve porting the function that translates presets to options (lzma_lzma_preset, see [3]) and passing in those options to lzma.LZMACompressor .

[1] https://bugs.python.org/issue21417
[2] https://github.com/python/cpython/pull/5385
[3] https://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/lzma/lzma_encoder_presets.c;hb=HEAD

----------
components: Library (Lib)
messages: 311283
nosy: bbayles
priority: normal
severity: normal
status: open
title: Extend zipfile's compression level support  to LZMA
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32728>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:50:27 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 16:50:27 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517331027.45.0.467229070634.issue32727@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@r.david.murray I am interested with your opinion about a test for this PR, if you have an idea, because all the tests pass on my laptop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:48:59 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 16:48:59 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517330939.28.0.467229070634.issue32727@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +5282
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 12:19:37 2018
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bajusz?=)
Date: Tue, 30 Jan 2018 17:19:37 +0000
Subject: [issue29882] Add an efficient popcount method for integers
In-Reply-To: <1490203842.58.0.276315183014.issue29882@psf.upfronthosting.co.za>
Message-ID: <1517332777.04.0.467229070634.issue29882@psf.upfronthosting.co.za>


Change by Tam?s Bajusz <gbtami at gmail.com>:


----------
nosy: +gbtami

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29882>
_______________________________________

From report at bugs.python.org  Tue Jan 30 12:20:51 2018
From: report at bugs.python.org (=?utf-8?q?Tam=C3=A1s_Bajusz?=)
Date: Tue, 30 Jan 2018 17:20:51 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1517332851.16.0.467229070634.issue19915@psf.upfronthosting.co.za>


Change by Tam?s Bajusz <gbtami at gmail.com>:


----------
nosy: +gbtami

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Tue Jan 30 12:22:20 2018
From: report at bugs.python.org (Minion Jim)
Date: Tue, 30 Jan 2018 17:22:20 +0000
Subject: [issue32611] Tkinter taskbar icon (Windows)
In-Reply-To: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>
Message-ID: <1517332940.04.0.467229070634.issue32611@psf.upfronthosting.co.za>


Minion Jim <epaine13 at ranelagh.bracknell-forest.sch.uk> added the comment:

Sorry for posting this as a bug :-( When I reupdated (again) it sorted itself out (for whatever reason). So once again sorry for wasting your time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Tue Jan 30 12:39:37 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jan 2018 17:39:37 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517333977.44.0.467229070634.issue32727@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, you'll have to write a test.  Add a test after test_send_unicode_without_SMTPUTF8, but put the unicode in the name field of the 'from' address and test that it is accepted.  You should be able to figure out how to check for success from the other tests in that class (I hope ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 13:22:28 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 18:22:28 +0000
Subject: [issue30117] test_lib2to3.test_parser.test_all_project_files() fails
In-Reply-To: <1492692321.21.0.476906243501.issue30117@psf.upfronthosting.co.za>
Message-ID: <1517336548.06.0.467229070634.issue30117@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

1e17d4aaff5c7ca972bab437949d2bb51c5b30f7. I don't think you can pin test_subprocess on this change, though.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30117>
_______________________________________

From report at bugs.python.org  Tue Jan 30 13:23:21 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 18:23:21 +0000
Subject: [issue30117] test_lib2to3.test_parser.test_all_project_files() fails
In-Reply-To: <1492692321.21.0.476906243501.issue30117@psf.upfronthosting.co.za>
Message-ID: <1517336601.02.0.467229070634.issue30117@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a23a2c555c4187f349276fe2f2ceffa953d0afe9 by Benjamin Peterson in branch '3.6':
[3.6] closes bpo-30117: fix lib2to3 ParserIdempotency test (GH-1242) (GH-5443)
https://github.com/python/cpython/commit/a23a2c555c4187f349276fe2f2ceffa953d0afe9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30117>
_______________________________________

From report at bugs.python.org  Tue Jan 30 13:36:27 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 30 Jan 2018 18:36:27 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1517337387.25.0.467229070634.issue27428@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Since WindowsRegistryFinder was deprecated in 3.6, should this be closed or should the documentation still be corrected?

----------
nosy: +csabella
versions: +Python 3.7 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Tue Jan 30 14:24:35 2018
From: report at bugs.python.org (Nitish)
Date: Tue, 30 Jan 2018 19:24:35 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1517340275.01.0.467229070634.issue19915@psf.upfronthosting.co.za>


Change by Nitish <nitishch at protonmail.com>:


----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Tue Jan 30 14:25:41 2018
From: report at bugs.python.org (William Pickard)
Date: Tue, 30 Jan 2018 19:25:41 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1517340341.07.0.467229070634.issue25095@psf.upfronthosting.co.za>


Change by William Pickard <lollol222gg at gmail.com>:


----------
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Tue Jan 30 14:31:36 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 30 Jan 2018 19:31:36 +0000
Subject: [issue32045] Does json.dumps have a memory leak?
In-Reply-To: <1510820419.37.0.213398074469.issue32045@psf.upfronthosting.co.za>
Message-ID: <1517340696.26.0.467229070634.issue32045@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Can this be closed as 'Not a Bug'?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32045>
_______________________________________

From report at bugs.python.org  Tue Jan 30 14:32:24 2018
From: report at bugs.python.org (Rohan D'Sa)
Date: Tue, 30 Jan 2018 19:32:24 +0000
Subject: [issue32045] Does json.dumps have a memory leak?
In-Reply-To: <1517340696.26.0.467229070634.issue32045@psf.upfronthosting.co.za>
Message-ID: <CAC=4VUx1xSP3D_CfiioyBzJdD4kLTnH1QP6eiVMxX57ZXHrvew@mail.gmail.com>


Rohan D'Sa <roh4n.ds4 at gmail.com> added the comment:

Yes. Thanks.

On 30 Jan 2018 8:31 PM, "Cheryl Sabella" <report at bugs.python.org> wrote:

>
> Cheryl Sabella <chekat2 at gmail.com> added the comment:
>
> Can this be closed as 'Not a Bug'?
>
> ----------
> nosy: +csabella
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32045>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32045>
_______________________________________

From report at bugs.python.org  Tue Jan 30 14:32:56 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Jan 2018 19:32:56 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1517340776.48.0.467229070634.issue27428@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Docs should still be correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Tue Jan 30 14:37:33 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Jan 2018 19:37:33 +0000
Subject: [issue32690] Return function locals() in order of creation?
In-Reply-To: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>
Message-ID: <1517341053.78.0.467229070634.issue32690@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank Nick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Tue Jan 30 14:43:08 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 30 Jan 2018 19:43:08 +0000
Subject: [issue19495] context manager for measuring duration of blocks of code
In-Reply-To: <1383588451.25.0.545990193953.issue19495@psf.upfronthosting.co.za>
Message-ID: <1517341388.7.0.467229070634.issue19495@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hello everyone,

I was interested in similar functionality for timeit and found this discussion.  I know it's too late for 3.7, but I was wondering if it would be worth putting this on python-ideas or python-dev to try to get some consensus for a PEP or a patch?  With Barry's addition of breakpoint(), I would find something similar for timeit (that is, a simpler way to invoke it) would be quite helpful.

Thanks!

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19495>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:06:51 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jan 2018 20:06:51 +0000
Subject: [issue19495] context manager for measuring duration of blocks of code
In-Reply-To: <1383588451.25.0.545990193953.issue19495@psf.upfronthosting.co.za>
Message-ID: <1517342811.79.0.467229070634.issue19495@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FWIW, we just ran in to the need for this on our project, and used 'Time' from the contexttimer package on pypi.  In our use case we want the number so we can log it, and what we care about is the actual elapsed time, not a precise measurement of the code block, because it for system monitoring and metrics, not hardcore performance analysis.  

Having this always print would indeed be sub-optimal :)

----------
nosy: +r.david.murray
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19495>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:07:24 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 20:07:24 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517342844.92.0.467229070634.issue32727@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@r.david.murray I just updated the PR with a test, but I am not sure about it, could you give me your opinion because the current test suite works fine without my new test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:12:05 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jan 2018 20:12:05 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517343125.56.0.467229070634.issue32727@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The current test suite had better work fine without your new test, otherwise your fix broke something :)  I will take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:18:51 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 20:18:51 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517343531.68.0.467229070634.issue32727@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

yep, you can take a look but all the tests are green on Travis, maybe you will understand why I don't see the interest of my new test. you are the master for the email part ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:27:46 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Jan 2018 20:27:46 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1517344066.47.0.467229070634.issue29708@psf.upfronthosting.co.za>


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


----------
assignee: brett.cannon -> 
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:28:48 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Jan 2018 20:28:48 +0000
Subject: [issue32722] Mislabeling of a dict comprehension as a generator
 expression in the tutorial
In-Reply-To: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>
Message-ID: <1517344128.97.0.467229070634.issue32722@psf.upfronthosting.co.za>


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


----------
title: Classes -> Mislabeling of a dict comprehension as a generator expression in the tutorial

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:30:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 30 Jan 2018 20:30:49 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1517344249.96.0.467229070634.issue32604@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

A couple defects reported by coverity:



** CID 1428758: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /Modules/_xxsubinterpretersmodule.c: 45 in _coerce_id()
________________________________________________________________________________________________________ *** CID 1428758: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /Modules/_xxsubinterpretersmodule.c: 45 in _coerce_id()
39 }
40 if (cid < 0) {
41 PyErr_SetString(PyExc_ValueError, 42 "'id' must be a non-negative int"); 43 return -1;
44 }
45 if (cid > INT64_MAX) {
46 PyErr_SetString(PyExc_ValueError, 47 "'id' too large (must be 64-bit int)"); 48 return -1;
49 }
50 return cid;
** CID 1428757: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /Modules/_xxsubinterpretersmodule.c: 1215 in channelid_richcompare()
________________________________________________________________________________________________________ *** CID 1428757: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /Modules/_xxsubinterpretersmodule.c: 1215 in channelid_richcompare()
1209 }
1210 int64_t othercid = PyLong_AsLongLong(other); 1211 // XXX decref other here?
1212 if (othercid == -1 && PyErr_Occurred() != NULL) { 1213 return NULL;
1214 }
1215 if (othercid < 0 || othercid > INT64_MAX) { 1216 equal = 0;
 
1217 }
1218 else {
1219 equal = (cid->id == othercid); 1220 }
** CID 1428756: Error handling issues (CHECKED_RETURN) /Modules/gcmodule.c: 1071 in gc_enable_impl()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:32:54 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 30 Jan 2018 20:32:54 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517344373.99.0.467229070634.issue31356@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

A bug found by coverity:

(PyErr_WarnEx might error out; please update the code to handle that)


________________________________________________________________________________________________________ *** CID 1428756: Error handling issues (CHECKED_RETURN)
/Modules/gcmodule.c: 1071 in gc_enable_impl()
1065
1066 static PyObject *
1067 gc_enable_impl(PyObject *module)
1068 /*[clinic end generated code: output=45a427e9dce9155c input=81ac4940ca579707]*/
1069 {
1070 if(_PyRuntime.gc.disabled_threads){
1071 PyErr_WarnEx(PyExc_RuntimeWarning, "Garbage collector enabled while another "
1072 "thread is inside gc.ensure_enabled",1);
1073 }
1074 _PyRuntime.gc.enabled = 1;
1075 Py_RETURN_NONE;
1076 }

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:33:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 30 Jan 2018 20:33:02 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517344382.88.0.467229070634.issue31356@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Tue Jan 30 15:39:21 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jan 2018 20:39:21 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517344761.45.0.467229070634.issue32727@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We need a test that will fail without your fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 16:31:11 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 21:31:11 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517344761.45.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <20180130213102.GA11790@xps>


St?phane Wirtel <stephane at wirtel.be> added the comment:

The new test crashes without my fix but once we use the fix, all the
tests pass. I have modified the SimSMTPServer.process_manage method

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 17:39:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 22:39:38 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1517351978.52.0.467229070634.issue30697@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I don't know what the right answer here is.  But since there don't seem to be strong opinions one way or the other with regard to 3.7, I am not going to hold 3.7.0b1 for a resolution.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Tue Jan 30 18:00:31 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 30 Jan 2018 23:00:31 +0000
Subject: [issue32045] Does json.dumps have a memory leak?
In-Reply-To: <1510820419.37.0.213398074469.issue32045@psf.upfronthosting.co.za>
Message-ID: <1517353231.96.0.467229070634.issue32045@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32045>
_______________________________________

From report at bugs.python.org  Tue Jan 30 18:18:14 2018
From: report at bugs.python.org (Soothsayer)
Date: Tue, 30 Jan 2018 23:18:14 +0000
Subject: [issue32722] Mislabeling of a dict comprehension as a generator
 expression in the tutorial
In-Reply-To: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>
Message-ID: <1517354294.1.0.467229070634.issue32722@psf.upfronthosting.co.za>


Soothsayer <qd57h9m4q2 at snkmail.com> added the comment:

I agree that 2.7 is incorrect also, 2.7 has dict comprehensions also so there's no reason to pass a generator expression to dict().

I add 3.4 and 3.8 because they also have the problem.

----------
versions: +Python 3.4, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 18:39:49 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Jan 2018 23:39:49 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517355589.38.0.467229070634.issue31356@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> (PyErr_WarnEx might error out; please update the code to handle that)

Lisa, would you like to take a crack at fixing this one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Tue Jan 30 19:02:53 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Jan 2018 00:02:53 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517356973.42.0.467229070634.issue32727@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:


New changeset 8d83e4ba7823827bcbc119db887004d5c3a63dc6 by R. David Murray (St?phane Wirtel) in branch 'master':
bpo-32727: smtplib's SMTP.send_message behaves differently with from_addr and to_addrs (#5451)
https://github.com/python/cpython/commit/8d83e4ba7823827bcbc119db887004d5c3a63dc6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 19:03:04 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Jan 2018 00:03:04 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517356984.69.0.467229070634.issue32727@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 19:12:39 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 31 Jan 2018 00:12:39 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1517357559.84.0.467229070634.issue27987@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Jan 30 19:13:00 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 31 Jan 2018 00:13:00 +0000
Subject: [issue31912] PyMem_Malloc() should guarantee alignof(max_align_t)
In-Reply-To: <1509472895.95.0.213398074469.issue31912@psf.upfronthosting.co.za>
Message-ID: <1517357580.41.0.467229070634.issue31912@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31912>
_______________________________________

From report at bugs.python.org  Tue Jan 30 19:41:20 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 31 Jan 2018 00:41:20 +0000
Subject: [issue32723] codecs.open silently ignores argument errors
In-Reply-To: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>
Message-ID: <1517359280.05.0.467229070634.issue32723@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Ah, my mistake. That said, when you're not passing an encoding, you're still just calling regular open, it's not doing any special codecs.open wrapping (on Python 2, this meant you weren't decoding the input at all, on Python 3 it means you're decoding with the default encoding); you may as well just call open (codecs.open is pointless as soon as io.open exists, since codecs.open it's slower and has so many weird quirks).

While I acknowledge codecs.open is misbehaving here, I'm not sure fixing it is a great idea, since the function is effectively a legacy function (especially when used without an encoding argument), and io.open works correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 20:06:31 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 31 Jan 2018 01:06:31 +0000
Subject: [issue32723] codecs.open silently ignores argument errors
In-Reply-To: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>
Message-ID: <1517360791.53.0.467229070634.issue32723@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

On rereading the docs for Python 3 codecs.open, it doesn't seem to document the whole "no encoding means no codecs.StreamReaderWriter wrapping behavior" at all.

First off, any fix would only apply to Python 3 (I've removed 2.7 from the versions). Both Python 2 and Python 3 have the behavior of calling the plain builtin open function with just filename, mode, and buffering when no encoding is provided. On Python 2, it's impossible to use the errors keyword (because plain built-in open doesn't do decoding, it doesn't accept an errors parameter); on Python 3, you could, but you'd be adding to the behavioral discrepancies with Python 2.

The docs (just above codecs.open) already state:

"the builtin open() and the associated io module are the recommended approach for working with encoded text files"; personally, I'm inclined to just wash my hands of codecs.open (perhaps moving the note about builtin open down inside codecs.open's docs, so people who get a direct link don't have to scroll up to notice the note).

codecs.open was and is underspecified, never worked right (e.g. #8260, which despite the status, is not really fixed https://stackoverflow.com/a/46438434/364696 ), and the code which uses it is likely already working around its quirks, making fixes difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 20:06:53 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 31 Jan 2018 01:06:53 +0000
Subject: [issue32723] codecs.open silently ignores argument errors
In-Reply-To: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>
Message-ID: <1517360813.59.0.467229070634.issue32723@psf.upfronthosting.co.za>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 20:38:20 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 31 Jan 2018 01:38:20 +0000
Subject: [issue32387] Disallow untagged C extension import on major platforms
In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za>
Message-ID: <1517362700.02.0.467229070634.issue32387@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

So, just for clarity, is there another approved mechanism for distributing an extension that just happens to act as a (Python version specific) C support library? I've wanted to be able to build a library (static or dynamic) that is installed to lib/pythonX.Y/site-packages so it can be found by other extensions that use it without them having to ship a copy themselves.

The best solution I found was building and installing untagged extensions with pip; the extension features weren't actually used for anything but unittesting the library, but making it an extension meant it got installed to the Python version specific site-packages.

If untagged extensions aren't just old-fashioned, but banned, my use case is broken, and I've been completely unable to find a decent, non-Cython based, setup.py based pattern for building a C library that provides wrappers for Python API calls (and therefore must target specific Python versions).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32387>
_______________________________________

From report at bugs.python.org  Tue Jan 30 20:39:49 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 31 Jan 2018 01:39:49 +0000
Subject: [issue32694] Can no longer specify OpenSSL locations with CPPFLAGS /
 LDFLAGS ?
In-Reply-To: <1517152421.93.0.467229070634.issue32694@psf.upfronthosting.co.za>
Message-ID: <1517362789.35.0.467229070634.issue32694@psf.upfronthosting.co.za>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
title: Can no longer specify OpenSLL locations with CPPFLAGS / LDFLAGS ? -> Can no longer specify OpenSSL locations with CPPFLAGS / LDFLAGS ?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Tue Jan 30 21:33:31 2018
From: report at bugs.python.org (Xavier G. Domingo)
Date: Wed, 31 Jan 2018 02:33:31 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1517366011.63.0.467229070634.issue30491@psf.upfronthosting.co.za>


Change by Xavier G. Domingo <xgdomingo at gmail.com>:


----------
nosy: +xgdomingo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Tue Jan 30 23:23:23 2018
From: report at bugs.python.org (Xavier G. Domingo)
Date: Wed, 31 Jan 2018 04:23:23 +0000
Subject: [issue32623] Resize dict on del/pop
In-Reply-To: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>
Message-ID: <1517372603.97.0.467229070634.issue32623@psf.upfronthosting.co.za>


Change by Xavier G. Domingo <xgdomingo at gmail.com>:


----------
nosy: +xgdomingo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Tue Jan 30 23:24:57 2018
From: report at bugs.python.org (Xavier G. Domingo)
Date: Wed, 31 Jan 2018 04:24:57 +0000
Subject: [issue32637] Android: set sys.platform to android
In-Reply-To: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>
Message-ID: <1517372697.31.0.467229070634.issue32637@psf.upfronthosting.co.za>


Change by Xavier G. Domingo <xgdomingo at gmail.com>:


----------
nosy: +xgdomingo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Wed Jan 31 00:16:12 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 05:16:12 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517375772.07.0.467229070634.issue25988@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Guido:
> But we should make some noise around this change in the 3.7 announcement.

How about a paragraph in the Deprecation section of the "What's New in Python 3.7"? document

https://docs.python.org/dev/whatsnew/3.7.html#deprecated

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Wed Jan 31 00:48:09 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Jan 2018 05:48:09 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517377689.55.0.467229070634.issue25988@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> > But we should make some noise around this change in the 3.7 announcement.
>
> How about a paragraph in the Deprecation section of the "What's New in Python 3.7"? document
>
> https://docs.python.org/dev/whatsnew/3.7.html#deprecated

You mean other than what's there? The text that's currently there begins with "In Python 3.8, ..." which almost sounds like it's misplaced or a typo.  Maybe you can amend it somehow to explain that in 3.7, using or importing the ABCs from "collections" instead of from "collections.abc" is deprecated, and in 3.8 it will stop working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Wed Jan 31 01:16:23 2018
From: report at bugs.python.org (Lisa Roach)
Date: Wed, 31 Jan 2018 06:16:23 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517379383.41.0.467229070634.issue31356@psf.upfronthosting.co.za>


Change by Lisa Roach <lisaroach14 at gmail.com>:


----------
pull_requests: +5284
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 01:17:36 2018
From: report at bugs.python.org (Lisa Roach)
Date: Wed, 31 Jan 2018 06:17:36 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517379456.38.0.467229070634.issue31356@psf.upfronthosting.co.za>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

I gave it a shot- looks like we need to ensure that we catch any errors that could be thrown by the warning itself.

I wasn't entirely sure how to create a test for this, if anyone knows how I'll definitely add it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 01:37:30 2018
From: report at bugs.python.org (=?utf-8?b?7JaR7JiB7J28?=)
Date: Wed, 31 Jan 2018 06:37:30 +0000
Subject: [issue32729] socket error handling needed
Message-ID: <1517380649.99.0.467229070634.issue32729@psf.upfronthosting.co.za>


New submission from ??? <sun0202id at gmail.com>:

socket error handling needed

----------
components: IO
messages: 311313
nosy: ???
priority: normal
severity: normal
status: open
title: socket error handling needed
type: crash
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32729>
_______________________________________

From report at bugs.python.org  Wed Jan 31 01:49:00 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 31 Jan 2018 06:49:00 +0000
Subject: [issue32387] Disallow untagged C extension import on major platforms
In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za>
Message-ID: <1517381340.64.0.467229070634.issue32387@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Interesting use case Josh.  I don't know of a good way to deal with non-extension-module Python API using .so files.  I like your extension hack, but what is the problem with having the version embedded in the .so name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32387>
_______________________________________

From report at bugs.python.org  Wed Jan 31 02:48:49 2018
From: report at bugs.python.org (Kubilay Kocak)
Date: Wed, 31 Jan 2018 07:48:49 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1517384929.23.0.467229070634.issue20767@psf.upfronthosting.co.za>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

The changeset(s) applied in this issue were/are fine (thus no response on the issue)

It is the *removal* of the changesets included in this issue (as proposed in https://github.com/python/cpython/pull/5233) that would re-break compilation of extensions with clang (requiring re-opening this issue)

The root cause of the current confusion is the special case added here was conditional on the OS ('freebsd'), whereas it should (arguably) have been for a specific compiler (clang). 

In order to do this, this leads to the compiler detection code requiring improvement, see: https://github.com/python/cpython/pull/5233#issuecomment-358906977 as it currently does not detect clang as the default compiler (cc), see: https://github.com/python/cpython/pull/5233#issuecomment-358948425

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Wed Jan 31 02:51:48 2018
From: report at bugs.python.org (Kubilay Kocak)
Date: Wed, 31 Jan 2018 07:51:48 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1517385108.1.0.467229070634.issue20767@psf.upfronthosting.co.za>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

If the intent is to use this issue to track the resolution of the original issue (clang compilation broken) and cover the new PR (which just moves the code from os detection to compiler detection), then it can remain open. 

Otherwise it can be closed, as the original issue 'has' been fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Wed Jan 31 03:34:31 2018
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Wed, 31 Jan 2018 08:34:31 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1517387671.94.0.467229070634.issue29708@psf.upfronthosting.co.za>


Bernhard M. Wiedemann <pythonbugs at lsmod.de> added the comment:

Any chance we can get the (somewhat related) patch for https://bugs.python.org/issue30693 also merged?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Jan 31 04:09:18 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Jan 2018 09:09:18 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1517389758.14.0.467229070634.issue30693@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

We missed beta freeze deadline. :/

Ned,
can we get this change into beta 2? It's low risk change to make the tarballs and other archives have a stable sort order. We even considered to backport the change to 3.6 and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 31 05:12:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Jan 2018 10:12:52 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517393572.29.0.467229070634.issue25988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Can't we use the new shiny PEP 562 here to actually emit a warning when collections.Iterable is used instead of collections.abc.Iterable?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Wed Jan 31 05:17:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Jan 2018 10:17:16 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1517393836.85.0.467229070634.issue30693@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 84521047e413d7d1150aaa1c333580b683b3f4b1 by Victor Stinner (Bernhard M. Wiedemann) in branch 'master':
bpo-30693: zip+tarfile: sort directory listing (#2263)
https://github.com/python/cpython/commit/84521047e413d7d1150aaa1c333580b683b3f4b1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 31 05:22:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Jan 2018 10:22:07 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1517394127.84.0.467229070634.issue30693@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> We missed beta freeze deadline. :/

I merged the PR. We will have to create a cherry-pick request once the 3.7 branch will be created. If Ned rejects it, we have to change the version number of documentation.

https://mail.python.org/pipermail/python-dev/2018-January/152012.html

IMHO the change is very safe to be merged into 3.7b2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 31 05:55:10 2018
From: report at bugs.python.org (Florian Weimer)
Date: Wed, 31 Jan 2018 10:55:10 +0000
Subject: [issue31912] PyMem_Malloc() should guarantee alignof(max_align_t)
In-Reply-To: <1509472895.95.0.213398074469.issue31912@psf.upfronthosting.co.za>
Message-ID: <1517396110.43.0.467229070634.issue31912@psf.upfronthosting.co.za>


Florian Weimer <fweimer at redhat.com> added the comment:

max_align_t is a bit of a kitchen sink and will specify larger and larger alignment in the future, e.g. 32-byte alignment for a complex _Float128 type (a pair of two _Float128 variables).  The alignment is also not generally useful for allocations whose size is smaller than the alignment.  (Many mallocs do not follow the C standard and do not provide 16-byte alignment when 8 bytes are allocated, although alignof(max_align_t) is 16.)

----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31912>
_______________________________________

From report at bugs.python.org  Wed Jan 31 05:57:18 2018
From: report at bugs.python.org (Florian Weimer)
Date: Wed, 31 Jan 2018 10:57:18 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1517396238.5.0.467229070634.issue27987@psf.upfronthosting.co.za>


Florian Weimer <fweimer at redhat.com> added the comment:

This bug causes miscompilation of Python 2.7 by GCC 8 on x86-64 (with no sanitizers enabled, just compiler optimization).

I think this is a fairly conservative way for papering over the issue:

https://mail.python.org/pipermail/python-dev/2018-January/152011.html

----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Wed Jan 31 05:57:24 2018
From: report at bugs.python.org (Florian Weimer)
Date: Wed, 31 Jan 2018 10:57:24 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1517396244.17.0.467229070634.issue27987@psf.upfronthosting.co.za>


Change by Florian Weimer <fweimer at redhat.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Wed Jan 31 06:51:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 11:51:34 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1517399494.78.0.467229070634.issue30693@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I requested additional changes in msg310337.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 31 06:58:12 2018
From: report at bugs.python.org (qb-cea)
Date: Wed, 31 Jan 2018 11:58:12 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1517399892.52.0.467229070634.issue24132@psf.upfronthosting.co.za>


Change by qb-cea <quentin.bouget at cea.fr>:


----------
nosy: +qb-cea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Wed Jan 31 07:12:54 2018
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Wed, 31 Jan 2018 12:12:54 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1517400774.76.0.467229070634.issue30693@psf.upfronthosting.co.za>


Bernhard M. Wiedemann <pythonbugs at lsmod.de> added the comment:

@Serhiy IMHO, just because we fix one problem, we do not have to fix all other problems at the same time. You can still open a pull-request for the others, but I know too little about those to test them.
And having commits pending for 7 months is not exactly energizing either.

For my use-case I just needed a trivial 1 line fix in tarfile.py and already ended up with a diffstat of
 7 files changed, 39 insertions(+), 6 deletions(-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 31 07:38:03 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 31 Jan 2018 12:38:03 +0000
Subject: [issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit
 CPython 'current user only' installations on 64-bit Windows
In-Reply-To: <1395251194.85.0.622620129448.issue20984@psf.upfronthosting.co.za>
Message-ID: <1517402283.33.0.467229070634.issue20984@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Based on Steve's last comment on this issue, should this be closed as 'Out of Date'?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20984>
_______________________________________

From report at bugs.python.org  Wed Jan 31 07:48:12 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Jan 2018 12:48:12 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1517402892.68.0.467229070634.issue32583@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 2c7fd46e11333ef5e5cce34212f7d087694f3658 by Xiang Zhang in branch 'master':
bpo-32583: Fix possible crashing in builtin Unicode decoders (#5325)
https://github.com/python/cpython/commit/2c7fd46e11333ef5e5cce34212f7d087694f3658


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 31 08:01:25 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Jan 2018 13:01:25 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1517403685.25.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5285

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 31 08:31:05 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Dupuis?=)
Date: Wed, 31 Jan 2018 13:31:05 +0000
Subject: [issue15795] Zipfile.extractall does not preserve file permissions
In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za>
Message-ID: <1517405465.04.0.467229070634.issue15795@psf.upfronthosting.co.za>


?tienne Dupuis <svart.riddare at gmail.com> added the comment:

A workaround is provided here: https://stackoverflow.com/questions/39296101/python-zipfile-removes-execute-permissions-from-binaries

----------
nosy: +?tienne Dupuis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15795>
_______________________________________

From report at bugs.python.org  Wed Jan 31 08:34:19 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Jan 2018 13:34:19 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1517405659.95.0.467229070634.issue32583@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset ea94fce6960d90fffeeda131e31024617912d231 by Xiang Zhang in branch '3.6':
[3.6] bpo-32583: Fix possible crashing in builtin Unicode decoders (GH-5325) (#5459)
https://github.com/python/cpython/commit/ea94fce6960d90fffeeda131e31024617912d231


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 31 08:35:16 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Jan 2018 13:35:16 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1517405716.9.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 31 08:38:48 2018
From: report at bugs.python.org (ABR)
Date: Wed, 31 Jan 2018 13:38:48 +0000
Subject: [issue15795] Zipfile.extractall does not preserve file permissions
In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za>
Message-ID: <1517405928.36.0.467229070634.issue15795@psf.upfronthosting.co.za>


Change by ABR <Adrian.Robert at solaforce.com>:


----------
nosy:  -arobert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15795>
_______________________________________

From report at bugs.python.org  Wed Jan 31 08:47:37 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 31 Jan 2018 13:47:37 +0000
Subject: [issue29209] Remove old-deprecated ElementTree features
In-Reply-To: <1483898185.03.0.0187159979308.issue29209@psf.upfronthosting.co.za>
Message-ID: <1517406457.83.0.467229070634.issue29209@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Serhiy,

Did you want to revive this for 3.8?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29209>
_______________________________________

From report at bugs.python.org  Wed Jan 31 08:57:42 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 31 Jan 2018 13:57:42 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517407062.22.0.467229070634.issue31356@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

@lisroach A possible test for this is repeat `test_ensure_disabled_thread` with warnings as errors:

```python
warnings.filterwarnings('error')
```

and then checking for a `RuntimeWarning` exception instead of the warning. I think this will work because without the changes in this PR, this proposed test will produce this error:

```python

======================================================================
ERROR: test_ensure_disabled_thread (Lib.test.test_gc.GCTogglingTests)
----------------------------------------------------------------------
RuntimeWarning: Garbage collector enabled while another thread is inside gc.ensure_enabled

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/pgalindo3/cpython/Lib/test/support/__init__.py", line 2083, in decorator
    return func(*args)
  File "/home/pgalindo3/cpython/Lib/test/test_gc.py", line 1063, in test_ensure_disabled_thread
    inside_status_after_thread = gc.isenabled()
SystemError: <built-in method __exit__ of gc.ensure_disabled object at 0x7f0253d22de0> returned a result with an error se

```

Another posible test is checking that SystemError is not raised / in stderr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 09:21:35 2018
From: report at bugs.python.org (yang)
Date: Wed, 31 Jan 2018 14:21:35 +0000
Subject: [issue32729] socket error handling needed
In-Reply-To: <1517380649.99.0.467229070634.issue32729@psf.upfronthosting.co.za>
Message-ID: <1517408495.74.0.467229070634.issue32729@psf.upfronthosting.co.za>


yang <rkdls9 at naver.com> added the comment:

If socket error occurred I think it is a timeout error or something. but It's not error raising correctly but IndexError which is not correct error MSG.

It will be fixed or None type check needed.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32729>
_______________________________________

From report at bugs.python.org  Wed Jan 31 09:27:42 2018
From: report at bugs.python.org (yang)
Date: Wed, 31 Jan 2018 14:27:42 +0000
Subject: [issue32729] socket error handling needed
In-Reply-To: <1517380649.99.0.467229070634.issue32729@psf.upfronthosting.co.za>
Message-ID: <1517408862.36.0.467229070634.issue32729@psf.upfronthosting.co.za>


Change by yang <rkdls9 at naver.com>:


----------
keywords: +patch
pull_requests: +5286
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32729>
_______________________________________

From report at bugs.python.org  Wed Jan 31 09:29:38 2018
From: report at bugs.python.org (yang)
Date: Wed, 31 Jan 2018 14:29:38 +0000
Subject: [issue32729] socket error handling needed
In-Reply-To: <1517380649.99.0.467229070634.issue32729@psf.upfronthosting.co.za>
Message-ID: <1517408978.03.0.467229070634.issue32729@psf.upfronthosting.co.za>


yang <rkdls9 at naver.com> added the comment:

In the lib/socket.py 

Inside of readinto function, 576 line 
needed None type check or something

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32729>
_______________________________________

From report at bugs.python.org  Wed Jan 31 09:34:27 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Jan 2018 14:34:27 +0000
Subject: [issue32723] codecs.open silently ignores argument errors
In-Reply-To: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>
Message-ID: <1517409267.48.0.467229070634.issue32723@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Honestly speaking I am not interested in Python3. I think codecs.open will be deprecated one day in Python3 and Victor has raised it long ago. See #8796.

And in Python2, codecs.open is still in use. errors could still function when you are writing, encoding, just as the example I give. So now if encoding is not given, the builtin open is used, no matter errors is given or not. Is it reasonable to change the logic to either encoding or errors is given, we don't use the builtin open but the StreamReaderWriter wrapper?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Wed Jan 31 09:42:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 14:42:43 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517409763.81.0.467229070634.issue25988@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5287

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Wed Jan 31 09:48:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 14:48:22 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517410102.53.0.467229070634.issue25988@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Can't we use the new shiny PEP 562 here to actually emit a warning when collections.Iterable is used instead of collections.abc.Iterable?

PR 5460 implements this.

It exposes issues in third-party packages. urllib3 and pyparsing directly use or import ABCs from 'collections'. request and pip are indirectly affected. If not add these warnings in 3.7 we can break the world in 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Wed Jan 31 10:42:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 15:42:32 +0000
Subject: [issue32072] Issues with binary plists
In-Reply-To: <1511031976.48.0.213398074469.issue32072@psf.upfronthosting.co.za>
Message-ID: <1517413352.42.0.467229070634.issue32072@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks Larry.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32072>
_______________________________________

From report at bugs.python.org  Wed Jan 31 10:54:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 15:54:18 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517414058.91.0.467229070634.issue31356@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Actually raising an exception in PyErr_WarnEx() is not an error, but a standard behavior with corresponding configuration.

For now running tests with -We in debug build crashes.

$ ./python -We -m test test_gc
Run tests sequentially
0:00:00 load avg: 0.33 [1/1] test_gc
Fatal Python error: a function returned a result with an error set
RuntimeWarning: Garbage collector enabled while another thread is inside gc.ensure_enabled

The above exception was the direct cause of the following exception:

SystemError: <built-in method __exit__ of gc.ensure_disabled object at 0x7fb1b62a08f8> returned a result with an error set

Thread 0x00007fb1b1773700 (most recent call first):
  File "/home/serhiy/py/cpython/Lib/test/test_gc.py", line 1050 in disabling_thread
  File "/home/serhiy/py/cpython/Lib/threading.py", line 865 in run
  File "/home/serhiy/py/cpython/Lib/threading.py", line 917 in _bootstrap_inner
  File "/home/serhiy/py/cpython/Lib/threading.py", line 885 in _bootstrap

Current thread 0x00007fb1b824f040 (most recent call first):
  File "/home/serhiy/py/cpython/Lib/test/test_gc.py", line 1061 in test_ensure_disabled_thread
  File "/home/serhiy/py/cpython/Lib/test/support/__init__.py", line 2083 in decorator
  File "/home/serhiy/py/cpython/Lib/unittest/case.py", line 615 in run
  File "/home/serhiy/py/cpython/Lib/unittest/case.py", line 663 in __call__
  File "/home/serhiy/py/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/serhiy/py/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/serhiy/py/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/serhiy/py/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/serhiy/py/cpython/Lib/test/support/__init__.py", line 1760 in run
  File "/home/serhiy/py/cpython/Lib/test/support/__init__.py", line 1861 in _run_suite
  File "/home/serhiy/py/cpython/Lib/test/support/__init__.py", line 1951 in run_unittest
  File "/home/serhiy/py/cpython/Lib/test/test_gc.py", line 1088 in test_main
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/runtest.py", line 176 in runtest_inner
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/main.py", line 379 in run_tests_sequential
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/main.py", line 458 in run_tests
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/main.py", line 536 in _main
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/main.py", line 510 in main
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/main.py", line 585 in main
  File "/home/serhiy/py/cpython/Lib/test/__main__.py", line 2 in <module>
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 193 in _run_module_as_main
Aborted (core dumped)

----------
nosy: +ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 10:57:13 2018
From: report at bugs.python.org (Peter Suter)
Date: Wed, 31 Jan 2018 15:57:13 +0000
Subject: [issue32730] Allow py launcher to launch other registered Pythons
Message-ID: <1517414233.69.0.467229070634.issue32730@psf.upfronthosting.co.za>


New submission from Peter Suter <petsuter at gmail.com>:

For example Anaconda Python is registered under HKEY_LOCAL_MACHINE\Software\Python\ContinuumAnalytics\Anaconda36-64\ as described in PEP 514 "Python registration in the Windows registry" .

The py launcher from PEP 397 however ignores that and only considers HKEY_LOCAL_MACHINE\Software\Python\PythonCore\ registrations.

There seems to be no mechanism to register Anaconda Python with the py launcher. Anaconda considers this a bug in the Python launcher. https://github.com/ContinuumIO/anaconda-issues/issues/149#issuecomment-361922640

Shouldn't this be possible? Maybe via py.ini [defaults]?

----------
components: Windows
messages: 311338
nosy: paul.moore, petsuter at gmail.com, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Allow py launcher to launch other registered Pythons
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32730>
_______________________________________

From report at bugs.python.org  Wed Jan 31 11:06:43 2018
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 31 Jan 2018 16:06:43 +0000
Subject: [issue32072] Issues with binary plists
In-Reply-To: <1511031976.48.0.213398074469.issue32072@psf.upfronthosting.co.za>
Message-ID: <1517414803.59.0.467229070634.issue32072@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Thank you for the fix!  I just wish I knew what plists were ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32072>
_______________________________________

From report at bugs.python.org  Wed Jan 31 11:14:45 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 16:14:45 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517415285.9.0.467229070634.issue31356@psf.upfronthosting.co.za>


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


----------
pull_requests: +5288

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 11:18:19 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 16:18:19 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517415499.53.0.467229070634.issue31356@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Just noting here: the original PR was a little bit under-reviewed: return values of C functions were not checked, and the code style was very far from PEP 7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 11:24:14 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Jan 2018 16:24:14 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517415854.17.0.467229070634.issue25988@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Good idea, Victor, and thanks for the PR, Serhiy!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Wed Jan 31 11:43:55 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 16:43:55 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517417035.55.0.467229070634.issue31356@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

IMO this needs to be pulled from 3.7.  Ned?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 12:09:19 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 31 Jan 2018 17:09:19 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517418559.52.0.467229070634.issue31356@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I would not remove this.  It is a new feature, leave it in for 3.7.

The style issues and missing error checks are easy to address.  We're at 3.7beta1 stage, it is normal to have issues to be cleaned up in a beta release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 12:10:01 2018
From: report at bugs.python.org (Xavier G. Domingo)
Date: Wed, 31 Jan 2018 17:10:01 +0000
Subject: [issue32703] 'async with' somehow suppresses unawaited coroutine
 warnings
In-Reply-To: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>
Message-ID: <1517418601.09.0.467229070634.issue32703@psf.upfronthosting.co.za>


Change by Xavier G. Domingo <xgdomingo at gmail.com>:


----------
nosy: +xgdomingo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Wed Jan 31 12:11:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 17:11:23 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517418683.43.0.467229070634.issue31356@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The style issues and missing error checks are easy to address.  We're at 3.7beta1 stage, it is normal to have issues to be cleaned up in a beta release.


I don't understand the code. Please take a look in my PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 12:13:43 2018
From: report at bugs.python.org (Niko Fink)
Date: Wed, 31 Jan 2018 17:13:43 +0000
Subject: [issue29780] Interpreter hang on self._epoll.poll(timeout, max_ev)
In-Reply-To: <1489139274.42.0.877186515769.issue29780@psf.upfronthosting.co.za>
Message-ID: <1517418823.64.0.467229070634.issue29780@psf.upfronthosting.co.za>


Niko Fink <python at niko.fink.bayern> added the comment:

I recently had a similar issue, a MWE can be found here (and also attached):
https://gist.github.com/N-Coder/89b1be8e5cfb83b1b03ade8485676982
As soon as `loop.stop` in loop_stop_problem.py:44 is called in a non-threadsafe way from another thread, i.e. without loop.call_soon_threadsafe, the loop seems to hang in `self._epoll.poll(timeout, max_ev)`.
This can be seen when comparing the two outputs in threadunsafe_loop_stop.log (without loop.call_soon_threadsafe) and call_soon_threadsafe_loop_stop.log (with loop.call_soon_threadsafe). Please note the time difference after "Waiting for loop join".
The loop seems to hang until the (seemingly random) epoll timeout occurs, or the next pending events needs to be processed (which might take quite some time).

There is also no explicit note about this behavior in the doc of the function (https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.stop), only a small note in the doc of AbstractEventLoop, informing you about the non-thread-safety of the whole class.
Also, other methods like `call_at` use `BaseEventLoop._check_thread` (https://github.com/python/cpython/blob/3.6/Lib/asyncio/base_events.py#L549) to check for violations when running in debug mode. Unfortunately, `stop` doesn't make those checks.
All this together makes this bug very hard to find.

So, i'd vote for adding a short `if self._debug: self._check_thread()` to the `stop` method.

----------
nosy: +NCode
Added file: https://bugs.python.org/file47418/loop_stop_problem.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29780>
_______________________________________

From report at bugs.python.org  Wed Jan 31 12:19:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 17:19:37 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1517419177.37.0.467229070634.issue25988@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c66f9f8d3909f588c251957d499599a1680e2320 by Serhiy Storchaka in branch 'master':
bpo-25988: Emit a warning when use or import ABCs from 'collections'. (#5460)
https://github.com/python/cpython/commit/c66f9f8d3909f588c251957d499599a1680e2320


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Wed Jan 31 12:32:55 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Wed, 31 Jan 2018 17:32:55 +0000
Subject: [issue32689] shutil.move raises AttributeError if first argument is a
 pathlib.Path object and destination is a directory
In-Reply-To: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>
Message-ID: <1517419975.09.0.467229070634.issue32689@psf.upfronthosting.co.za>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Wed Jan 31 12:56:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 17:56:27 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517421387.81.0.467229070634.issue31356@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I don't understand why PyGILState_Ensure() and PyGILState_Release() are used at all. I think it is better to revert PR 4224 until we understood this code.

Currently the code contains a bug which leads to a crash in some circumstances. Since several third-party projects try to support warning-free code, this can prevent running tests with 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:00:16 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 18:00:16 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517421616.01.0.467229070634.issue31356@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

A few thoughts:

1. The merged PR releases GIL for any Python code run in `with gc.ensure_disabled()`.  This is just plain wrong.

2. The merged PR crashes on debug build of CPython.

3. I don't actually understand this feature.  Our GC is not per OS thread, which means that inside `with gc.ensure_disabled()` the GC can become suddenly **enabled**, if another thread enables it.  This API is just misleading (maybe the name of the new context manager is bad?it cannot ensure anything).  There's even a unittest that tests this!

4. This new API can be trivially implemented in pure Python:

   @contextmanager
   def disable_gc():
       gc.disable()
       try:
           yield
       finally:
           gc.enable()

5. While such pure Python version shares the problem discussed in (3), the currently committed C implementation doesn't fix them either.

IMO this entire issue needs to be properly debated on python-ideas first and the PR should be reverted from beta-1.  If the latter is not possible, OK, let's revert it for beta-2 and for 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:02:32 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 31 Jan 2018 18:02:32 +0000
Subject: [issue32731] getpass.getuser() raises an unspecified exceptions
 (ImportError, OSError, etc)
Message-ID: <1517421752.06.0.467229070634.issue32731@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

This has been true since Python 1.x.  getpass.getuser() is documented as "raising an exception" but doesn't specify what exception.

On Windows when the environment variables it looks at are not set, an ImportError (!) escapes due to "import pwd" failing.  It could just a easily allow an exception from the following pwd.getpwuid(os.getuid())[0] call to escape on systems when pwd exists.

None of these are actually helpful to the caller as they are left having to catch a bare Exception around a getpass.getuser() call to take another course of action.  I filed this as I just saw someone suggesting code that specifically catches ImportError on getpass.getuser().

It is too late to change the exception type coming out in 2.7 or 3.6, but cleaning up this underspecified behavior to be a meaningful exception for 3.7 seems reasonable.

----------
components: Library (Lib)
messages: 311349
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: getpass.getuser() raises an unspecified exceptions (ImportError, OSError, etc)
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32731>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:03:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 18:03:19 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1517421616.01.0.467229070634.issue31356@psf.upfronthosting.co.za>
Message-ID: <CAAuNNr4CPWFT3u2zBEXMZAj-oghxHREP03mLpiGwyp2mkjuYag@mail.gmail.com>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Yury.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:11:11 2018
From: report at bugs.python.org (Yaron de Leeuw)
Date: Wed, 31 Jan 2018 18:11:11 +0000
Subject: [issue32731] getpass.getuser() raises an unspecified exceptions
 (ImportError, OSError, etc)
In-Reply-To: <1517421752.06.0.467229070634.issue32731@psf.upfronthosting.co.za>
Message-ID: <1517422271.44.0.467229070634.issue32731@psf.upfronthosting.co.za>


Change by Yaron de Leeuw <me at jarondl.net>:


----------
nosy: +jarondl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32731>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:15:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 18:15:40 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517422540.09.0.467229070634.issue31356@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> 2. The merged PR crashes on debug build of CPython.

Actually, for me, it only crashes on a debug build when using -We with tests, an option I don't normally use, otherwise, I would have noticed it before.  And, as noted, few downstream users use debug builds.

But, more importantly, this is a new feature so it doesn't break any existing code.  If that is the case, I think we don't need to expedite a release; it can wait four weeks for 3.7.0b2 and in that time we need to decide what the proper actions for 3.7 (fix, reimplement, remove) and for 3.8.

Please chime in now if you strongly disagree.  In any case, thanks all for your efforts on this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:22:21 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 18:22:21 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517422941.32.0.467229070634.issue31356@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> But, more importantly, this is a new feature so it doesn't break any existing code.

I imagine you're almost done with the beta-1 release, Ned, so I'd hate to create more work for you here.  Let's release beta-1 as is.

> and in that time we need to decide what the proper actions for 3.7 (fix, reimplement, remove) and for 3.8.

I have a different opinion on this though.  The committed PR is **fundamentally** broken (releases GIL for Python code, refleaks, SIGABRT, nonsensical test) and the feature itself is very questionable.  As soon as 3.7 branch appears, I'll revert the commit from 3.7 and from master.

If we want this feature to be kept in 3.7beta2, someone should write a **new** patch from scratch.  But I strongly suggest to first discuss it on python-dev, because as is, not only the commit is broken, the proposed API is broken too from my standpoint.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:26:15 2018
From: report at bugs.python.org (Cyril Martin)
Date: Wed, 31 Jan 2018 18:26:15 +0000
Subject: [issue32732] LoggingAdapter ignores extra kwargs of Logger#log()
Message-ID: <1517423175.51.0.467229070634.issue32732@psf.upfronthosting.co.za>


New submission from Cyril Martin <mcoolive at gmail.com>:

- LoggerAdapter processes only extra kwargs given during its __init__
So extra kwargs, given to Logger#log are ignored when we configure a LoggerAdapter (same for: debug, info, warning etc).
- I expect extras are merged. More precisely, I expect local extra override the ones given in __init__

----------
components: Library (Lib)
messages: 311353
nosy: mcoolive
priority: normal
pull_requests: 5289
severity: normal
status: open
title: LoggingAdapter ignores extra kwargs of Logger#log()
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32732>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:29:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 18:29:07 +0000
Subject: [issue32733] test_coroutines is failed when run with -We
Message-ID: <1517423347.93.0.467229070634.issue32733@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

$ ./python -We -m test test_coroutines
Run tests sequentially
0:00:00 load avg: 0.29 [1/1] test_coroutines
Exception ignored in: <coroutine object OriginTrackingTest.test_origin_tracking_warning.<locals>.corofn at 0x7fc5fc692cb8>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 511, in _warn_unawaited_coroutine
    warn(msg, category=RuntimeWarning, stacklevel=2, source=coro)
RuntimeWarning: coroutine 'OriginTrackingTest.test_origin_tracking_warning.<locals>.corofn' was never awaited
test test_coroutines failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_coroutines.py", line 2167, in test_origin_tracking_warning
    msg = check(0, f"coroutine '{corofn.__qualname__}' was never awaited")
  File "/home/serhiy/py/cpython/Lib/test/test_coroutines.py", line 2161, in check
    self.assertTrue(len(wlist) == 1)
AssertionError: False is not true

test_coroutines failed

1 test failed:
    test_coroutines

Total duration: 371 ms
Tests result: FAILURE

This isn't release blocker, because the test is failed, not crashed, and seems this is just a test issue.

----------
components: Tests
messages: 311354
nosy: serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: test_coroutines is failed when run with -We
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32733>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:33:18 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 18:33:18 +0000
Subject: [issue32733] test_coroutines is failed when run with -We
In-Reply-To: <1517423347.93.0.467229070634.issue32733@psf.upfronthosting.co.za>
Message-ID: <1517423598.42.0.467229070634.issue32733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Nathaniel, this seems to be related to coro-origin-tracking.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32733>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:36:04 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 31 Jan 2018 18:36:04 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517423764.22.0.467229070634.issue31356@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I also think this should be reverted if that is still possible.  I didn't put in sufficient review effort at the outset.  No need to publish embarrassing code, especially for such a minor feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:46:36 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 18:46:36 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517424396.73.0.467229070634.issue31356@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

OK, it sounds like we have enough of a consensus to remove it for 3.7.0b2.  Unfortunately, 3.7.0b1 is already finished.  We are not going to do an emergency brown bag b2 just for this.  We could add a warning note to the release notice that is about to got out but OTOH the feature isn't very visible and the documentation for it will disappear from the docs web site once the revert is made (and please wait for the imminent announcement of the 3.7 branch to do that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:50:46 2018
From: report at bugs.python.org (Yaron de Leeuw)
Date: Wed, 31 Jan 2018 18:50:46 +0000
Subject: [issue32731] getpass.getuser() raises an unspecified exceptions
 (ImportError, OSError, etc)
In-Reply-To: <1517421752.06.0.467229070634.issue32731@psf.upfronthosting.co.za>
Message-ID: <1517424646.26.0.467229070634.issue32731@psf.upfronthosting.co.za>


Yaron de Leeuw <me at jarondl.net> added the comment:

What kind of exception did you have in mind? As the 'someone' you mentioned, I can contribute this.

btw, os.getuid() on windows raises an attribute error, so we need to check that too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32731>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:53:20 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 18:53:20 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517424800.63.0.467229070634.issue31356@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

(If anyone downstream is having problems with test aborts, a workaround until b2 is to simply skip test_gc by adding -x test_gc, like:

python3.7 -m test -We -x test_gc".
)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:54:19 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 18:54:19 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517424859.51.0.467229070634.issue31356@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

(If anyone downstream is having problems with test aborts, a workaround until b2 is to simply skip test_gc by adding -x test_gc, like:

python3.7 -m test -We -x test_gc

)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:54:32 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 18:54:32 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517424872.12.0.467229070634.issue31356@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg311359

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:55:45 2018
From: report at bugs.python.org (Bar Harel)
Date: Wed, 31 Jan 2018 18:55:45 +0000
Subject: [issue32734] Asyncio Lock safety issue (unlimited acquire)
Message-ID: <1517424945.58.0.467229070634.issue32734@psf.upfronthosting.co.za>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Hey guys,

I found a pretty dangerous bug that allows acquiring locks in asyncio without them being free.

This happens due to double release (calling _wake_up_first) from both release and acquire in case of cancellation.

The example I've uploaded exploits it by acquiring 4 times, which grooms the loop's _ready queue, cancelling the second acquire to add the cancellation to the _ready queue, and releasing once to add the next waiter (number 3) to the _ready queue. Next event loop step causes the cancellation to run first, skipping the queued waiter (due to .done check being true) and waking the next waiter in line (number 4). Then both number 3 and number 4 run together on the same Lock.

I'm not at home so it's hard for me to code but the simple way of fixing it is by adding this line - "if self._locked: yield from self.acquire()" after the "yield from fut" (quite minimal overhead and only if bug happens, so no harm) or by slightly restructuring the code and the checks regarding cancelled futures.

I can later on post the restructured code but I think the simple if statement is a pretty fine and efficient fix.

----------
components: asyncio
files: bug.py
messages: 311361
nosy: asvetlov, bar.harel, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio Lock safety issue (unlimited acquire)
type: security
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47419/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32734>
_______________________________________

From report at bugs.python.org  Wed Jan 31 14:13:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 31 Jan 2018 19:13:36 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517426016.31.0.467229070634.issue31356@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Agree that this is invisible enough that no release note is warranted.

Can I go ahead and do a reversion on the master branch or I should I wait a day or so?

----------
assignee: lisroach -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 14:15:52 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 19:15:52 +0000
Subject: [issue32734] Asyncio Lock safety issue (unlimited acquire)
In-Reply-To: <1517424945.58.0.467229070634.issue32734@psf.upfronthosting.co.za>
Message-ID: <1517426152.73.0.467229070634.issue32734@psf.upfronthosting.co.za>


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


----------
priority: normal -> high
stage:  -> needs patch
type: security -> behavior
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32734>
_______________________________________

From report at bugs.python.org  Wed Jan 31 14:17:07 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 19:17:07 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517426227.19.0.467229070634.issue31356@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> Agree that this is invisible enough that no release note is warranted.

OK

> Can I go ahead and do a reversion on the master branch or I should I wait a day or so?

Please hold off for the moment until the 3.7 branch is announced.  It will make life easier for me.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 14:22:31 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 31 Jan 2018 19:22:31 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1517426551.39.0.467229070634.issue18876@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I believe Erik opened #20082 for the BufferedWriter bug, so I think this issue can be closed as Resolved?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:26:32 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Wed, 31 Jan 2018 20:26:32 +0000
Subject: [issue27923] PEP 467 -- Minor API improvements for binary sequences
In-Reply-To: <1472691379.75.0.669592694643.issue27923@psf.upfronthosting.co.za>
Message-ID: <1517430392.91.0.467229070634.issue27923@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

What else needs to be done with this issue? Can someone merge my pull request?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27923>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:34:17 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 31 Jan 2018 20:34:17 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517430857.4.0.467229070634.issue31356@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

Since "ensure_disabled" is a class https://docs.python.org/3.7/library/gc.html#gc.ensure_disabled it should be "EnsureDisabled" according to https://www.python.org/dev/peps/pep-0008/#class-names

----------
nosy: +YoSTEALTH

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:44:35 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 31 Jan 2018 20:44:35 +0000
Subject: [issue32733] test_coroutines is failed when run with -We
In-Reply-To: <1517423347.93.0.467229070634.issue32733@psf.upfronthosting.co.za>
Message-ID: <1517431475.57.0.467229070634.issue32733@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Ok, yeah, that's a test that a warning is emitted, which fails when the warning is converted into an error instead. Need to normalize the warnings filter settings inside that test, I guess.

How does this not cause the same problem for every other test that uses assertWarns though?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32733>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:48:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 20:48:59 +0000
Subject: [issue32733] test_coroutines is failed when run with -We
In-Reply-To: <1517423347.93.0.467229070634.issue32733@psf.upfronthosting.co.za>
Message-ID: <1517431739.92.0.467229070634.issue32733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I think assertWarns just handles it. Maybe the test should be converted to use it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32733>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:50:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Jan 2018 20:50:05 +0000
Subject: [issue32733] test_coroutines is failed when run with -We
In-Reply-To: <1517423347.93.0.467229070634.issue32733@psf.upfronthosting.co.za>
Message-ID: <1517431805.04.0.467229070634.issue32733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Or to use assertWarnsRegex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32733>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:54:12 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Jan 2018 20:54:12 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517432052.27.0.467229070634.issue32727@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:


New changeset 85a92d00bd278022cc00fda6b124c06f614c5ebb by R. David Murray (Miss Islington (bot)) in branch '3.6':
bpo-32727: smtplib's SMTP.send_message behaves differently with from_addr and to_addrs (GH-5451) (#5455)
https://github.com/python/cpython/commit/85a92d00bd278022cc00fda6b124c06f614c5ebb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:56:00 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 31 Jan 2018 20:56:00 +0000
Subject: [issue32735] Typo in f-string example in docs
Message-ID: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

On the lexical analysis doc page, in f-strings example, the following example isn't quite right:

>>> f"{today:%b %d, %Y}"  # using date format specifier
'January 27, 2017'

Submitting a patch shortly to use %B instead of %b.

----------
assignee: docs at python
components: Documentation
messages: 311371
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Typo in f-string example in docs
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:57:18 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 31 Jan 2018 20:57:18 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517432238.6.0.467229070634.issue32735@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5290
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:00:13 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 31 Jan 2018 21:00:13 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517432413.44.0.467229070634.issue31356@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

ps, maybe a better name "DisabledZone" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:04:15 2018
From: report at bugs.python.org (Emily Morehouse)
Date: Wed, 31 Jan 2018 21:04:15 +0000
Subject: [issue32689] shutil.move raises AttributeError if first argument is a
 pathlib.Path object and destination is a directory
In-Reply-To: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>
Message-ID: <1517432655.65.0.467229070634.issue32689@psf.upfronthosting.co.za>


Emily Morehouse <emily at cuttlesoft.com> added the comment:

Ah, you're right. That was a typo when I was redacting my full path. The path object remains unchanged even though the directory has moved. 

Should have been:

    >>> import os, pathlib, shutil
    >>> os.mkdir('test1')
    >>> os.mkdir('test2')
    >>> path = pathlib.Path('test1')
    >>> path.absolute()
    PosixPath('/Users/e/Development/OSS/cpython/test1')
    >>> shutil.move(path, 'test2')
    'test2/test1'
    >>> path.absolute()
    PosixPath('/Users/e/Development/OSS/cpython/test1')

test1 is now actually at '/Users/e/Development/OSS/cpython/test2/test1'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:05:31 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Jan 2018 21:05:31 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517432731.15.0.467229070634.issue32727@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, St?phane.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:13:38 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 31 Jan 2018 21:13:38 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517433218.71.0.467229070634.issue32735@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Good catch!

I checked my presentation slides (where this example comes from).
It appeared that I meant it as %b, so the output should have been `Jan` instead of `January`.

But no strong preference, the idea is to demonstrate how to use the specifier, so %B works too.

----------
nosy: +Mariatta
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:37:59 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 31 Jan 2018 21:37:59 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517434679.89.0.467229070634.issue32735@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset b299393cc372f3ecbef4304f8eaa4c7838e975ca by Mariatta (Cheryl Sabella) in branch 'master':
bpo-32735: Fix typo in f-strings datetime format specifier example (GH-5464)
https://github.com/python/cpython/commit/b299393cc372f3ecbef4304f8eaa4c7838e975ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:38:02 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 31 Jan 2018 21:38:02 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517434682.4.0.467229070634.issue32735@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5291

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:39:14 2018
From: report at bugs.python.org (Edward Preble)
Date: Wed, 31 Jan 2018 21:39:14 +0000
Subject: [issue32736] random.triangular yields unexpected distribution when
 args mixed
Message-ID: <1517434754.22.0.467229070634.issue32736@psf.upfronthosting.co.za>


New submission from Edward Preble <preble.edward at gmail.com>:

The random.triangular function produces an unexpected distribution result (instead of an error or warning message) when the order of the 3 arguments are mixed up.

Python notebook with demo of issue here:
https://github.com/epreble/random_triangular_distribution_issue

Cases 1-4 are OK
1. random.triangular(low, high, mode) (Docs specified usage)
2. random.triangular(high, low, mode)
3. random.triangular(low, high)
4. random.triangular(high, low)

Incorrect argument input (e.g. numpy style) yields distributions that are NOT 3-value-triangular and the output is also from different ranges than expected:

Incorrect arguments (first one is numpy.random.triangular style)
6. random.triangular(low, mode, high) 
or:
7. random.triangular(high, mode, low)

Raising errors was discouraged in prior discussion (https://bugs.python.org/issue13355) due to back compatibility concerns. However, I would argue that output of an incorrect distribution without a warning is a problem that -should- be broken, even in old code.

A possible solution, that might not break the old code (I haven't looked at all the edge cases):

If 3 arguments provided, need to be sure the mode is arg3:
If arg1 < arg2 < arg3, this is definitely wrong since the mode is definitely in the middle (wrong position).
If arg1 > arg2 > arg3, this is definitely wrong since the mode is definitely in the middle (wrong position).

Those tests would not break the old use cases, since the signs of the tests switch between arg1/arg2/arg3:
  low, high, mode (would be arg1 < arg2 > arg3)
  high, low, mode (would be arg1 > arg2 < arg3)

Not positive how all the <=, >= combos work out with these tests.

----------
components: Library (Lib)
messages: 311377
nosy: eddieprebs
priority: normal
severity: normal
status: open
title: random.triangular yields unexpected distribution when args mixed
type: behavior
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32736>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:39:29 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 31 Jan 2018 21:39:29 +0000
Subject: [issue32730] Allow py launcher to launch other registered Pythons
In-Reply-To: <1517414233.69.0.467229070634.issue32730@psf.upfronthosting.co.za>
Message-ID: <1517434769.3.0.467229070634.issue32730@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Yep, this was part of the plan. Just hasn't happened yet (it probably requires a significant rewrite of the launcher which nobody has volunteered to do or found the time for).

I thought I had another open bug on this too... if someone finds it, feel free to dup this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32730>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:40:53 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 31 Jan 2018 21:40:53 +0000
Subject: [issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit
 CPython 'current user only' installations on 64-bit Windows
In-Reply-To: <1395251194.85.0.622620129448.issue20984@psf.upfronthosting.co.za>
Message-ID: <1517434853.7.0.467229070634.issue20984@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20984>
_______________________________________

From report at bugs.python.org  Wed Jan 31 17:17:10 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 31 Jan 2018 22:17:10 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517437030.82.0.467229070634.issue32735@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 581ce25e1ffa374e62547ef266b6326bee0c54e5 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-32735: Fix typo in f-strings datetime format specifier example (GH-5464) (GH-5465)
https://github.com/python/cpython/commit/581ce25e1ffa374e62547ef266b6326bee0c54e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 17:20:15 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 31 Jan 2018 22:20:15 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517437215.3.0.467229070634.issue32735@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 17:20:21 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 31 Jan 2018 22:20:21 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517437221.36.0.467229070634.issue32735@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 17:29:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Jan 2018 22:29:34 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517437774.95.0.467229070634.issue32735@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

@Cheryl: I concur with Mariatta, good catch, thanks!

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 17:40:04 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 31 Jan 2018 22:40:04 +0000
Subject: [issue27923] PEP 467 -- Minor API improvements for binary sequences
In-Reply-To: <1472691379.75.0.669592694643.issue27923@psf.upfronthosting.co.za>
Message-ID: <1517438404.14.0.467229070634.issue27923@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

PEP should be accepted before review and merge.
So what you can do is restart discussion on ML again.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27923>
_______________________________________

From report at bugs.python.org  Wed Jan 31 17:44:07 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Wed, 31 Jan 2018 22:44:07 +0000
Subject: [issue27923] PEP 467 -- Minor API improvements for binary sequences
In-Reply-To: <1472691379.75.0.669592694643.issue27923@psf.upfronthosting.co.za>
Message-ID: <1517438647.91.0.467229070634.issue27923@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

INADA, what is ML? How do I restart the discussion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27923>
_______________________________________

From report at bugs.python.org  Wed Jan 31 17:52:14 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 31 Jan 2018 22:52:14 +0000
Subject: [issue27923] PEP 467 -- Minor API improvements for binary sequences
In-Reply-To: <1472691379.75.0.669592694643.issue27923@psf.upfronthosting.co.za>
Message-ID: <1517439134.76.0.467229070634.issue27923@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

ML meant mailing list.
There is guide for it.
http://devguide.python.org/communication/

If you really want this new API, you can search previous discussion and post new mail with summary of the previous discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27923>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:12:39 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 31 Jan 2018 23:12:39 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1517440359.55.0.467229070634.issue27428@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:33:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 23:33:09 +0000
Subject: [issue32727] smtplib's SMTP.send_message behaves differently with
 from_addr and to_addrs
In-Reply-To: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>
Message-ID: <1517441589.59.0.467229070634.issue32727@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 209108bd6997258948d13f48f2b5a2f1220c1a35 by Ned Deily (St?phane Wirtel) in branch '3.7':
bpo-32727: smtplib's SMTP.send_message behaves differently with from_addr and to_addrs (#5451)
https://github.com/python/cpython/commit/209108bd6997258948d13f48f2b5a2f1220c1a35


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:33:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 23:33:09 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1517441589.72.0.714561066657.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 7fdefac8e8fdca29b329b27e6e50f3b265bd8900 by Ned Deily in branch '3.7':
bpo-32726: Build macOS 10.9+ installer with private copy of Tcl/Tk 8.6
https://github.com/python/cpython/commit/7fdefac8e8fdca29b329b27e6e50f3b265bd8900


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:33:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 23:33:09 +0000
Subject: [issue30693] tarfile add uses random order
In-Reply-To: <1497751410.94.0.779622739852.issue30693@psf.upfronthosting.co.za>
Message-ID: <1517441589.78.0.574204596225.issue30693@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 57750be4ad3fa2cfd3473b5be1f1e1a5d0fa9f50 by Ned Deily (Bernhard M. Wiedemann) in branch '3.7':
bpo-30693: zip+tarfile: sort directory listing (#2263)
https://github.com/python/cpython/commit/57750be4ad3fa2cfd3473b5be1f1e1a5d0fa9f50


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30693>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:33:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 23:33:09 +0000
Subject: [issue32583] Crash during decoding using UTF-16/32 and custom error
 handler
In-Reply-To: <1516202870.11.0.467229070634.issue32583@psf.upfronthosting.co.za>
Message-ID: <1517441589.93.0.198621003763.issue32583@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 86fdad093b863db7ef6a3a00c9cff724c09442e7 by Ned Deily (Xiang Zhang) in branch '3.7':
bpo-32583: Fix possible crashing in builtin Unicode decoders (#5325)
https://github.com/python/cpython/commit/86fdad093b863db7ef6a3a00c9cff724c09442e7


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:33:10 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 23:33:10 +0000
Subject: [issue32735] Typo in f-string example in docs
In-Reply-To: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>
Message-ID: <1517441590.1.0.057773128935.issue32735@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 70e304252af34dfde3d89c9a1aa48c0c4af17dd3 by Ned Deily (Cheryl Sabella) in branch '3.7':
bpo-32735: Fix typo in f-strings datetime format specifier example (GH-5464)
https://github.com/python/cpython/commit/70e304252af34dfde3d89c9a1aa48c0c4af17dd3


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:33:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Jan 2018 23:33:40 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1517441620.39.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 1ca2ffdc532622ef001418585c146e6b0f31027f by Ned Deily in branch 'master':
bpo-32726: Build macOS 10.9+ installer with private copy of Tcl/Tk 8.6
https://github.com/python/cpython/commit/1ca2ffdc532622ef001418585c146e6b0f31027f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:48:06 2018
From: report at bugs.python.org (Bar Harel)
Date: Wed, 31 Jan 2018 23:48:06 +0000
Subject: [issue32734] Asyncio Lock safety issue (unlimited acquire)
In-Reply-To: <1517424945.58.0.467229070634.issue32734@psf.upfronthosting.co.za>
Message-ID: <1517442486.0.0.467229070634.issue32734@psf.upfronthosting.co.za>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
keywords: +patch
pull_requests: +5292
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32734>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:51:24 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 31 Jan 2018 23:51:24 +0000
Subject: [issue32736] random.triangular yields unexpected distribution when
 args mixed
In-Reply-To: <1517434754.22.0.467229070634.issue32736@psf.upfronthosting.co.za>
Message-ID: <1517442684.85.0.467229070634.issue32736@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry, while appreciate the sentiment and how well you articulated it, I'm going to decline this one for the reasons listed in the original discussion at https://bugs.python.org/issue13355 and because it is important to keep this code fast and light (so that large numbers of random variates can be created).  Also, for your own code, it is trivially easy to wrap the existing function with your own error checking.  Lastly, the ship for 2.7 sailed many years ago.  

Note, almost note of the random functions can defend themselves are incorrect argument order.  And who knows, there may be legitimate use cases for having the midpoint not between the low and high.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32736>
_______________________________________

From report at bugs.python.org  Wed Jan 31 18:53:08 2018
From: report at bugs.python.org (Bar Harel)
Date: Wed, 31 Jan 2018 23:53:08 +0000
Subject: [issue32734] Asyncio Lock safety issue (unlimited acquire)
In-Reply-To: <1517424945.58.0.467229070634.issue32734@psf.upfronthosting.co.za>
Message-ID: <1517442788.37.0.467229070634.issue32734@psf.upfronthosting.co.za>


Bar Harel <bzvi7919 at gmail.com> added the comment:

Alright. Fixed, added tests, news and acks.
Besides PR5466, we'll need another one for the 3.6 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32734>
_______________________________________

From report at bugs.python.org  Wed Jan 31 19:08:16 2018
From: report at bugs.python.org (D. Michael Parrish)
Date: Thu, 01 Feb 2018 00:08:16 +0000
Subject: [issue32737] str.format not producing strings for nan argument in
 accordance with documentation
Message-ID: <1517443696.2.0.467229070634.issue32737@psf.upfronthosting.co.za>


New submission from D. Michael Parrish <will.hill.fx at gmail.com>:

>>> version_info
(3, 0, 1, 'final', 0)
# I know this is an older version---stuck with it at work.
# I did not see this issue in the tracker (380 results for nan).
# Perhaps there is better documentation for how to use the issue
# tracker. Many of the links on the Dealing with Bugs page---
# https://docs.python.org/3/bugs.html#contributing-to-python
# ---are not helpful, e.g., 'contribute' just links back the same
# page.
#
# There are similar problems with inf and -inf
>>> isnan(float('nan'))
True
>>> repr(float('nan'))
'nan'
>>> '{0:f}'.format(float('nan'))
'-1.#IND00'
>>> '{0:F}'.format(float('nan'))
'-1.#IND00'
>>> '{0:g}'.format(float('nan'))
'-1.#IND'
>>> '{0:G}'.format(float('nan'))
'-1.#IND'
>>> '{0:.2f}'.format(float('nan'))
'-1.#J'

# c.f. https://docs.python.org/3/library/string.html#formatspec

----------
assignee: docs at python
components: Documentation
messages: 311393
nosy: ana, docs at python
priority: normal
severity: normal
status: open
title: str.format not producing strings for nan argument in accordance with documentation
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32737>
_______________________________________

From report at bugs.python.org  Wed Jan 31 19:13:05 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Feb 2018 00:13:05 +0000
Subject: [issue32737] str.format not producing strings for nan argument in
 accordance with documentation
In-Reply-To: <1517443696.2.0.467229070634.issue32737@psf.upfronthosting.co.za>
Message-ID: <1517443985.88.0.467229070634.issue32737@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I think you need to clarify with whoever is restricting your Python version which version you can actually use: Python 3.0.1 has been out of support for the better part of 10 years now and hardly anybody ever actually used that particular version (aside from me :))

I have confirmed that Python 3.6 (the oldest version which would receive a fix for this at this point) behaves as expected:

In [1]: '{0:f}'.format(float('nan'))
Out[1]: 'nan'

In [2]: '{0:F}'.format(float('nan'))
Out[2]: 'NAN'

In [3]: '{0:g}'.format(float('nan'))
Out[3]: 'nan'

In [4]: '{0:G}'.format(float('nan'))
Out[4]: 'NAN'

In [5]: '{0:.2f}'.format(float('nan'))
Out[5]: 'nan'

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32737>
_______________________________________

From report at bugs.python.org  Wed Jan 31 19:31:52 2018
From: report at bugs.python.org (D. Michael Parrish)
Date: Thu, 01 Feb 2018 00:31:52 +0000
Subject: [issue32737] str.format not producing strings for nan argument in
 accordance with documentation
In-Reply-To: <1517443696.2.0.467229070634.issue32737@psf.upfronthosting.co.za>
Message-ID: <1517445112.8.0.467229070634.issue32737@psf.upfronthosting.co.za>


D. Michael Parrish <will.hill.fx at gmail.com> added the comment:

Thank you so much for that reply. Maybe with that I can push for an upgrade.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32737>
_______________________________________

From report at bugs.python.org  Wed Jan 31 20:14:46 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 01 Feb 2018 01:14:46 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517447686.01.0.467229070634.issue31356@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

YoSTEALTH: I think this is one of those cases where the fact of it being a class is incidental; it's used the same as if it were a function, and just happens to be implemented as a class (the docs actually describe it in terms of a function). PEP8 guidance on CapWords for class names isn't ironclad, particularly when being a class is more implementation detail than design goal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 20:34:01 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 01 Feb 2018 01:34:01 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517448841.41.0.467229070634.issue31356@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

Actually i don't remember the last time where i saw anyone call a function using a "with" statement. This is very sloppy, sure PEP8 isn't ironclad but this is going to lead to confusion and we might have another case of datetime model (where you don't know whats what!!!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 20:58:06 2018
From: report at bugs.python.org (twinkim2)
Date: Thu, 01 Feb 2018 01:58:06 +0000
Subject: [issue32738] CDLL : Can't fine module
Message-ID: <1517450286.23.0.467229070634.issue32738@psf.upfronthosting.co.za>


New submission from twinkim2 <twinkim2 at hanmail.net>:

I just try to import ./so created by c language.
However , if some c function library is added in c souce code such as "fopen" and "sscanf" related with stdio , runtime error is happend like as below.
==================================================================
Traceback (most recent call last):  File "D:\python_test\c_library_test.py", line 8, in <module>
    adder = CDLL('./_adder.so')
  File "C:\Users\admin\AppData\Local\Programs\Python\Python36\lib\ctypes\__init__.py", line 348, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 126] can't fine Module.
===================================================================
Please give your guide to fix this issue.

----------
components: ctypes
messages: 311398
nosy: twinkim2
priority: normal
severity: normal
status: open
title: CDLL : Can't fine module
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32738>
_______________________________________

From report at bugs.python.org  Wed Jan 31 21:26:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 01 Feb 2018 02:26:38 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1517451998.83.0.467229070634.issue32476@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Sorry, I think this qualifies as a new feature and thus needs to go in 3.8.  Plus it should get a wider review from those with ET experience.  Perhaps @scoder would be willing go take a look.

----------
nosy: +scoder
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Wed Jan 31 21:47:55 2018
From: report at bugs.python.org (Ma Lin)
Date: Thu, 01 Feb 2018 02:47:55 +0000
Subject: [issue32394] socket lib beahavior change in 3.6.4
In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za>
Message-ID: <1517453275.77.0.467229070634.issue32394@psf.upfronthosting.co.za>


Ma Lin <malincns at 163.com> added the comment:

Base on Kamil's code, a little improvements.


if hasattr(sys, 'getwindowsversion'):
    WIN_MAJOR, _, WIN_BUILD, *_ = sys.getwindowsversion()
    if WIN_MAJOR == 10:
        if WIN_BUILD >= 15063:    # Windows 10 1703
            pass
        elif WIN_BUILD >= 14393:  # Windows 10 1607
            del socket.TCP_KEEPCNT
        else:
            del socket.TCP_KEEPCNT
            del socket.TCP_FASTOPEN
    elif WIN_MAJOR < 10:
        del socket.TCP_KEEPCNT
        del socket.TCP_FASTOPEN


Windows 10 versions:
https://technet.microsoft.com/en-us/windows/release-info.aspx

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32394>
_______________________________________

From report at bugs.python.org  Wed Jan 31 22:12:35 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 01 Feb 2018 03:12:35 +0000
Subject: [issue32394] socket lib beahavior change in 3.6.4
In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za>
Message-ID: <1517454755.03.0.467229070634.issue32394@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Nice. Think you can turn that into a pull request on GitHub?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32394>
_______________________________________

From report at bugs.python.org  Wed Jan 31 22:28:31 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 01 Feb 2018 03:28:31 +0000
Subject: [issue31368] Add os.preadv() and os.pwritev()
In-Reply-To: <1504727850.0.0.983406507924.issue31368@psf.upfronthosting.co.za>
Message-ID: <1517455711.49.0.467229070634.issue31368@psf.upfronthosting.co.za>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


----------
pull_requests: +5293

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31368>
_______________________________________

From report at bugs.python.org  Wed Jan 31 22:55:53 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Feb 2018 03:55:53 +0000
Subject: [issue31356] Add context manager to temporarily disable GC
In-Reply-To: <1504655244.01.0.877867263237.issue31356@psf.upfronthosting.co.za>
Message-ID: <1517457353.0.0.467229070634.issue31356@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A useful heuristic is that if something is named with CapWords, then class-like *usage* is explicitly supported (inheritance, isinstance checks, etc).

If it's named with snake_case or wordsruntogether, then calling it is OK, but you may run into quirky behaviour in class-style usage (e.g. it may not be a class at all in some implementations, or it may not be friendly to subclassing even when it is a full class).

So for something like this, snake_case is appropriate - you're meant to just use it, not subclass it. The fact that it's a type instance is an implementation detail.

(In other cases like contextlib.contextmanager we've made that implementation details status completely explicit in the code by having the public API be a wrapper function that returns an instance of a private class)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31356>
_______________________________________

From report at bugs.python.org  Wed Jan 31 23:59:28 2018
From: report at bugs.python.org (twinkim2)
Date: Thu, 01 Feb 2018 04:59:28 +0000
Subject: [issue32738] CDLL : Can't find module
In-Reply-To: <1517450286.23.0.467229070634.issue32738@psf.upfronthosting.co.za>
Message-ID: <1517461168.3.0.467229070634.issue32738@psf.upfronthosting.co.za>


Change by twinkim2 <twinkim2 at hanmail.net>:


----------
title: CDLL : Can't fine module -> CDLL : Can't find module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32738>
_______________________________________